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.
- Protection Level to Use for Selecting Rules
- The runtime policy rules are split among the following protection levels:
- 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.
- 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 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.