This topic introduces concepts and defines common terms that are used in Carbon Black Container.

General Terminology

Term Definition
Admission Controller A piece of code that intercepts requests to the Kubernetes API server. Admission controllers limit requests to create, delete, or modify objects.
cbctl Command-line tool that lets you control your Carbon Black Cloud Container and Kubernetes workload security. Carbon Black Cloud CLI Client scans container images and reports their health to the Carbon Black Cloud console.
Common Vulnerabilities and Exposures (CVE) A reference method for publicly known information-security vulnerabilities and exposures.
Container Lightweight, portable executable image. Containers let you virtualize multiple application runtime environments on the same operating system (kernel) instance.
Container Orchestration Exposes the API and interfaces. Helps manage the container lifecycle.
Control Plane Manages worker nodes and pods.
Controller Watches the state of your cluster and makes or requests changes where needed. Each controller tries to move the current cluster state closer to the desired state.
Cluster A set of nodes. Each cluster contains at least one node.
DaemonSet Node agent pod in the pod that ensures that all nodes run a copy of this pod. Using this node enables you to add more nodes to the pod and have them automatically protected by Carbon Black. Daemonset are commonly used for monitoring, networking, and security solutions. This technology is available in all Kubernetes.
DevOps Integration of traditional development and IT operations teams.
Docker Technology that provides operating system level virtualization (containers). The Docker environment includes a container runtime as well as container build and image management. builds an OCI-standard container image: therefore, Docker images run on any OCI-compliant container runtime.
eBPF Technology that extends the capabilities of the kernel safely and efficiently without changing kernel source code or loading kernel modules.
Egress The traffic going from the cluster to another network (public or private).
Ingress Exposes HTTP and HTTPS routes from outside the cluster to services within the cluster.
Kubelet Agent that runs on nodes.
Kubernetes An open-source container orchestrator. Automates deployment, load balancing, resource allocation, and security enforcement for containers. Keeps containerized applications running in their desired state to ensure that they are scalable and resilient.
Manifest digest A hash of a container image that is encrypted with SHA-256 and is deterministic based on the image build.
Microservice An application that is divided into a suite of independent, loosely integrated services.
Namespace A mechanism for isolating groups of resources in a single cluster.
Node Worker machine that runs containerized applications.
Node Agent Makes sure that all nodes run a copy of the pod. The node agent allows you to add more nodes to your Kubernetes cluster and have them be automatically protected by Carbon Black Container.
Pod A set of running containers.
Registry Docker Hub and other third party repository hosting services are called registries. A registry stores a collection of repositories.
Repository Stores one or more versions of a specific image.
Scope A way to group Kubernetes resources for targeted security protection and analysis. For example, you can group resources by cluster and namespace and then create policies for that scope.
Templated Policies Carbon Black Cloud Container deploys with 3 templated policies: Basic, Restrictive, and CIS Benchmark.
Vulernability Scanning Vulnerability scanning helps detect known vulnerabilities to reduce the risk of security breaches. Reduces the attack surface of a containerized application.
Workload An application running in a container.
Tip: For a full glossary of Kubernetes terms, see https://kubernetes.io/docs/reference/glossary/?fundamental=true.

Runtime Policies Concepts and Terminology

Runtime policies include rules for egress network control, threat protection, and anomaly detection in your Kubernetes environment. They provide the benchmark to control Kubernetes workloads behavioral changes. Control of the Kubernetes runtime environment happens at two levels:
  • Scope: you can monitor all Kubernetes resources in a defined scope.
  • Workload, you can track the behavior of a specific workload.
Actions
All rules have an associated action: Monitor or Alert. Either action causes an alert in the Carbon Black Cloud console.
  • Monitor: Monitor actions create an event record for informational purposes.
  • Alert: Alert actions create an event record signifying a change in behavior. Alert is the default action for each rule unless it is changed.
Built-in Rules
Runtime policies include built-in rules from the following categories:
  • Egress Traffic (Scope) — A list of allowed domains or IP addresses
  • Malicious Egress Traffic (Scope) — A list of malicious IP addresses and domains that have bad reputations
  • Workload Anomaly Detection — A change in workload behavior
  • Workload Threat Detection — A port scan
Learning Period
The learning period is the time during which all the Kubernetes resources in a scope are monitored for egress network connections. All egress destinations are recorded in the scope baseline. After the learning period is complete, the system actively tracks workloads behavior. Subsequent violations of the Kubernetes runtime policies trigger alerts.
If the learning period of a policy is modified, the policy stops alerting and the learning period is reset. If you add a new rule, the learning period starts running only for the new rule.
You can see and analyze the alerts in the Alerts page in the Carbon Black Cloud console.
Protection Level to Use for Selecting Rules
The runtime policy rules are split among the following protection levels:
Basic
Covers the issues that have the highest priority.
Moderate
Extends the rules included in the Basic protection level.
Strict
Extends the rules included in the Moderate protection level. Provides the broadest coverage of issues.
Runtime Policy Scope
Kubernetes scope is a grouping of Kubernetes resources, such as clusters or workloads. With the Kubernetes runtime policies, scopes explicitly define deploy phase or target complete applications.
Scope Baseline
The scope baseline determines the normal allowed behavior for all Kubernetes resources inside a scope. You can establish a scope baseline by monitoring the egress traffic of all workloads in the scope for a certain time, called a learning period. Deviation from the baseline triggers an alert. The baseline is at scope level and you can amend or reset the final behavior list in the scope.

Hardening Policies Terminology and Concepts

Actions
All rules have an action associated with them: Alert, Block, or Enforce. The rules configuration sets an expected value. If the value is not met, a rule violation is triggered.
An Alert action violation displays as a notification.
A Block action blocks the Kubernetes resources. This violation displays as an alert and block notification.

An Enforce action enforces the value for a rule. Enforce overwrites the value of one or more fields to the value that is defined in the rule's preset. In other words, Enforce changes the setting instead of blocking it. For example, you might set CPU and Memory for all workloads.

Note: When you enforce values, the running workload is different from the deployed workload. This difference can impact workload behavior and cause confusion if troubleshooting is required.
Built-in Rules
Built-in rules are available for direct use in Kubernetes hardening policies and are based on the Kubernetes security configuration.
Built-in Policies and Scopes
Policies and scopes that are available are with the Carbon Black Cloud console to facilitate the initial setup of Kubernetes policies. You can update and delete these policies and scopes. For more information, see Built-in Kubernetes Hardening Policies and Built-in Kubernetes Scopes.
Built-in Rules for Container Images
Rules that display the container-shaped icon Container-shape apply to scopes in the build phase by using the CLI Client. The rules also apply to Kubernetes workloads based on container images in the deploy phase. These rules enforce container image properties and behavior. Rules that do not display this icon are not applicable for the build phase. See Built-in Kubernetes Policy Rules.
Custom Rules
Custom rules use JSONPaths to specify Kubernetes resources and properties.
Custom Templates
A combination of built-in and custom rules.
Exceptions
Exclusion of workloads from the coverage of a Kubernetes policy due to known and accepted behavior.
  • For most rules, the exceptions are based on a workload name.
  • For Role-Based Access Control (RBAC) rules, the exceptions are based on resource name and username.
  • For rules that allow the Enforce action, the exceptions are based on workload name or workload label.
Hardening Policies
Policies that check rules on your Kubernetes environment configuration.
Kubernetes Scope
Grouping of Kubernetes resources with a definitive purpose; for example, to apply a policy.
Predefined Templates
Predefined rule sets of built-in rules.
Violations
Notifications on changes that happen in your Kubernetes environment after enabling Kubernetes hardening policies. Violations trigger actions at the block or alert rule level. Potential violations can be identified before enabling a policy, thus allowing planning security strategies such as adding exceptions, enforcing actions, or disabling and enabling rules.