13 Container and Pod security

If we try to secure our computers in a secure building, locked in a guarded vault, inside a Faraday cage, with a biometric login, not connected to the internet . . . , add up all of these precautions, and they still aren’t enough for our computers to be truly secure. As Kubernetes practitioners, we need to make reasonable security decisions based on our business needs. If we lock all of our Kubernetes clusters in a Faraday cage, unplugged from the internet, we make our clusters unusable. But if we do not focus on security, we allow people (like bitcoin miners, for example) to waltz in and invade our clusters.

As Kubernetes matures and is used more widely, common vulnerabilities and exposures (CVEs) in Kubernetes become a frequent occurrence. Here is a way to think about security: there is a risk that your system will get hacked! When you do get hacked, the questions to ask are

13.1 Blast radius

13.1.1 Vulnerabilities

13.1.2 Intrusion

13.2 Container security

13.2.1 Plan to update containers and custom software

13.2.2 Container screening

13.2.3 Container users—do not run as root

13.2.4 Use the smallest container

13.2.5 Container provenance

13.2.6 Linters for containers

13.3 Pod security

13.3.1 Security context

13.3.2 Escalated permissions and capabilities

13.3.3 Pod Security Policies (PSPs)