The previous articles about Docker security have discussed many security features that can be applied at container's runtime. Those features, such as privileges management, kernel capabilities, mandatory access control, among many others, can be enforced in Kubernetes environments through security contexts and policies.
A security context can be applied for a Pod or container.
The features that a security context allows to define are:
- Discretionary Access Control: Permission to access an object, like a file, is based on user ID (UID) and group ID (GID).
- SELinux: Objects are assigned security labels.
- Privileges: Run as privileged or not (Docker --privileged flag).
- Linux Capabilities: Give a process some privileges, but not all the privileges of the root user.
- AppArmor: Use program profiles to restrict the capabilities of individual programs.
- Seccomp: Filter a process's system calls.
- AllowPrivilegeEscalation: Controls whether a process can gain more privileges than its parent process.
- readOnlyRootFilesystem: Mounts the container's root filesystem as read-only.
To specify these security settings for a Pod, the securityContext field must be included in the Pod Spec. For the container level case, then the field must be located within the container’s array definition.
Analyzing an example:
As noted, securityContext is declared twice. The first is at the Pod level, the directives "runAsUser" and "runAsGroup" apply to all containers in the Pod definition file. The second securityContext declaration is inside the container definition, so "allowPrivilegeEscalation" will apply only for that container.
The image above shows that the UID and GID of the container are the ones specified in the security context.
Looking at another example:
In this case, the security context is used to drop all the kernel capabilities at container's runtime and add only the one needed for this scenario. The definition of capabilities can only be applied at container level.
An excellent practice is to define a Pod Security Policy for the cluster. This is a cluster-level resource, that defines a set of conditions related to security that a pod must run with, in order to be accepted into the system.
Pod Security Policies are enforced by enabling the admission controller, if implemented this acts an optional Kubernetes admission controller.
Below is an example of a restrictive policy that requires users to run as an unprivileged user, blocks possible escalations to root, and requires use of several security mechanisms.
Create the security policy by running:
In order to use the Pod Security Policy created, the requesting user or target pod's service account must be authorized to use that policy. This can be achieved easily by using an RBAC Cluster Role.
The following Cluster Role definition allows to use the security policies specified.
Then the Cluster Role is bound to the authorized users or service accounts.
From now on, all Pods created using the service account configured in the previous Cluster Role Binding, will have the Pod Security Policy enforced.
Do you want to learn more?
We will give a training about pentesting and securing docker swarm & kubernetes environments at Black Hat USA, HITB, Ekoparty and SIGS! Get your ticket!
- Black Hat USA (Online - English): www.blackhat.com/us-20/training/schedule/index.html
- HITB (Online - English - Singapore Timezone): conference.hitb.org/hitbsecconf2020sin/sessions/2-day-training-3-from-zero-to-hero-pentesting-and-securitization-of-docker-swarm-kubernetes-environments/
- Ekoparty Buenos Aires (Online - Spanish): www.ekoparty.org/eko16/trainings/from-zero-to-hero-pentesting-and-securing-docker-swarm-kubernetes-environments
- SIGS (Online - English - Europe Timezone): www.sig-switzerland.ch/from_zero_to_hero/
Sheila A. Berta
Head of Research at Dreamlab Technologies