Kubernetes Security Principles and Categories

In this blog, I will be sharing some of the Kubernetes security principles and categories.

Some Security Principles

#

• Limiting Attack Surface: Always look for ways to reduce areas where an attacker can harm you.
• Defense in Depth: Always have multiple layers of security and redundancy.
• Least Privilege: Always give the least permissions required to complete a task.

Visual Diagram:

%%{init: {"themeVariables": {
  "sequenceActorFontSize": "18",
  "sequenceActorLineHeight": "36",
  "sequenceMessageFontSize": "14"
}} }%%

sequenceDiagram
  autonumber
  participant Attacker
  participant ASR as Attack Surface Reduction
  participant DSL as Defense in Depth
  participant LP as Least Privilege

  rect rgb(255,230,230)
    Attacker->>ASR: Probe / Recon
    ASR-->>Attacker: Minimize exposure / block
  end

  rect rgb(230,255,230)
    Attacker->>DSL: Attempt exploit
    DSL-->>Attacker: Detect / slow / block
  end

  rect rgb(230,240,255)
    Attacker->>LP: Try privilege escalation
    LP-->>Attacker: Deny / restrict
  end

Kubernetes Security Categories

#

Host Operating System Security

#

In managed Kubernetes clusters, this is managed by the cloud provider.
But we should know how to manage it if we ever need to run a cluster from the ground up.

• A Kubernetes node should only do one thing, and that is Kubernetes — meaning no other services should be running other than Kubernetes components like containerd, kubelet, etc. Here, I recommend looking at Talos Linux distro for Kubernetes.
• Reduce the attack surface by removing unnecessary applications from nodes and keeping them up to date.
• Use runtime security tools like Seccomp, AppArmor, SELinux, and many more.
• Restrict access to nodes via SSH and IAM.
  ⚠️ DO NOT GIVE ACCESS TO ANYONE without a particular reason.

Kubernetes Cluster Security

#

In managed Kubernetes clusters, this is also managed by the cloud provider.
Let’s see some of the things on the cluster level.

• All Kubernetes components like the API Server, Kubelet, ETCD, and others should be up to date and running securely.
• Restrict access to the Kubernetes API server from outside of your network.
• Admission controllers provide various security plugins that you can enable for your cluster, both mutating and validating.
• Enable audit logging on the cluster for checking who did what, when, and from where.
• Data in ETCD should be encrypted.

Applications Security

#

Even in managed Kubernetes environments, you are fully responsible for this layer of security.
Some of the basic things one should do are mentioned below.

• Always use secrets, never hardcode any credentials.
• Use Role-Based Access Control (RBAC) to give access to anyone in the team.
• Use container sandboxing by isolating containers from the host system. Even if an attacker gets access to a container, your host machine is safe. Examples: kata containers, gVisor
• Apply container hardening by:
  • Running containers as non-root users.
  • Having read-only filesystems.
  • Using network policies.
  • Running secure container images.
• Always scan container images using vulnerability scanning tools and create secure container images.
• Use mTLS and service meshes.

Visual Diagram:

%%{init: {"themeVariables": {
  "sequenceActorFontSize": "18",
  "sequenceActorLineHeight": "36",
  "sequenceMessageFontSize": "14"
}} }%%

sequenceDiagram
  autonumber
  participant Attacker
  participant AS as Application Security
  participant KCS as Cluster Security
  participant HOS as Host OS Security

  rect rgb(230,240,255)
    Attacker->>AS: Target workloads / containers
    AS-->>Attacker: Secrets, RBAC, sandboxing, hardening, scanning
  end

  rect rgb(230,255,230)
    Attacker->>KCS: Attack Kubernetes components
    KCS-->>Attacker: Restricted API, admission controls, audit logs, encryption
  end

  rect rgb(255,230,230)
    Attacker->>HOS: Try to exploit node / OS
    HOS-->>Attacker: Hardened nodes, runtime security, limited access
  end