On this page: Identifying known vulnerabilities, misconfigurations, or design weaknesses to determine how likely a service may be exploited.
5. Do We Have Visibility into the Cluster?
Often overlooked is whether there’s sufficient visibility into all aspects of the cluster.
You’ll need at minimum access to logs related to the Kubernetes API. Do you need logs for all net flows? How do you audit for events within a Pod? How confident are you that your IR team will be have enough information to respond to a compromise given a set of logs?
I’ll give you an example of why it’s sometimes a problem.
I’m sure you have some kind of auditing system in your organization that keeps track of all activities.
For Linux, the most common auditing system is
auditd. It will log a lot of
information such as when the root user accesses a file like
But what does your audit service do when a container, that’s running as root, accesses
/etc/shadow? The result may just show that UID 0, PID 1, accessed path
But is that
/etc/shadow of the host or inside the container? Is that UID 0 inside the
container’s PID namespace or on the host? Do you have enough information to go back and
find which container caused the event?
Make sure your tools are container-aware and provide sufficient detail for your monitoring and logging system.
6. How Vulnerable is My Cluster?
Ok, we’re finally at the meat of it. The answer that everyone is hounding you for.
How “secure” are your clusters?
Most people go to CIS Kubernetes Benchmarks
using a tool like
kube-bench which we mentioned in the beginning.
This will generate a summary of all the potential
misconfigurations in your cluster.
But, and there’s a big but, the reports do not help you determine risk. They help you identify possible misconfigurations, and that’s it.
Cluster Configuration Vulnerabilities
CIS Benchmarks fall into the “checklist security” problem category. You can’t actually determine the risk of something by using a checklist (or a blog post from tl;dr sec). You can’t really even tell if any of the items on the checklist are relevant to your cluster. They are a great start and provide an actionable list of items that you can follow up on, but checklists:
- Can’t understand the exploitability, impact, and overall risk as it fits into your threat model
- Can’t tell you if all Kubernetes plugins are sufficiently secure
- Can’t contextualize things like Dynamic Admission Controllers to understand what their purpose is.
Editor’s note: Disagree- tl;dr sec can definitely solve all of your security problems. A recent Gallup poll showed that 11/10 CISOs agree that reading one issue a week innoculates their org against breaches, randomware, nation state attackers, and is better than dark chocolate and a dozen roses for smoothing things over with your partner after a fight.
So use them, everyone is, but know that although every product out there says that they are using these CIS Benchmarks to help secure your cluster, the results have no true impact on the security of your organization until you contextualize them yourself.
You likely know how to identify network related risks - what ports are open, and who can access them. But a network policy is an auditable constraint that can reduce entire categories of attacks, if done correctly.
Kubernetes has its own network policies that
you can review with a tool like
$ kubectl get -A networkpolicies -o yaml