chapter thirteen

13 Container and Pod security

 

This chapter covers

  • Security basics
  • Container security
  • Securing Pods

The only secure computer is in a secure building, locked in a guarded vault, inside a Faraday cage, with a biometric login, and not connected to the internet. Add up all of these precautions, and they still aren’t enough to be truly secure. As Kubernetes practitioners, we need to be reasonable and make security decisions based on business needs. Utilizing simple and basic practices, you can reduce the blast radius of security risk. The phrase 'blast radius' refers to the breadth and depth of a security intrusion.

When Kubernetes first came out, security via obscurity was feasible. It simply wasn’t a major attack vector; however, nowadays, CVEs in Kubernetes are a frequent occurrence. When you get hacked, the questions to ask are:

  • What can they get into
  • What can they do
  • What data can they get

With security comes a balancing act—security can slow down business and businesses thrive when they are operating at full speed. Being security conscious is different from overdoing security. The more you can automate, the more secure your system is, however, at the end of the day, a computer on the internet, is simply NOT secure.

13.1 Blast Radius

13.1.1 Vulnerabilities

13.1.2 Intrusion

13.2 Container Security

13.2.1 Plan to update

13.2.2 Screening

13.2.3 Container users setup

13.2.4 Use the smallest container

13.2.5 Container provenance

13.2.6 Linters With Your Containers

13.3 Pod security

13.3.1 Security Context

13.3.2 Escalated permissions and capabilities

13.3.3 Pod security policies

13.3.4 Do not automount the service account token

13.3.5 Root like Pods

13.3.6 The security outskirts

13.4 Summary