Container Security
Detect Container Drift in Your Kubernetes Deployments
Discover how to maintain compliance and secure your Kubernetes containers with automated security policies and scanning.
Detecting, inspecting, and preventing misconfigurations in your Kubernetes deployments is something security practitioners should be doing as a best practice. Kubernetes admission control deployment capabilities can help you accomplish this. However, what about when your container images are already deployed? What if you make a subsequent security deployment policy change after the fact? How do you make sure that non-compliant containers are not continuously running unchecked? What if you just want to identify which non-compliant containers are currently running in Kubernetes? That is where Continuous Compliance—our latest feature for Trend Micro Cloud One™ – Container Security—comes into play.
Let’s take a look at a sample Kubernetes deployment and explore this in detail from a security context:
As you can see, there are some properties in the Kubernetes deployment manifest file that are of note in the securityContext section.
These actions could potentially put the application at risk because if the container is compromised Privilege escalation can happen, which does not align with best practice standards.
So, how do we monitor and prevent this from being deployed in the future? Let’s look how we can do this with Container Security.
After I have my Kubernetes infrastructure enrolled, onboarded, and protected by Container Security with a simple Helm-based deployment, I can start doing some amazing things with Admission Control and Continuous Compliance.
Let’s start with Admission Control. If you navigate to the polices section, you can create a deployment policy to check for misconfigurations prior to deployment. For example, you can set the container properties policy to check for containers that are configured with privileged escalation rights to block and to log all privileged containers admitted to the Kubernetes Cluster.
Next, we will test our Admission Control policy and see what happens with a sample deployment:
We see that the Admission Controller has checked the deployment, blocked the non-compliant deployment, and logged the information in the Container Security console. Excellent!
Ok, so now what can we do about the containers that might be running in the environment that doesn’t meet our new deployment policies? Well, we can now extend our deployment policy into a Continuous Compliance policy. To do that, I can go to the Continuous tab in the policies section.
We are now going to choose to terminate containers that are currently running in privileged mode. You could also set this to log; first to identify the containers and then choose which ones you wish to terminate.
Below are my currently running pods and containers. Notice that I am currently running container/pod busypoxpod2 that is going to be evaluated after I save my new policy.
Now let’s see if Continuous Compliance detects it.
And there we go! We can see that container was terminated from the running pods and properly logged in the Container Security console.
To try this out on your own we invite you to register for a free, 30-day trial of Container Security.
See you next time!
