Skip to main content

Kubernetes Security | Kubernetes is a powerful tool for managing containerized applications, but it is important to understand the security implications of using Kubernetes. By default, Kubernetes does not provide any security features, so it is important to take steps to secure your Kubernetes cluster.

  • Part One can be found here.
  • Part Two can be found here.
kubernetes-security

Secure OS configuration

  • Privileged access management systems should be used by host administrators and maintainers to interact with cluster nodes.
  • It is recommended that the operating system and software be configured in accordance with the baseline and standards.
  • It is recommended to scan packages and configuration for vulnerabilities on a regular basis.
  • It is recommended that the OS kernel version be updated on a regular basis.

Secure Image development

  • Do not use RUN construct with sudo
  • COPY is required instead of ADD instruction.
  • Do not use automatic package update via apt-get upgrade, yum update, apt-get dist-upgrade
  • It is necessary to explicitly indicate the versions of the installed packages.
  • Do not store sensitive information (passwords, tokens, certificates) in the Dockerfile.
  • The composition of the packages in the container image should be minimal enough to work.
  • The port range forwarded into the container should be minimal enough to work.
  • It is not recommended to install wget, curl, netcat inside the production application image and container – It is recommended to use dockerignore to prevent putting sensitive information inside the image.
  • It is recommended to use a minimum number of layers using a multi-stage build
  • It is recommended to use WORKDIR as an absolute path. It is not recommended to use cd instead of WORKDIR
  • It is recommended to beware of recursive copying using COPY …
  • It is recommended not to use the latest tag
  • When downloading packages from the Internet during the build process, it is recommended to check the integrity of these packages.
  • Do not run remote control tools in a container
  • Based on the results of scanning Docker images, an image signature should be generated, which will be verified before deployment
  • Dockerfile should be checked during development by automated scanners
  • All images should be checked in the application lifecycle by automated scanners
  • Build secure CI and CD as same as supply chain process

Secure configuration of workloads

  • Do not run pods under the root account UID 0
  • Set runAsUser parameter for all applications
  • Set allowPrivilegeEscalation – false
  • Do not run the privileged pod (privileged: true)
  • It is recommended to set readonlyRootFilesystem – true
  • Do not use hostPID and hostIPC
  • Do not use hostNetwork
  • Do not use unsafe system calls (sysctl):
    • kernel.shm, kernel.msg, kernel.sem, fs.mqueue.
  • Do not use hostPath
  • Use CPU / RAM limits. The values should be the minimum for the containerized application to work
  • Capabilities should be set according to the principle of least privileges (drop ‘ALL’, after which all the necessary capacities for the application to work are enumerated, while it is prohibited to use:
    • CAP_SYS_CHROOT, CAP_SYS_PTRACE, CAP_FSETID, CAP_CHOWN, CAP_NET_RAW, CAP_NET_ADMIN, CAP_SYS_ADMIN, CAP_NET_BIND_SERVICE), CAP_SETUID, CAP_SETGID
  • Do not use the default namespace (default)
  • The application should have a seccomp, apparmor or selinux profile according to the principles of least privileges.
  • Workload configuration should be audited regularly.

Conclusion

In conclusion, Kubernetes security is a complex but important topic. By understanding the risks and taking steps to mitigate them, you can help keep your cluster safe from attack. Additionally, it’s important to stay up-to-date on security news and best practices, as the threat landscape is constantly changing. By following these guidelines, you can help ensure that your Kubernetes cluster is as secure as possible.