Lab27 - Kubernetes Pod Security Context
Lab27 - Kubernetes Pod Security Context
Introduction
A security context defines privilege and access control settings for a Pod or Container. Security
context settings include, but are not limited to:
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.
readOnlyRootFilesystem: Mounts the container's root filesystem as read-only.
Objectives:
• Set security context for a pod
• Set security context for a Container
• Set capabilities for a Container
Note: Ensure you have running cluster deployed & configured.
1. Ensure that you have logged-in as root user with password as linux on kube-master node.
1.1 Let us clone the git repository which contains manifests required for this exercise, by
executing the below command.
# git clone https://github.com/EyesOnCloud/k8s-security.git
Output:
# cat -n ~/k8s-security/security-context.yaml
Output:
Output:
Output:
/ $ ps
Output:
Note: The output shows that the processes are running as user 1000, which is the value of
runAsUser:
1.7 Let us list the /data/demo inside the container, by executing the below command.
/ $ ls -ld /data/demo
Output:
Note: The output shows that the /data/demo directory has group ID 2000, which is the value of
fsGroup
Output:
Note: The output shows that testfile has group ID 2000, which is the value of fsGroup.
/ $ id
Output:
Note: You will see that gid is 3000 which is same as runAsGroup field. If the runAsGroup was
omitted the gid would remain as 0(root) and the process will be able to interact with files that
are owned by root(0) group and that have the required group permissions for root(0) group.
/ $ exit
# cat -n ~/k8s-security/security-context-2.yaml
Output:
Output:
1.13 Let us verify the pod is running, by executing the below command.
Output:
$ ps aux
Output:
Note: The output shows that the processes are running as user 2000. This is the value of
runAsUser specified for the Container. It overrides the value 1000 that is specified for the Pod.
$ exit
# cat -n ~/k8s-security/security-context-3.yaml
Output:
Output:
1.19 Let us verify the pod is running, by executing the below command.
Output:
$ ps aux
Output:
1.22 Let us view the status of the process 1, by executing the below command
# cat /proc/1/status
Output:
# cat -n ~/k8s-security/security-context-4.yaml
Output:
Output:
1.26 Let us verify the pod is running, by executing the below command.
Output:
1.28 Let us view the status of the process 1, by executing the below command
# cat /proc/1/status
Output:
Note: In the capability bitmap of the first container, bits 12 and 25 are clear. In the second
container, bits 12 and 25 are set. Bit 12 is CAP_NET_ADMIN, and bit 25 is CAP_SYS_TIME.
Note: Linux capability constants have the form CAP_XXX. But when you list capabilities in your
Container manifest, you must omit the CAP_ portion of the constant. For example, to add
CAP_SYS_TIME, include SYS_TIME in your list of capabilities