Kubernetes is dynamic and hard to secure or monitor using existing tools. This has a significant impact on your security and compliance controls.
Kubernetes changes the way that we implement security controls. Here are some best practices for securing those environments.
Not knowing what is inside containers could be problematic, especially if it has vulnerable code. Downloaded container images could contain vulnerable code, making run-time containers exploitable by attackers. Therefore, it is crucial to practice good security hygiene and understand what exactly is being deployed.
Container scanning can help you to an extent, screening out containers with known major CVEs. Assuming that your code does what you want it to do, you want to make sure that no one can change it in a way that you don’t know about. Use source code control systems like Git.
Since IP addresses are ephemeral in a Kubernetes environment, we need to use other attributes to identify and audit workloads. This might include metadata and labels that identify infrastructure that must align to your compliance controls. When you use labels or fingerprints as an identity, you can begin attaching the security controls you need for compliance.
The next step is to write policies that interact with your labels. If an element in your architecture is labeled for PCI, then it doesn’t matter what specific kind of element it is. Your PCI-related policies should apply automatically, no matter what.
Lastly, you need to enforce the concrete nature of your policies. Developers and other personnel should not be able to change your policies – only the security and/or compliance team can. If someone tries to change those policies, the security and/or compliance team should receive an alert.
You may have thousands or even tens of thousands of servers, each with hundreds of workloads. You need a solution that can correlate all of these workloads, so you can detect what’s really happening in your platform. As one example, your containers need to have a consistent sense of time. Without a sense of time, your logs won’t be in a sequential order, so you can’t determine cause or effect.
As we’ve mentioned, you need to assume that you have one or more compromises in your network. Acting accordingly means implementing multiple enforcement points in and outside of your pod and hosts. If a single enforcement point gets compromised, the infection won’t be able to compromise your security posture. By implementing multiple, interlocking, and partially redundant security controls at every level of your stack, you eliminate the possibility that a single compromise can own your entire system.
Your orchestrator is in charge of the rest of your environment, so it should be in charge of security. Doing anything else will create an impedance between your policies and your security. Where the workload goes, the policy should follow.
Creating new microservices security models means adding more complexity to what are already very complex environments. Do it right, however, and you’ll be able to create a security model that’s even more secure than the model it’s replacing. For more information, check out our free webinar today.
Free Online Training
Access Live and On-Demand Kubernetes Tutorials
Calico Enterprise – Free Trial
Solve Common Kubernetes Roadblocks and Advance Your Enterprise Adoption
Get updates on blog posts, new releases and more!