Kubernetes security

1. Overview
2. Key security concepts
3. State update requests validation

• The K8s security model is based on the CNCF guidelines for securing cloud infrastructure and applications.

• The framework of security related best practices and tools is split along the 4 phases of the cloud application lifecycle :

  phase	description
  Develop	Enforce security best practices during application development
  Distribute	Secure supply chain and images registries, keep dependencies up-to-date
  Deploy	Secure cluster and nodes configuration, restrict access to the K8s API
  Runtime	Restrict workloads access to cluster resources and node resources

• It is assumed that security measures relevant to Develop and Distribute phases are enforced outside of K8s :

  1. Candidate workloads are compliant to security best practices (OWASP top 10, etc).
  2. Container images are built on top of a secure supply chain (socket.dev, base image scanning, etc).
  3. Nodes are provisioned with strict security measures (VLAN / VPC, firewall, hardened SSH config, etc).

• Past that stage, K8s offers native security mechanisms for the Deploy and Runtime phases :

  phase	tier	security feature	description
  Deploy	access	PKI	Authenticate components and users to kube-apiserver
  Deploy	access	ServiceAccount	Authenticate pods to kube-apiserver
  Deploy	access	mTLS	Encrypt control plane traffic
  Deploy	access	RBAC	Authorize / deny requests to kube-apiserver
  Deploy	storage	Secret	Built-in encryption for confidential workload data
  Deploy	storage	Encryption at rest	On-disk encryption for persistent data
  Runtime	compute	securityContext	Fine tune pods privileges and capabilities
  Runtime	compute	OS level security	Support OS-level restrictions for pods

1. Integrity : protection of cluster state

• Only cluster components and admins have to have the ability to update the cluster state.
• As a result, access to the components APIs must be restricted by authentication and authorization policies.
• Otherwise, outsiders may deploy unauthorized workloads to the cluster or tamper with existing workloads.

2. Authenticity : authentication of cluster components and admins

• Components and admins have to prove their respective identities when interacting with one another.
• It means that for each interaction, components and admins identities have to be verified :
  • Each component / admin must be identified (is it etcd, kubelet, an admin, etc ...).
  • Each component / admin must be part of the same cluster.
• Otherwise, outsiders may impersonate components or admins, which could lead to unauthorized cluster state updates.

3. Confidentiality : securing control plane traffic

• All traffic between cluster components have to be encrypted, and not exposed to public internet.
• The go-to options to that effect are to use TLS for encryption and VLAN / VPC for network isolation.
• Admins communications with the control plane can also be secured through SSH tunneling.
• Otherwise, outsiders may spy on traffic and gain unauthorized access to confidential cluster data (Secrets, etc ...)

Notes :

• Authentication, authorization and traffic encryption for workloads themselves is out of scope (Develop phase).
• A service mesh can be used to encrypt all internal cluster traffic as well (Pods, Service, etc ...)

• Security for the Deploy/access phase is provided by state update requests validation.
• Each incoming request to kube-apiserver goes through a sequence of security checks :

1. Authentication

• The request is evaluated against kube-apiserver configured authentication strategies.
• If a single authentication strategy validates the request, it is considered authenticated and identified.

2. Authorization

• The request is evaluated against kube-apiserver configured authorization policies.
• If all authorization policies validate the request, the requested state update is considered authorized.

3. Admission control

• The request is processed by kube-apiserver configured admission controllers.

• At this stage, the request can be modified (set default values, etc) and rejected in some cases.

• If none of the admission controllers reject the request, it is considered validated.

• Once the request is validated, it is written into etcd to update the cluster's desired state.

• Then, kube-controller-manager and kube-scheduler propagate the update to the cluster's current state.