How to enable seccomp profile on a predefined Helm chart in Kubernetes

Question

I want to enable seccomp profile like RuntimeDefault in my AWS EKS Kubernetes cluster on a predefined Helm chart which doesn't have any specific parameter in the values.yml file to be updated. I don't want to download the chart and all the files locally to make changes in the deployment.yml.

What is the right way to do it?

Answer 1

Answer:

Kubernetes does not (currently) enable seccomp by default.

Following are the 3 possible ways to do so defined:

1. If seccomp profile is already defined with a type (e.g., RuntimeDefault) in the default values.yml file of the newer version of a predefined Helm chart then simply upgrading its helm chart to that version will enable it.

2. If option 1 is not possible, you can enable it on a predefined Helm chart by setting the seccomp profile type in the security context of a pod to RuntimeDefault as follows in the values.yml file depending upon the key used in the deployment.yml file. For example, let’s say that securityContext is the key used to define the securityContext in the deployment.yml file. So, the following will be added in the values.yml file:

securityContext:
  seccompProfile:
    type: RuntimeDefault

3. If option 1 and 2 are not possible, you can download its complete helm chart locally and use it after updating the pod’s specification in its deployment.yml file as follows:

spec:
  securityContext:
    seccompProfile:
      type: RuntimeDefault

Note: It is not possible to apply a seccomp profile to a container running with privileged: true set in the container's securityContext. Privileged containers always run as Unconfined.

More Details:

Seccomp stands for “Secure Computing Mode”. It’s a security feature of the Linux kernel. In simple words, seccomp restricts the system calls that a process can make. In case of Kubernetes, it is a process running in a container in a pod.

Would seccomp improve our security posture? Yes, as seccomp protects the kernel from unwanted system calls made by processes, which in turn protects the host and helps maintain the isolation expected in a containerised environment.

Seccomp operation is controlled through rules specifying actions to take based on the requested syscall. Rules are defined in a file and referred to as a seccomp profile.

Example profiles can be found here: Restrict a Container's Syscalls with seccomp

In a seccomp profile, you basically define defaultAction to be taken, architectures covered, syscalls to list specific calls to be allowed or not.

• defaultAction: specifies what happens when the container uses a syscall that you haven't explicitly specified an action for. E.g., defaultAction: SCMP_ACT_ERRNO filters out the syscall.

• architectures: specifies the architectures we are allowed to receive syscalls from.

• syscalls: is a list of syscalls and the action we take when we encounter them. action: SCMP_ACT_ALLOW means we allow the system call to get past our seccomp filter.

A good starting point when introducing seccomp to your Kubernetes cluster is to enable the default profile (RuntimeDefault). While general in nature and very likely to be overly permissive for most of your workloads, some of the most security-sensitive syscalls are blocked. This default seccomp profile provides a sane default for running containers with seccomp and disables around 44 system calls out of 300+. Significant syscalls blocked by the default profile can be found here.

Docker, CRI-O or Containerd, all of these come with a default seccomp profile available in your Kubernetes cluster.

Some workloads may require a lower amount of syscall restrictions than others. This means that they can fail during runtime even with the RuntimeDefault profile. To mitigate such a failure, you can:

• Run the workload explicitly as Unconfined.

• Disable the SeccompDefault feature for the nodes. Also making sure that workloads get scheduled on nodes where the feature is disabled.

• Create a custom seccomp profile for the workload.

Important Note: Cloud managed Kubernetes clusters like Amazon EKS, GKE, etc, are managed Kubernetes clusters, so, we cannot play with the kubelet which means we cannot enable it on node level for all the pods in one go.