Skip to content
bifrost security

Glossary

This is a glossary of the terminology used in bifrost Service. It is a comprehensive guide to the concepts used.

Service

bifrost uses the term Service to represent the containerized software component and the lowest block that can have a tailored security profile attached to it. Service represents the containerized workload that bifrost will track across its lifecycle across every new build and version to understand how the behavior changes and to find anomalies in behavior to flag users about.

The behavioral data collected for one Service is used to produce a tailored Security profile deployed with the Service to protect it during runtime.

The Service is deployed into Environments, such as Dev, staging, pre-prod, sandbox, etc. These environments exist on Clusters. The specific setup varies across different organizations.

Environments

Environments in software development are distinct setups that isolate stages of the development lifecycle, helping manage and test changes safely before they reach end-users. Usually, they include:

  • Development (Dev): A sandbox environment where developers build and test code locally. It often includes mock data and is configured to allow rapid code changes without affecting other stages.
  • Staging (Test/Pre-production): A replica of the production environment used to test the full integration of the Service with realistic data and configurations, ensuring code stability and functionality before deployment.
  • Production (Prod): This is the live environment where the Service serves real users with actual data. It is optimized for performance and security, with strict access controls to maintain stability and protect data integrity.

When setting up bifrost, users will mirror their developer processes for developing and deploying their workloads.

Cluster

A representation of a Kubernetes cluster. It could be anything from a managed cluster on a hyperscaler to a self-hosted cluster on bare metal. A Cluster can have one or several Environments on it. A Cluster has at least one Worker Node.

Worker Node

The compute asset upon which containerized Services gets deployed. Worker nodes have a Host OS that needs to support the Kernel Module AppArmor for bifrost to work.

Host OS

The operating system running on each Worker Node is the foundation for container orchestration and workload execution. It is typically a lightweight, secure, and container-optimized OS designed to efficiently run Kubernetes workloads. For bifrost to work, the host OS must support the LSM AppArmor.

Common Host OS that supports AppArmor

Bifrost Agent

bifrost deploys an agent within each Cluster to assist in distributing AppArmor profiles and collecting events for the bifrost system to analyze. The Agent runs as daemonSet. The Agent is deployed using a Helm chart and an Agent Key. Bifrost Agent is written in Go and is installed using a helm chart. bifrost Agent runs as a DaemonSet within your Cluster.

Agent Key

A bifrost-generated unique key is used to identify a Cluster into which the bifrost Agent is deployed. Each Cluster holds a unique Key accessed from the bifrost portal /cluster setup page.

DaemonSet

A DaemonSet in Kubernetes ensures that a copy of a specific pod runs on all (or selected) Worker Nodes in a Cluster. It’s typically used for background processes running on every Worker Node, such as log collectors, monitoring agents, or network services. Whenever a new Worker Node is added to the Cluster, the DaemonSet automatically deploys the required pod to that Worker Node, ensuring consistent operation across the entire Cluster.

bifrost portal

bifrost portal is powering the bifrost Service, helping you set up your environment, connect the bifrost Agent, and is where you monitor all Services protected by bifrost.

bifrost Account

The Account used to access the bifrost portal. Users can sign up using either email/username and password or an existing account from Github, Google, Slack, or Microsoft. Every bifrost Account is tied to an Organization. When creating a new account without an invitation, the user will be prompted to create an Organization.

bifrost Organization

The Organization is the overall management object for the bifrost Service. It houses the bifrost Accounts invited to the Organization.

Security Profiles

bifrost works with AppArmor as the security module of choice. When auditing a Service, bifrost will analyze all the events that the Service produces when operating. The analysis will let bifrost produce a tailored security profile that is then used to protect the containerized workload in the production environment.

AppArmor

AppArmor is a Linux security module that provides a framework for restricting programs’ capabilities using per-container profiles. These profiles define the allowed actions and resources that the containerized workload can access, such as files, signals, and capabilities. Thus, the containerized Service is confined to a minimal set of permissions needed for its operation.

bifrost uses and produces AppArmor profiles to collect and protect Services. bifrost Agent distributes AppArmor profiles in audit mode to collect audit events and complain or enforce mode to protect a given workload.

audit mode

When bifrost is learning about the behavior of a Service, an audit profile is distributed. The audit profile will tell the system to record the Service’s behavior. bifrost Agent collects and sends the logs to the bifrost engine.

complain mode

A security profile deployed in complain mode will not break the behavior of a given container. Still, it will warn every time the containerized workload oversteps the boundary that the profile contains.

enforce mode

A security profile deployed in enforce mode provides the highest security and will block the call outside the boundary established by the profile.

Notifications

bifrost can generate alerts, warnings, and informative Notifications that will lead the receiving party to take action.

  • An informative notification often does not require any actions. It could be something as simple as an invited user joining the Organization, a new Service being registered, etc.

  • A warning notification will most likely require action. An example could be a misconfigured annotation for a given Service.

  • An alert will require a user to take action. The alert will show direct action by a deployed profile, either in complain or enforce mode. bifrost will provide more data about the alert in the portal.