Kubernetes clusters should not grant CAPSYSADMIN security capabilities

In Our AKS, found high severity alerts related to this in Azure Security Center.

What is CAPSYSADMIN meant for? Is the pods by default enabled with this property? Because we didnt specifically enabled it in our AKS? Then what will be the reason for this alert ? And how can we remediate this alert?

Explanation:

What is CAPSYSADMIN meant for?

Linux capabilities are a broad topic in itself but in short, as you can read here:

Starting with kernel 2.2, Linux divides the privileges traditionally associated with superuser into distinct units, known as capabilities, which can be independently enabled and disabled. Capabilities are a per-thread attribute.

So in other words they are distinct units that can be used to controll privilege escalation in your Linux OS.

And CAP_SYS_ADMIN is one of them and in fact it is pretty powerfull one. It allows to perform a range of system administration operations, privileged ones that cannot be performed by a normal user. For the full list please refer to this document and Ctrl+f for CAP_SYS_ADMIN.

As you can imagine, from security perspective, using this capability is not recommended, unless it is absolutely necessary. This is in line with principle of least privilege which basically means "giving a user account or process only those privileges which are essential to perform its intended function".

But let's go back to the context of kubernetes, AKS and Azure as you're probably still curious how all what I mentioned above fits there.

Is the pods by default enabled with this property?

No, it is not unless you enable it explicitly in a Pod definition. So the warning you get it's not about the fact that this capability is used by any of your pods but rather about the possibility that this property can be used by any of your users who are authorized to create new pods in the AKS cluster. In other words, at the moment, pods that leverage CAP_SYS_ADMIN capability are allowed to be created on your AKS cluster.

Below you can see an example of such a Pod:

apiVersion: v1
kind: Pod
metadata:
  name: security-context-demo-4
spec:
  containers:
  - name: sec-ctx-4
    image: gcr.io/google-samples/node-hello:1.0
    securityContext:
      capabilities:
        add: ["SYS_ADMIN"]

For more details please refer to Set capabilities for a Container section in the official kubernetes docs.

You can easily test it on your own and you'll see that the above Pod will be successfully created as it is not prohibited now in any way.

You can then kubectl exec to such Pod and verify that CAP_SYS_ADMIN capability is indeed used by it. Simply run:

kubectl exec -it security-context-demo-4 -- /bin/bash

Once connected to the Pod you can run:

capsh --print | grep cap_sys_admin

And you'll see that cap_sys_admin capability is enabled.

You can check the same in a Pod which doesn't use this capability:

apiVersion: v1
kind: Pod
metadata:
  name: security-context-demo-4-1
spec:
  containers:
  - name: sec-ctx-4
    image: gcr.io/google-samples/node-hello:1.0

When you kubectl exec into it:

kubectl exec -ti security-context-demo-4-1 -- /bin/bash

and run the same command:

capsh --print | grep cap_sys_admin

you'll see it's not enabled by default.

Solution:

Although AKS is a managed kubernetes service and in fact a lot of security layers are already handled for you by Microsoft, you are still granted with quite wide range of responsibilities when it comes to management of your AKS cluster. You can e.g. perform some further actions on your own to make it even more secure.

The good news is that you're not left completely alone with such tasks and you're provided with bunch of ready solutions that you can simply apply in your Azure environment.

One of them is Azure Security Center, which relieves you of the burden to detect new potential threats in your current setup on your own. As you can read here the recommendation Kubernetes clusters should not grant CAPSYSADMIN security capabilities is a part of New recommendations for hardening Kubernetes clusters which are still in preview, so you may have not seen them before:

New recommendations for hardening Kubernetes clusters (in preview)

The following recommendations allow you to further harden your Kubernetes clusters

Kubernetes clusters should not use the default namespace - To protect against unauthorized access for ConfigMap, Pod, Secret, Service, and ServiceAccount resource types, prevent usage of the default namespace in Kubernetes clusters.

Kubernetes clusters should disable automounting API credentials - To prevent a potentially compromised Pod resource from running API commands against Kubernetes clusters, disable automounting API credentials.

Kubernetes clusters should not grant CAPSYSADMIN security capabilities

Then what will be the reason for this alert ?

Given the above, this question can be answered: to give you possibility to improve your kubernetes cluster security by reducing the potential attack surface of your containers. But it's entirely up to you if you decide to follow this recommendation or not.

So much for the threat detection part. What about the remediation part ?

And how can we remediate this alert?

Azure policies is the answer for that. You may have heard about them already. Fortunately to remediate this particular threat you don't have to write your own custom policy as Azure provides built-in policy definitions for Azure Kubernetes Service and you can simply leverage them on your AKS cluster.

In the first column you are provided with direct link to your Azure Portal, which will bring you to the policy definition page, where you can examine its details and where it can be assigned to a particular subscription and recource group:

enter image description here

For more details please refer to:

Understand Azure Policy for Kubernetes clusters

Kubernetes clusters should not grant CAPSYSADMIN security capabilities

Explanation:

Solution:

New recommendations for hardening Kubernetes clusters (in preview)

Related

Recent Posts