Workload is a fairly recent term that is often used to describe applications but can also refer to infrastructure services. That’s important, because there can be a variety of ‘workloads’ running in your container clusters that aren't necessarily coming from your developers. The use of free and open-source services for a variety of purposes within container environments is growing. That’s actually true across IT operations, which was the number one category for downloads of free and open source software in the past year.
So when we say workload security, we mean any piece of software you’ve downloaded, developed, or deployed into your container environment. Think Consul. Think Kubernetes itself. Think Prometheus and Elasticsearch. Think NGINX and istio.
And then also put on that list any API gateways, caches, and ingress controllers you’ve deployed to support your Kubernetes environment. This is where a thorough bill of materials is important, and why taking an inventory on a regular basis is critical to maintaining a secure environment.
Once you’ve got your list, it’s time to address key workload security issues.
2. Malicious content is malicious
Even after you’ve locked the door by requiring credentials and applying access control, you’ve still got to worry about malicious content. That’s true of applications, microservices, and operational services in use. All workloads that present an interface to a user (whether operator or consumer) are potentially at risk.
If an attacker is able to exploit a vulnerability in OS components, they can compromise one or more workloads. Those vulnerabilities might be exposed thanks to a failure to 'lock the door' or 'screen your calls'. It's not a far-fetched scenario, as we’ve seen with CVE-2019-5736, in which a runc vulnerability at the OS layer sent the Internets into a panic.
The core security principle here was famously stated by Dan Walsh, SELinux and RedHat container security guru as: "Containers don't contain".
It's important to note that all network traffic with services and users outside the node must traverse the host OS. Networking between pods and containers on a node is accomplished via virtual networking with virtual bridges and clever use of iptables. But ultimately, traffic has to leave that physical node and that means processing at the host OS. Agents, plug-ins, and other daemons may be observing or capturing that traffic for security or visibility purposes. Those are potential points of compromise that you should add to the inventory you started compiling after reading about Pipeline Security.
Much of workload security in a container context is the same as that of any other application workload running in your production environment. Control access and require strong authentication, watch for malicious content, and be aware of shared and platform level vulnerabilities.