Introduction to Kubernetes Security

Let's take an overview of various aspects of Kubernetes security. This is quite important when working with Kubernetes in production and for the CKS exam.

Security Principles

Generally security is a complex process as it's not a single thing we should pay attention to, it's a combination of many different things.

Environments change, which means security cannot remain in a certain state for too long, requiring constant adaptation.

Attackers usually have the advantage of deciding when and what to attack, being able to choose the weak link in our system, which is why it's good to follow security principles.

• Defense in Depth: We should have multiple layers of security and redundancy is always welcome.
• Least Privilege: Everything should run only with the necessary permission. For example a pod should use a service account with minimal privilege so that if an attacker manages to run something it's within a limited container.
• Reduce Attack Surfaces: Remove or even eliminate possibilities for the attacker to exploit anything in our system.

Redundancy is good in security, which goes against the DRY (Don't repeat yourself) development principle.

Let's imagine an attacker will attack something in our cluster.

The first level of defense would be what we did to reduce the attack surface. We removed unnecessary applications on the system and implemented some firewall rules. This already keeps many attackers away.

The intermediate levels are all the security layers we can implement to ensure redundancy of the first level.

If the attacker manages to break through all layers they'll already be able to do something. What we can do is ensure that where they've reached they can't do much that will harm the system.

Ensuring security between Kubernetes components, even if the attacker manages, through a pod running a container without permission limits, to exit this container to inside the host, they shouldn't be able to communicate with etcd. At this point we can put communication restrictions and encryption.

K8S Security Categories

• Host operating system security. Probably it's a Linux operating system that already comes with some implemented security.
  • Kubernetes nodes should only run Kubernetes components.
  • Reduce attack surface.
    • Remove all extra applications that aren't necessary to run Kubernetes components.
  • Keep everything updated.
  • Use security tools to help.
  • Identify malicious processes.
  • Restrict user access to the host (IAM/SSH).
• Kubernetes cluster security. This is the security part of components running on the host.
  • Ensure components are running securely and updated.
    • Apiserver
    • Kubelet
    • ETCD
  • Restrict external access.
  • Confine communication through the network.
    • Components should communicate with others they need to communicate with. For example kubelet doesn't need to communicate with etcd.
  • Use authentication -> authorization.
  • Admission controller
    • NodeRestriction
    • Custom Policies (OPA)
  • Enable audit logs.
  • Security benchmark to give us recommendations
• Application security. It's the security we apply to pods and containers running in them.
  • Use secrets instead of writing them inside our Docker containers or manifests.
  • RBAC for access control and restriction.
  • Run pod containers in sandbox to create another security layer between container and host.
  • Container Hardening
    • Reduce attack surfaces on base images.
    • Run containers as User and not as Root.
    • Readonly filesystem.
    • Container should be immutable during its execution.
  • Vulnerability scans on images should be done constantly.
  • mTLS/Service Meshes ensuring traffic between our cluster applications is encrypted.

Kubernetes services in cloud like EKS, AKS, GKS, etc. are responsible for ensuring security at host and cluster level, but our application security is our problem. If we're going to set up a self-managed cluster then we should care about all categories and that's what CKS focuses on.