This topic discusses Carbon Black Container and Kubernetes architecture.
Carbon Black Cloud is a cloud-native SAAS solution. It can protect multiple Kubernetes clusters on-prem and in the public cloud (Amazon EKS, Azure Kubernetes Service, Google Kubernetes Engine).
Kubernetes Cluster Components
On a Kubernetes cluster, Carbon Black Container consists of key components that interact with each other.
All Carbon Black Container pods run in a dedicated namespace called cbcontainers-dataplane. The pods must all connect to Carbon Black Cloud through a direct connection or a proxy.
In the preceding diagram, all Carbon Black Cloud components are displayed in green and all Kubernetes components are displayed in blue.
Carbon Black Container uses eBPF technology (external link) to add the runtime security layer in Linux. eBPF extends the kernel capabilities safely and efficiently without requiring changing kernel source code or load kernel modules. Carbon Black uses eBPF in Carbon Black Container for all Linux kernels version 4.4+. With eBPF, Carbon Black Container can monitor all ingress, egress, and internal network connections. eBPF detects ports scanning, anomalous behaviors, and connections to malicious IPs and URLs.
The node agent pod is a Kubernetes DaemonSet. It makes sure that all nodes run a copy of this pod; therefore, you can add more nodes to your Kubernetes cluster, and Carbon Black automatically protects them. One node agent exists on each worker node. Daemonset are commonly used for monitoring, networking, and security solutions. This technology is available in all Kubernetes.
Kubernetes Admission Controller
VMware Carbon Black Container provides two kinds of policies:
- Runtime policy
- Hardening policy
Hardening policies include webhooks, which can extend the admission control (external link) of Kubernetes clusters. Carbon Black Container can automatically enforce (or mutate), block, or alert if an admin deploys a resource that is not compliant with Carbon Black Container hardening policies.
