This chapter will discuss the basics of container security from the container runtime level to the host itself. We will discuss how to apply these concepts to workloads running in a Kubernetes cluster and some of the security concerns and practices that relate specifically to running your Kubernetes cluster.
This chapter will discuss the following topics:
Container security is a deep subject area and in itself can fill its own book. Having said this, we will cover some of the high-level concerns and give a starting point to think about this area.
In the A brief overview of containers section of Chapter 1, Introduction to Kubernetes, we looked at some of the core isolation features in the Linux kernel that enable container technology. Understanding the details of how containers work is the key to grasping the various security concerns in managing them.
A good paper to dive deeper is NCC's Whitepaper, Understanding and Hardening Linux Containers (you can refer to more details about this in point 1 in the References section at the end of the chapter). In section 7, the paper explores the various attack vectors of concern for container deployments, which I will summarize (you can refer to more details about this in point 1 in the References section at the end of the chapter).
Vulnerability management is a critical component of any modern day IT operation. Zero-day vulnerabilities are on the rise and even those vulnerabilities with patches can be cumbersome to remediate. First, application owners must be made aware of their vulnerabilities and potential patches. Then these patches must be integrated into systems and code and often this requires additional deployments or maintenance windows. Even when there is visibility to vulnerabilities, there is often a lag in remediation, often taking large organizations several months to patch.
While containers greatly improve the process of updating applications and minimizing downtime, there still remains a challenge inherent in vulnerability management. Especially since an attacker only needs to expose one such vulnerability; making anything less than 100% of systems patched is a risk for compromise.
What's needed is a faster feedback loop in addressing vulnerabilities. Continuous scanning and tying into...
Kubernetes has continued to add a number of security features in their latest releases and has a well-rounded set of control points that can be used in your cluster; everything from secure node communication to pod security and even storage of sensitive configuration data.
During every API call, Kubernetes applies a number of security controls. This security life cycle is depicted here:
API call life cycle
After secure TLS communication is established, the API server runs through Authorization and Authentication. Finally, an Admission Controller loop is applied to the request before it reaches the API server.
Kubernetes supports the use of secure communication channels between the API server and any client including the nodes themselves. Whether it's a GUI or command-line utility such as kubectl, we can use certificates to communicate with the API server. Hence, the API server is the central interaction point for any changes...
Sometimes, our application needs to hold sensitive information. This can be credentials or tokens to log in to a database or service. Storing this sensitive information in the image itself is something to be avoided. Here, Kubernetes provides us a solution in the construct of secrets.
Secrets give us a way to store sensitive information without including plaintext versions in our resource definition files. Secrets can be mounted to the pods that need them and then accessed within the pod as files with the secret values as content. Alternatively, you can also expose the secrets via environment variables.
We can easily create a secret either with YAML or on the command line. Secrets do need to be base-64 encoded, but if we use the kubectl command line, this encoding is done for us.
Let's start with the following Secret:
$ kubectl create secret generic secret-phrases --from-literal=quiet-phrase="Shh! Dont' tell"We can then check for the Secret with...
We took a look at basic container security and some essential areas of consideration. We also touched on basic image security and continuous vulnerability scanning. Later in this chapter, we looked at the overall security features of Kubernetes including secrets for storing sensitive configuration data, secure API calls, and even setting up security policies and contexts for pods running on our cluster.
You should now have a solid starting point for securing your cluster and moving towards production. To that end, the next chapter will cover an overall strategy for moving towards production and will also look at some third-party vendors that offer tools to fill in the gaps and assist you on the way.
© 2017 Packt Publishing Limited All Rights Reserved
