Carbon Black Container Architecture

Carbon Black Cloud Container Architecture Overview

Carbon Black Cloud Container 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), and it should be installed in all your clusters.

Why would you need multiple clusters? What we are seeing in the field is that is safer and easier to run multiple clusters for dev, pre-prod, prod, backup… And why would you run Kubernetes on different clouds? First, there is the legacy reason, when an organization acquires another, and secondly, because not all teams need the same services, have the same knowledge and prices can differ between different solutions.

Graphical user interface, diagram, application</p>
<p>Description automatically generated

Kubernetes cluster components

On a Kubernetes cluster, Carbon Black Container consists of a few key components that interact with each other. All Carbon Clack pods are running in a dedicated namespace called “cbcontainers-dataplane”, they all need to connect to Carbon Black Cloud via a direct connection or via a proxy.

<p>Description automatically generated

All Carbon Black components in this diagram are in green color, and all Kubernetes components are in blue. For the simplicity of the diagram, only 1 master node and 2 worker nodes are represented, but you should have 3, 5, 7… master nodes to ensures that services remain available should a master node fail.

Carbon Black container uses eBPF technology to add the runtime security layer in Linux OS. eBPF is a technology with origins in the Linux kernel, it is used to extend the capabilities of the kernel safely and efficiently without requiring changing kernel source code or load kernel modules. That is why Carbon Black uses eBPF in Carbon Black Container, in Carbon Black Endpoint and Workload Linux for all Linux kernel version 4.4+. With eBPF, Carbon Black container can monitor all ingress, egress and internal network connections, so it can detect ports scanning, anomalous behaviors, and connections to a malicious IPs and URLs.

The “node agent” pod is a Kubernetes DaemonSet, it ensures that all nodes run a copy of this pod, and thus you can add more nodes to your Kubernetes cluster and Carbon Black will protect them automatically. Depending on Kubernetes solutions, the “node agent” will be able to run or not on master nodes, but for sure there will be one “node agent” on each worker node. Daemonset are commonly used for monitoring, networking and security solutions, and this technology is available in all Kubernetes.

Kubernetes admission controller

VMware Carbon Black Container provides two kinds of policies:

-          Hardening policy (including webhooks)

-          Runtime policy (eBPF policies)

Webhooks are used to extend the admission control of Kubernetes cluster, Carbon Black Container can auto enforce (or mutate), block or alert if an admin deploys a resource that is not compliant with Carbon Black Container hardening policy:

<p>Description automatically generated

When an admin tries to deploy a new application, he needs to authenticate and have the correct rights. Then, in the “mutating admission” phase, Carbon Black can modify the content of the deployment for example to limit privileges, add quotas or change the user of the application. The resulting object format is then validated, and Carbon Black approves the admission of the object. Other applications can use webhooks to modify the deployment, but Carbon Black always validates the result at the end. And finally, the application-object, the “desired state” is stored in the etcd Kubernetes internal database.


Carbon Black Container provides a CLI tool for image scanning, and instrumenting Carbon Black services. This tool is available for Linux and Mac. It can be installed on a Dev/Sec/Ops machine, or can be included in a CI/CD pipeline, for example in Jenkins or GitLab.

Cbctl needs an Internet access to connect to Carbon Black Cloud, and an access to your container registries.

<p>Description automatically generated

Summary and Additional Resources

This document helped you get a high-level understanding and overview of the VMware Carbon Black Container.

For more information about Container Protection, explore the Securing Modern Applications path. The activity path provides step-by-step guidance to help you increase your understanding of Carbon Black Container, including articles, videos, and labs.


The following updates were made to this guide:


Description of Changes


  • Guide was published.

Your feedback is valuable.

To comment on this paper, contact VMware Carbon Black Technical Marketing

Associated Content

From the action bar MORE button.

Filter Tags

Container Document Reference Architecture Intermediate Architect