Security Context

Configure a Security Context for a Pod or Container

A security context defines privilege and access control settings for a Pod or Container. Security context settings include:

• Discretionary Access Control: Permission to access an object, like a file, is based on user ID (UID) and group ID (GID).

• Security Enhanced Linux (SELinux): Objects are assigned security labels.

• Running as privileged or unprivileged.

• 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. This bool directly controls whether the no_new_privs flag gets set on the container process. AllowPrivilegeEscalation is true always when the container is: 1) run as Privileged OR 2) has CAP_SYS_ADMIN

cat <<EOF >secure-debugger.yaml
apiVersion: v1
kind: Pod
metadata:
  labels:
    run: secure-debugger
  name: secure-debugger
spec:
  volumes:
  - name: sec-vol
    emptyDir: {}
  securityContext:
   runAsUser: 1000
   fsGroup: 2000
  containers:
  - image: ansilh/debug-tools
    name: secure-debugger
    volumeMounts:
    - name: sec-vol
      mountPath: /data/sec
    securityContext:
     allowPrivilegeEscalation: false
EOF

$ kubectl create -f secure-debugger.yaml

$ kubectl exec -it secure-debugger -- /bin/sh
/ $ id
uid=1000 gid=0(root) groups=2000
/ $ ls -ld /data/sec/
drwxrwsrwx    2 root     2000          4096 Feb 26 17:54 /data/sec/
/ $ cd /data/sec/
/data/sec $ touch test_file
/data/sec $ ls -lrt
total 0
-rw-r--r--    1 1000     2000             0 Feb 26 17:54 test_file
/data/sec $

To apply capabilities , we can use below in each containers.

securityContext:
      capabilities:
        add: ["NET_ADMIN", "SYS_TIME"]

You may read more about capabilities here

Pod Security Policy

A Pod Security Policy is a cluster-level resource that controls security sensitive aspects of the pod specification. The PodSecurityPolicy objects define a set of conditions that a pod must run with in order to be accepted into the system, as well as defaults for the related fields.

Pod security policy control is implemented as an optional (but recommended) admission controller. If PSP is not enabled , then enable it in API server using admission-controller flag.

When a PodSecurityPolicy resource is created, it does nothing. In order to use it, the requesting user or target pod’s ServiceAccount must be authorized to use the policy, by allowing the use verb on the policy.

i.e.;

• A Role have to be created first with resource PodSecurityPolicy in a namespace
• A RoleBinding have to be created from the ServiceAccount to the Role in a namespace
• Then create a object using kubectl --as=<serviceaccount> -n <namespace> ..

An example PSP is below.

apiVersion: policy/v1beta1
kind: PodSecurityPolicy
metadata:
  name: example
spec:
  privileged: false  # Don't allow privileged pods!
  # The rest fills in some required fields.
  seLinux:
    rule: RunAsAny
  supplementalGroups:
    rule: RunAsAny
  runAsUser:
    rule: RunAsAny
  fsGroup:
    rule: RunAsAny
  volumes:
  - '*'

A well documented example is in official documentation