Creating Operational Security for Kubernetes in the Enterprise

By Atos Apprenda Support


As Bruce Schneier famously stated, security is more a process than a product. Kubernetes is enterprise-grade technology that transforms automation into orchestration, and it is re-inventing the way we look at DevOps.

As a result, those of us looking to introduce enterprise compliance and governance into Kubernetes have to apply best practice policies and procedures to some new principles, technologies, and DevOps workflows (i.e. mapping security processes to this new and exciting product). In the following paragraphs, I have included some of the processes, policies, and procedures you should be thinking about when looking to operationalize Kubernetes in the enterprise. (You can check out my new video on the topic below too.)

Before diving into cryptography, identity providers, and other security enablers, you should always start off with a system security plan. This is where you’ll align your security requirements, define your context for your operational users, the boundaries for your Kubernetes clusters, any external connections you want to make to other data center resources. This can all be discussed early on, allowing your team to map your requirements to your other security controls as you continue to build on your security program.

Kubernetes provides an API that allows its users to manipulate containers and pods that make up a given cluster, but keep in mind that you may not want everyone to have privileged access to said pods and containers in the cluster. As a result, you may want to define which users/roles have access to which kubectl commands. For example, developers may be allowed to deploy services, whereas managing the actual containers and pods themselves may be designated to DevOps or not even a person at all, but a CI/CD service. When defining access controls to Kubernetes nodes themselves, or Kubernetes components like etcd or the scheduler, this is generally designated to an IT Operator. You’ll want to control which users can ssh to which nodes, when and where.

Configuration management is a critical security control family that enterprises employ to manage standards around their IT systems. By certifying a subset or even a single operating system image, enterprises have to control fewer configurations. Containers, also in this vein, are not too dissimilar. Enterprises are likely to deploy a repository where access to a subset of approved images is granted, allowing them to maintain as few as possible, and can standardize the ones they desire for mission-critical workloads, allowing enterprises to enforce “least privilege” and expedite vulnerability patching workflows across the data center.

When it comes to protecting communications, there are numerous questions regarding segmenting networks in a dynamic environment such as a Kubernetes cluster. There are products out there, such as Calico, which provide the capabilities to dynamically change network policies, depending on the requirements of the workload. But in order to achieve true software-defined networking, enterprises should spend time in the planning and configuration management stages defining their desired state for network controls. Calico is a powerful tool that can enforce controls, even undesired ones if not configured correctly (e.g. cutting off communication to a critical service). Take your time to understand your workload policies, and set up the right network configuration to enforce the correct controls.

Lastly, assessing the security of the entire IT security plan can be daunting, especially considering it should be done repeatedly. Assessing Kubernetes is a holistic process, involving every layer of your IT stack, which includes scanning the binaries of services that need to be deployed to the Kubernetes cluster, scanning the containers and pods that make up the K8 cluster itself (don’t forget about the enterprise standard!), verifying and testing the Kubernetes nodes and components themselves. An attacker only needs one opening in the stack, and as a defender, you need to secure it all, but a proper security assessment strategy will allow you to manage those risks.

My closing advice: don’t stop here. There are many more security control families recommended by NIST, ISO, and others that involve securing an information system and they’re definitely applicable to Kubernetes. The above is a great place to begin. Recognize that security is a journey and continue to improve upon your procedures and plans, especially as Kubernetes continues to change the game.

Atos Apprenda Support

View Comments
  1. HarringtonOctober 25, 2016

    Network policies are of course the obvious Big One. 🙂 What component will you be using? I’ll probably go with calico, just because they put in the effort to send some PR’s to coreos’ kube-aws bootstrapper.

Comments are closed.