What is more important than actually getting the Kubernetes security certificate CKS is to have a sort of a mind map or a clear vision over the Kubernetes core security concepts and the different tools that you may use to prevent or mitigate attacks that could get through one of the 4 main attack surfaces.

That’s already a great starting point to this post, what are actually the layers of the cloud native security

Cloud

If the cloud layer is vulnerable or configured in a vulnerable way there is no guarantee that the components built upon it will be secure. Thus the first checkpoint is to check out security fundamentals documented by the cloud provider of your choice, as an example this is the Azure security overview that goes over the built-in capabilities in the core functional areas

• Operations
• Applications
• Storage
• Networking
• Compute
• Identity and access management

There is also the security baseline for the Kubernetes service which applies guidance from security benchmarks and provide recommendations on how to secure the cloud solution. Check out the Full Azure Kubernetes Service security baseline mapping

Cluster

The second layer of security concerns the cluster setup itself, There are two main areas

Securing the cluster components

This is your first line of defense, as a poor configuration and a loose access to the main components of your cluster like the kubernetes API or kubelet may put in danger your setup on both malicious and accidental levels.

Therefor an Authentication (who can access) and an Authorization (what can the User/Admin/ServiceAccount do) concept must be considered before the implementation phase. Checkout the Access and identity options for Azure Kubernetes Service which covers how to enhance the cluster security with the Azure AD integration and lays out the role based access control RBAC concept on both Kubernetes and Azure levels.

As shown below in the flow diagram you can manage Azure AD-integrated Kubernetes cluster resource permissions and assignments using Azure role definition and role assignments.

Securing the apps running in the cluster

• Application secrets management
• Pod security standards
• Quality of Service for Pods
• Network Policies
• TLS for k8s Ingress

For the general recommendations in regards with the cluster overall security, please check out the official documentation

Containers

If the cloud environment and the cluster get compromised, it’s up to the containers running on the cluster to restrict the damage through best practices and security guidelines such as

• Container vulnerability scanning and OS dependency security
• Image signing and enforcement
• Disallow priveleged users
• Use container runtime with stronger isolation

Code

The application code is in general a topic doesn’t concern the kubernetes environment itself, nevertheless it’s on of the attack surfaces that may compromise the whole setup by exposing unnecessary ports or by not enforcing communication over TLS only.

• Dynamic probing attacks like SQL injection, CSRF and other common web attacks can be faced by a Web Application Firewall in front of the cluster to secure the traffic flowing to your applications, this is a tutorial on how to implement the concept with Azure Application Gateway.

• Mutual TLS is an enhancement to the flat pod network that kubernetes originaly propose where any pod can communicate with any other pod in the cluster with no network restrictions nor security mesurments, I wrote a blog post on how to implement mTLS via Istio.

Wrapup

In general it’s a good practice to have a blick on the big picture especially when it comes to complexe system such as Kubernetes where you can get lost in details. I will be digging deeper to share pieces of my preparation and my work on the security aspect not only to get the certificate but as a general practice. Topic that i will be covering will be clusterized by the CKS domains and competencies.