Kubernetes Security

Kubernetes Security involves protecting Kubernetes clusters and the applications running on them. This includes configuration, access, networking, images, and monitoring during operation.

How it works

Kubernetes manages containers across many different servers. Security therefore applies to multiple layers. The control plane with the API server must be protected from unauthorised access. Access is managed using role-based access control (RBAC). Network policies limit which pods can communicate with each other. Admission controllers prevent insecure configurations such as privileged containers. During operation, tools can detect suspicious processes inside the containers.

A practical example

A development team exposes the Kubernetes dashboard online for testing. Attackers discover it and launch a cryptocurrency mining container. The monitoring system reports an unknown pod with high CPU load and connections to a mining pool. The team removes the pod and secures the dashboard.

What to look out for

• Avoid making the API server publicly accessible, or protect it stringently.
• Assign RBAC permissions restrictively. Cluster admin rights should be an exception.
• Prevent privileged containers and access to the host system.
• Implement network policies between namespaces and pods.
• Store secrets in an encrypted format, not as plain text in configurations.
• Monitor the cluster's audit logs.

Switzerland and regulation

There are no specific regulations for Kubernetes in Switzerland. The CIS Benchmarks for Kubernetes often serve as a reference. Financial institutions must include container platforms in their operational risk management framework.

Relevance for the SOC

The API server's audit logs show who changed what in the cluster. Together with container monitoring, they provide the basis for detection. Short-lived containers make central storage of this data particularly important.

Typical mistakes

A common mistake is using default configurations intended only for testing environments. Another error is assigning overly permissive service accounts to every pod by default.

How we implement it

We integrate audit logs from your clusters as a log source in our SOC. We are happy to discuss architecture questions as part of our Security Consulting.