Container Vulnerability Management

Question

Having difficulty understanding how to translate 'traditional' vulnerability management to a cloud environment. Previously accustomed to using tools like OpenVAS and Nessus, setting up scans which target static IPs and CIDR blocks. This approach does not appear to lend itself well to a modern cloud environment from what I understand due to the large number of scalable containers and ephemeral IPs.

When the production environment uses tools like Kubernetes and Docker, what is the recommended approach here? I am aware of container image scanning, but wouldn't we want to still scan a live deployed host? I do not believe it would make sense to scan everything due to replication but please correct me if I am wrong here.

I haven't found a lot of documentation that covers this topic well, nor tooling to support my thought process which makes me question if I am thinking about this all wrong. Do container image scanners actually run a full deployment and report the vulnerabilities found at each layer? Each completed build? Does the scan only scan the built image or does it actually scan a container as well?

Answer 1

There isn’t really a good approach yet — not even from the vendors that say that they address this space. I have turned to the literature (e.g., learning.oreilly) which does mention JFrog but fails to mention Twistlock (although mentions Sysdig). I have seen other spaces (e.g., katacoda) provide trial runs of Kubernetes vulnerability detections and remediation/countermeasures such as Polyverse and Quay’s Clair

Cloud containers also brings FaaS into question, and there are some services in the coursework you’ll hear of such as PureSec FunctionShield, but this doesn’t cover all bases

Typically, you’ll hear of 3 major Kubernetesisms that translate well but require a different way of thinking, and another Kubernetesism that does not translate well at all, and requires a VERY different way of thinking

First up is the sidecar pattern. In the sidecar, Kubernetes delivers functionality that runs alongside all containers in a pod. This second sort of approach you’ll hear of is called DaemonSet -- which runs alongside all nodes in the cluster, or all in the namespace (cluster in the cluster), which there are many ways of seeing, say, Twistlock Defender deploy, or CN-series UTM (equivalent to a PAN-OS firewall)

Thirdly, you will encounter the more-popular and easier to understand concept, the registry, which can provide approved containers with already-scanned binaries, images, configurations, etc. This is a bit cart-before horse though because ultimately what Kubernetes is missing is policy enforcement and tracking

That’s where the final concept comes into play. Kubernetes nomenclature defines this role as the Admission Controller, which provides admission control. There are a few other moving pieces to this, but a book on Kubernetes Security will clear this up quickly enough. The most popular platform for admission control is the OPA Gateway admission controller, which has its own policy language. However, other admission controllers do exist and may be wrapped into your cloud providers’ own policy products and vehicles. Sometimes it could be both, or OPA Gateway could replace your cloud providers’ Kubernetes policy vehicle entirely. Admission control would be a place where say, only tagged containers would be able to made able to run, or where processes inside containers could be made to not run as root (i.e., container doesn’t run things as root user). These are small examples, but could extend further into PodSecurityPolicy controls or deeper into the Kubernetes ecosystem. Sometimes this is Kubernetes implementation-specific which can be at odds or not again with the cloud providers’ Kubernetes implementation(s), etc