Managing Security Context

1. Setting runAsUser

Property	Description	Values	Notes
runAsUser	User ID to run the container as	`1000`	Must be a non-root user (typically >= 1000) for security reasons
runAsGroup	Group ID to run the container as	`1000`	Must match the user's primary group or be a valid group ID
fsGroup	Group ID for filesystem permissions	`2000`	Applies to all volumes mounted in the pod

Example: Setting runAsUser in Pod Spec

apiVersion: v1
kind: Pod
metadata:
  name: security-context-pod
spec:
  securityContext:
    runAsUser: 1000
    runAsGroup: 1000
    fsGroup: 2000
  containers:
  - name: app-container
    image: nginx

2. Setting runAsGroup

Property	Values	Description
runAsGroup	`1000`	Defines the primary group ID (GID) for the container's processes
runAsGroup (in Pod)	`2000`	Applies to all containers in the pod if set at the pod level

Example: Setting runAsGroup in Pod Spec

apiVersion: v1
kind: Pod
metadata:
  name: security-context-pod
spec:
  securityContext:
    runAsGroup: 2000
  containers:
  - name: app-container
    image: nginx
    securityContext:
      runAsGroup: 3000

Note: If runAsGroup is not specified at the container level, it inherits from the pod's securityContext.

Warning: Ensure that the GID specified has appropriate permissions on the host filesystem if fsGroup is not set.

3. Setting fsGroup

Property	Value	Description
fsGroup	`1000`	GUID of the group that owns the pod's volumes

Example: Setting fsGroup in Pod Spec

apiVersion: v1
kind: Pod
metadata:
  name: security-context-demo
spec:
  securityContext:
    fsGroup: 1000
  containers:
  - name: app
    image: alpine
    command: ["sleep", "3600"]

Note: The fsGroup is applied to all volumes mounted in the pod, ensuring that files created by containers have the correct group ownership.

4. Running as Non-Root

Field	Description	Default
runAsNonRoot	Specifies that the container must not run as the root user (UID 0)	`false`
runAsUser	UID to run the container process as	`null`
runAsGroup	GID to run the container process as	`null`
fsGroup	Group ID for filesystem permissions	`null`

Example: Setting Non-Root User

apiVersion: v1
kind: Pod
metadata:
  name: non-root-pod
spec:
  securityContext:
    runAsNonRoot: true
    runAsUser: 1000
    runAsGroup: 3000
    fsGroup: 2000
  containers:
  - name: app-container
    image: nginx

Note: Setting runAsNonRoot: true in Pod securityContext ensures that the container will not run as root, even if the image is configured to do so.

5. Setting Read-Only Root Filesystem

Property	Description	Values	Notes
readOnlyRootFilesystem	Mounts the root filesystem as read-only	`true` or `false`	Defaults to `false`

Example: Pod with Read-Only Root Filesystem

apiVersion: v1
kind: Pod
metadata:
  name: readonly-pod
spec:
  containers:
  - name: app-container
    image: nginx
    securityContext:
      readOnlyRootFilesystem: true

Note: Setting readOnlyRootFilesystem to true enhances security by preventing writes to the root filesystem, but may require adjustments in container configuration or application logic to handle read-only mounts.

6. Adding Capabilities

Capability	Description	Default	Notes
CAP_CHOWN	Change ownership of files	Disabled	Required for changing file ownership
CAP_DAC_OVERRIDE	Bypass file read, write, and execute permission checks	Disabled	Allows access to files without permissions
CAP_DAC_READ_SEARCH	Bypass file read permission checks and search directory permissions	Disabled	Allows reading files and searching directories without read permission
CAP_FOWNER	Bypass file ownership checks	Disabled	Allows modifying files regardless of ownership
CAP_SETUID	Change user ID	Disabled	Allows changing the effective user ID
CAP_SETGID	Change group ID	Disabled	Allows changing the effective group ID
CAP_NET_BIND_SERVICE	Bind to privileged ports (e.g., < 1024)	Disabled	Required for binding to low-numbered ports
CAP_SYS_ADMIN	Perform system administration operations	Disabled	Very powerful capability, use with caution

Example: Adding Capabilities to a Pod

apiVersion: v1
kind: Pod
metadata:
  name: example-pod
spec:
  containers:
  - name: example-container
    image: nginx
    securityContext:
      capabilities:
        add:
        - CAP_NET_BIND_SERVICE
        - CAP_CHOWN

Note: Adding capabilities increases the attack surface of a container. Always follow the principle of least privilege and only add required capabilities.

7. Dropping Capabilities

Capability	Description	Dropped
CAP_CHOWN	Change file ownership	`true`
CAP_DAC_OVERRIDE	Bypass file read, write, and execute permission checks	`true`
CAP_DAC_READ_SEARCH	Bypass file read permission checks and search directory permissions	`true`
CAP_FOWNER	Bypass file ownership checks	`true`
CAP_FSETID	Set file user/group ID	`true`
CAP_KILL	Bypass permission checks for sending signals to processes	`true`
CAP_SETGID	Change group ID	`true`
CAP_SETUID	Change user ID	`true`
CAP_SETPCAP	Modify process capabilities	`true`
CAP_NET_BIND_SERVICE	Bind to privileged ports (e.g., below 1024)	`true`
CAP_NET_RAW	Use raw sockets and packet interfaces	`true`
CAP_SYS_CHROOT	Use chroot() system call	`true`
CAP_SETFCAP	Set file capabilities	`true`
CAP_SYS_ADMIN	Perform system administration operations	`true`
CAP_SYS_PTRACE	Trace processes	`true`

Example: Dropping Capabilities in Pod Spec

apiVersion: v1
kind: Pod
metadata:
  name: example-pod
spec:
  containers:
  - name: example-container
    image: nginx
    securityContext:
      capabilities:
        drop:
          - CAP_CHOWN
          - CAP_DAC_OVERRIDE
          - CAP_DAC_READ_SEARCH
          - CAP_FOWNER
          - CAP_FSETID
          - CAP_KILL
          - CAP_SETGID
          - CAP_SETUID
          - CAP_SETPCAP
          - CAP_NET_BIND_SERVICE
          - CAP_NET_RAW
          - CAP_SYS_CHROOT
          - CAP_SETFCAP
          - CAP_SYS_ADMIN
          - CAP_SYS_PTRACE

8. Using Privileged Mode

Property	Description	Values
privileged	Controls whether a container can run with elevated privileges	`true` or `false`

Example: Setting privileged mode in a Pod

apiVersion: v1
kind: Pod
metadata:
  name: privileged-pod
spec:
  containers:
  - name: privileged-container
    image: nginx
    securityContext:
      privileged: true

Note: Using privileged: true grants the container full root access to the host system, which is a significant security risk. It should only be used when absolutely necessary and in trusted environments.

9. Setting SELinux Options

Field	Description	Values	Notes
seLinuxOptions	Configures SELinux options for a pod or container	`SELinuxOptions`	Used to set SELinux context for containers and pods

Example: Setting SELinux Context for a Pod

apiVersion: v1
kind: Pod
metadata:
  name: selinux-pod
spec:
  securityContext:
    seLinuxOptions:
      user: "system_u"
      role: "object_r"
      type: "svirt_sandbox_file_t"
      level: "s0:c124,c987"
  containers:
  - name: app-container
    image: nginx

Note: SELinux context settings are applied at the pod or container level and must be supported by the underlying host system.

10. Configuring Seccomp Profiles

Field	Description	Values	Notes
seccompProfile.type	Seccomp profile type to apply	`"Unconfined"`, `"RuntimeDefault"`, `"Localhost"`	Defaults to `"RuntimeDefault"`
seccompProfile.localhostProfile	Path to seccomp profile on the node	`string`	Required if `type` is `"Localhost"`

Example: Applying a Seccomp Profile

apiVersion: v1
kind: Pod
metadata:
  name: seccomp-pod
spec:
  containers:
  - name: app-container
    image: nginx
    securityContext:
      seccompProfile:
        type: "Localhost"
        localhostProfile: "/var/lib/seccomp/profile.json"

Note: Seccomp profiles must be pre-loaded on the node or defined in a Localhost path.

Warning: Misconfiguring seccomp can lead to container startup failures or unexpected behavior.

11. Setting AppArmor Profiles

Field	Description	Values
securityContext.appArmorProfile	Specifies the AppArmor profile to be applied to a container	`localhost/<profile-name>`

Example: AppArmor Profile in Pod Spec

apiVersion: v1
kind: Pod
metadata:
  name: apparmor-pod
spec:
  containers:
  - name: apparmor-container
    image: nginx
    securityContext:
      appArmorProfile:
        profileName: localhost/nginx-profile

Note: AppArmor profiles must be loaded on the host system before they can be applied to containers.