--- title: "Baseline profile" url: https://docs.nirmata.io/docs/policy-sets/podsecurity/baseline/ --- The Baseline profile is aimed at ease of adoption for common containerized workloads while preventing known privilege escalations. It is targeted at application operators and developers of non-critical applications. Click on each of the controls to know more about them. - [disallow-capabilties](./disallow-capabilities/) - [disallow-host-namespaces](./disallow-host-namespaces/) - [disallow-host-path](./disallow-host-path/) - [disallow-host-ports](./disallow-host-ports/) - [disallow-host-process](./disallow-host-process/) - [disallow-privileged-containers](./disallow-privileged-containers/) - [disallow-proc-mount](./disallow-proc-mount/) - [disallow-selinux](./disallow-selinux/) - [restrict-apparmor-profiles](./restrict-apparmor-profiles/) - [restrict-seccomp](./restrict-seccomp/) - [restrict-sysctls](./restrict-sysctls/) --- ## Disallow Capabilities ### Description Adding additional capabilities beyond those listed below must be disallowed. **Restricted Fields** * spec.containers[*].securityContext.capabilities.add * spec.initContainers[*].securityContext.capabilities.add * spec.ephemeralContainers[*].securityContext.capabilities.add **Allowed Values** * `Undefined/nil`: No capability is assigned * `AUDIT_WRITE`: Allows writing records to the kernel auditing log. This is used for logging security-related events and auditing system activity * `CHOWN`: Permits the process to change the owner and group of files arbitrarily * `DAC_OVERRIDE`: Enables the process to bypass file read, write, and execute permission checks (DAC: Discretionary Access Control) * `FOWNER`: Allows bypassing the permission checks for operations that normally require the process’s filesystem user ID to match the file's user ID. It also includes permission to set certain file attributes and ACLs (Access Control Lists) * `FSETID`: Prevents the kernel from clearing the set-user-ID and set-group-ID mode bits when a file is modified, and allows setting the set-group-ID bit for files under specific conditions * `KILL`: Permits bypassing the permission checks required for sending signals to processes * `MKNOD`: Allows the creation of special device files using the mknod system call, which is usually restricted to system administrators. * `NET_BIND_SERVICE`: Allows a process to bind to Internet domain privileged ports (port numbers less than 1024) * `SETFCAP`: Permits a program to set the capabilities of a file * `SETGID`: Allows arbitrary manipulation of process group IDs and the supplementary group ID list * `SETPCAP`: Allows a process to manage and modify the capabilities of itself and other processes * `SETUID`: Allows a user to execute a file with the file owner's permissions * `SYS_CHROOT`: Allows the process to change its base directory to another location in the file system, effectively creating a new root directory for the process. This is used for isolating the process from the broader file system to enhance security ### Risks The allowed capabilities in this policy are intended to balance functionality and security. However, each of these capabilities can still pose security risks if misused or exploited. You might want to use the `restricted` profile or customize the checks. Below are some additional capabilities not listed in this policy, along with their associated risks: * `SYS_BOOT`: Allows a process to initiate a system reboot. An attacker could use this capability to cause service interruptions or system downtime. * `SYS_MODULE`: Permits loading and unloading of kernel modules. An attacker can use this to introduce malicious modules or alter kernel behavior. * `SYS_NICE`: Enables adjustment of process priorities and scheduling policies. Misuse of this capability might allow an attacker to degrade system performance by prioritizing their own processes over critical system tasks, potentially causing service degradation or denial of service. * `SYS_TIME`: Allows setting the system time and date. Manipulating the system clock could disrupt time-based security mechanisms and logging, and can lead to security vulnerabilities or incorrect system behavior. * `SYS_PTRACE`: Grants permission to observe processes and examine their memory and gain insights into their behavior. An unauthorized user could monitor or manipulate other processes, potentially leading to data leakage or access to sensitive information. ### Kyverno Policy Refer to the Nirmata curated policies - [disallow-capabilities.yaml](https://github.com/nirmata/kyverno-policies/blob/main/pod-security/baseline/disallow-capabilities/disallow-capabilities.yaml) ### References #### Configuration Settings The below configuration indicates that if the deployed resource contains one of `ephemeralContainers` or `initContainers` or `containers` in their `spec` field, **AND** if `securityContext.capabilities.add[]` field is present, **only** the values from the prescribed list make the resource to be conformant with this security control. If the `securityContext.capabilities.add[]` field is not present, then the resource is conformant by default. ```bash securityContext: capabilities: add: - AUDIT_WRITE - CHOWN - DAC_OVERRIDE - FOWNER - FSETID - KILL - MKNOD - NET_BIND_SERVICE - SETFCAP - SETGID - SETPCAP - SETUID - SYS_CHROOT ``` #### Resource Example Below is a `Deployment` resource example where `securityContext.capabilities.add` for both containers is from the allowed list of capabilities. ```bash apiVersion: apps/v1 kind: Deployment metadata: name: gooddeployment spec: replicas: 1 selector: matchLabels: app: app template: metadata: labels: app: app spec: containers: - name: container01 image: dummyimagename securityContext: capabilities: add: - DAC_OVERRIDE - name: container02 image: dummyimagename securityContext: capabilities: add: - SETGID ```text --- ## Disallow Host Namespaces ### Description Host namespaces (Process ID namespace, Inter-Process Communication namespace, and network namespace) allow access to shared information and can be used to elevate privileges. Pods should not be allowed access to host namespaces. **Restricted Fields** * spec.hostNetwork * spec.hostPID * spec.hostIPC **Allowed Values** * Undefined/nil * false ### Risks When `hostNetwork` is set to `true`, we encounter risks such as: * `Network Traffic Snooping`: Enabling hostNetwork allows a pod to access the node's network namespace, which includes the ability to monitor all network traffic on the node. This could lead to sensitive data exposure if an attacker manages to deploy a malicious pod that can snoop on network communications. * `Access Services Bound to Localhost`: You can gain access to services that are only available on the host's loopback interface or are otherwise restricted by network policies. These services could present opportunities for privilege escalation. * `Bypassing Network Policies`: When a pod is deployed with `hostNetwork: true`, it can bypass restrictive network policies applied to the namespace. This occurs because the pod is bound to the host's network interfaces rather than being confined to the network restrictions at the pod level. When `hostPID` is set to `true`, we encounter risks such as: * `Viewing Host Processes`: Running ps from within a pod with `hostPID: true` allows you to see all processes running on the host, including those from other pods. * `Finding Sensitive Information`: There's a chance you could discover credentials like passwords, tokens, or keys. With these, you could potentially escalate privileges within the cluster, gain access to other namespaces, or even elevate to cluster admin. * `Terminating Processes`: You could also terminate any process on the node, creating a denial-of-service situation. When `hostIPC` is set to `true`, we encounter risks such as: * `Access to Shared Data`: Allows a pod to access inter-process communication (IPC) mechanisms shared by the host or other pods using the host’s IPC namespace. * `Inspecting Shared Memory (`/dev/shm`)`: You can access the `/dev/shm` directory, which is shared between the host and any pod with this setting enabled. The sensitive data that is stored here might be exposed. * `Manipulating IPC Mechanisms`: You can inspect and potentially interact with existing IPC mechanisms, such as shared memory, semaphore arrays, or message queues, using tools like `/usr/bin/ipcs`. This could lead to altering of communication channels between processes. ### Kyverno Policy Refer to the Nirmata curated policies - [disallow-host-namespaces.yaml](https://github.com/nirmata/kyverno-policies/blob/main/pod-security/baseline/disallow-host-namespaces/disallow-host-namespaces.yaml) ### References #### Configuration Settings The below configuration indicates that if the deployed resource contains one of `hostPID` or `hostIPC` or `hostNetwork` in their `spec` field, then the only acceptable value is `false` to be conformant with this security control. If those fields are not present to begin with, then the resource is conformant by default. ```bash =(hostPID): "false" =(hostIPC): "false" =(hostNetwork): "false" ``` #### Resource Example Below is a `Deployment` resource example where all the three fields (`hostPID`, `hostIPC`, and `hostNetwork`) are set to `false`. Even if one or two of them are present, they should be set to `false`. ```bash apiVersion: apps/v1 kind: Deployment metadata: name: gooddeployment spec: replicas: 1 selector: matchLabels: app: app template: metadata: labels: app: app spec: hostPID: false hostIPC: false hostNetwork: false containers: - name: container01 image: dummyimagename ```text --- ## Disallow Host Path ### Description HostPath volumes let Pods use host directories and volumes in containers. Using host resources can be used to access shared data or escalate privileges and should not be allowed. Using the hostPath volume type presents many security risks. If you can avoid using a hostPath volume, you should. For example, define a local PersistentVolume, and use that instead. **Restricted Fields** * spec.volumes[*].hostPath **Allowed Values** * Undefined/nil ### Risks Using `hostPath` volumes can introduce significant security risks to your Kubernetes cluster. Here are some potential risks associated with allowing `hostPath`: 1. `Privilege Escalation`: If a Pod with a `hostPath` volume is compromised, an attacker could gain access to sensitive files on the host machine. For instance, mounting a directory such as `/var/log` could allow an attacker to symlink sensitive files, read private SSH keys, or even manipulate service account tokens stored on the host. 2. `Container Escape`: Allowing `hostPath` volumes can lead to container escape. For example, mounting `/proc/sys/kernel/core_pattern` allows an attacker to modify kernel parameters that could lead to executing commands on the host itself. 3. `Data Exposure and Manipulation`: By mounting sensitive directories like `/etc/kubernetes/manifests`, an attacker could modify static Pod definitions, causing unintended deployments or persistence on the cluster. 4. `Host Manipulation`: Mounting critical directories such as `/var/lib/kubelet/pods` can expose Pod-specific data, including tokens for service accounts, secrets, and configMaps, which could be used to move laterally across the cluster. 5. `Resource Misuse`: Pods with access to the host's filesystem can abuse mounted paths to perform unauthorized actions, such as creating persistent data outside of the Kubernetes control, leading to resource leaks or disk space exhaustion. 6. `Configuration Drift`: Pods that use `hostPath` can behave unpredictably depending on the specific files and directories available on different nodes. This inconsistency can lead to unexpected behavior and difficult-to-troubleshoot issues. ### Kyverno Policy Refer to the Nirmata curated policies - [disallow-host-path.yaml](https://github.com/nirmata/kyverno-policies/blob/main/pod-security/baseline/disallow-host-path/disallow-host-path.yaml) ### References #### Configuration Settings The below configuration indicates that HostPath volumes are forbidden. The field `spec.volumes[*].hostPath` must be unset in order to be conformant with this security control. If it is not present, then the resource is conformant by default. ```bash =(volumes): - X(hostPath): "null" ``` #### Resource Example Below is a `Deployment` resource example where even though `volumes` field is present, it does not have a `hostPath` field. If present, it should be set to `null`. ```bash apiVersion: apps/v1 kind: Deployment metadata: name: gooddeployment02 spec: replicas: 1 selector: matchLabels: app: app template: metadata: labels: app: app spec: containers: - name: container01 image: dummyimagename volumeMounts: - name: temp mountPath: /scratch volumes: - name: temp emptyDir: {} ```text --- ## Disallow Host Ports ### Description Access to host ports allows potential snooping of network traffic and should not be allowed, or at minimum restricted to a known list. This control recommends the `hostPort` field is unset or set to `0`. **Restricted Fields** * `spec.containers[*].ports[*].hostPort` * `spec.initContainers[*].ports[*].hostPort` * `spec.ephemeralContainers[*].ports[*].hostPort` **Allowed Values** * Undefined/nil * Known list * 0 ### Risks When `hostPort` field is not unset or set to `0`, we will encounter risks such as: * `Network Snooping`: When a container uses a hostPort, any traffic sent to the host machine on that port is forwarded to the container. An attacker with access to the host machine can potentially monitor or intercept this traffic more easily. * `Scheduling Constraints`: Don't specify a hostPort for a Pod unless it is absolutely necessary. When you bind a Pod to a hostPort, it limits the number of places the Pod can be scheduled, because each `` combination must be unique. If you don't specify the hostIP and protocol explicitly, Kubernetes will use `0.0.0.0` as the default hostIP and TCP as the default protocol. If you only need access to the port for debugging purposes, you can use the apiserver proxy or `kubectl port-forward`. If you explicitly need to expose a Pod's port on the node, consider using a NodePort Service before resorting to hostPort. ### Kyverno Policy Refer to the Nirmata curated policies - [disallow-host-ports.yaml](https://github.com/nirmata/kyverno-policies/blob/main/pod-security/baseline/disallow-host-ports/disallow-host-ports.yaml) ### References #### Configuration Settings Use of host ports is disallowed. In order to be conformant with this security controle, for the resources that include the fields `spec.containers[*].ports[*].hostPort`, `spec.initContainers[*].ports[*].hostPort`, and `spec.ephemeralContainers[*].ports[*].hostPort` must either be unset or set to `0`. ```bash =(ephemeralContainers): - =(ports): - =(hostPort): 0 =(initContainers): - =(ports): - =(hostPort): 0 containers: - =(ports): - =(hostPort): 0 ``` #### Resource Example Below is a `Deployment` resource example where `hostPort` field is not set at all. If present, it should be set to 0. ```bash apiVersion: apps/v1 kind: Deployment metadata: name: gooddeployment spec: replicas: 1 selector: matchLabels: app: app template: metadata: labels: app: app spec: initContainers: - name: initcontainer01 image: dummyimagename - name: initcontainer02 image: dummyimagename ports: - name: web-insecure containerPort: 8080 containers: - name: container01 image: dummyimagename ports: - name: web-insecure containerPort: 8080 ```text --- ## Disallow Host Process ### Description Windows pods offer the ability to run [HostProcess containers](https://kubernetes.io/docs/tasks/configure-pod-container/create-hostprocess-pod) which enables privileged access to the Windows node. Privileged access to the host is disallowed in the baseline policy. HostProcess pods are stable as of Kubernetes 1.26. **Restricted Fields** * spec.securityContext.windowsOptions.hostProcess * spec.containers[*].securityContext.windowsOptions.hostProcess * spec.initContainers[*].securityContext.windowsOptions.hostProcess * spec.ephemeralContainers[*].securityContext.windowsOptions.hostProcess **Allowed Values** * Undefined/nil * false ### Risks HostProcess determines if a container should be run as a 'Host Process' container. All of a Pod's containers must have the same effective HostProcess value (it is not allowed to have a mix of HostProcess containers and non-HostProcess containers). In addition, if HostProcess is true then HostNetwork must also be set to true. When `hostProcess` is set to `true`, we will encounter the following risks: * `Privileged Access`: Windows HostProcess containers run with elevated privileges on the host node. This grants them the ability to interact directly with the Windows host system, * `Network Traffic Snooping`: Enabling `hostNetwork` allows a pod to access the node's network namespace, which includes the ability to monitor all network traffic on the node. This could lead to sensitive data exposure if an attacker manages to deploy a malicious pod that can snoop on network communications. * `Access Services Bound to Localhost`: You can gain access to services that are only available on the host's loopback interface or are otherwise restricted by network policies. These services could present opportunities for privilege escalation. * `Bypassing Network Policies`: When a pod is deployed with `hostNetwork: true`, it can bypass restrictive network policies applied to the namespace. This occurs because the pod is bound to the host's network interfaces rather than being confined to the network restrictions at the pod level. ### Kyverno Policy Refer to the Nirmata curated policies - [disallow-host-process.yaml](https://github.com/nirmata/kyverno-policies/blob/main/pod-security/baseline/disallow-host-process/disallow-host-process.yaml) ### References #### Configuration Settings The below configuration indicates that if the deployed resource contains one of `ephemeralContainers` or `initContainers` or `containers` in their `spec` field, **AND** if `securityContext.windowsOptions.hostProcess`, field is present, then the only acceptable value is `false` to be conformant with this security control. If the `securityContext.windowsOptions.hostProcess` field is not present, then the resource is conformant by default. ```bash =(ephemeralContainers): - =(securityContext): =(windowsOptions): =(hostProcess): "false" =(initContainers): - =(securityContext): =(windowsOptions): =(hostProcess): "false" containers: - =(securityContext): =(windowsOptions): =(hostProcess): "false" ``` #### Resource Example Below is a `Deployment` resource example where `securityContext.windowsOptions.hostProcess` is set to `false` for both `initContainers` and `containers`. ```bash apiVersion: apps/v1 kind: Deployment metadata: name: gooddeployment spec: replicas: 1 selector: matchLabels: app: app template: metadata: labels: app: app spec: hostNetwork: true initContainers: - name: initcontainer01 image: dummyimagename securityContext: windowsOptions: hostProcess: false - name: initcontainer02 image: dummyimagename containers: - name: container01 image: dummyimagename securityContext: windowsOptions: hostProcess: false ```text --- ## Disallow Privileged Containers ### Description Privileged mode disables most security mechanisms and must not be allowed. This control ensures Pods do not call for privileged mode. **Restricted Fields** * spec.containers[*].securityContext.privileged * spec.initContainers[*].securityContext.privileged * spec.ephemeralContainers[*].securityContext.privileged **Allowed Values** * Undefined/nil * false ### Risks When `privileged` is set to `true`, we will encounter the following risks: * `Root Access on Host`: When a container is run in privileged mode, the root user inside the container has the same privileges as the root user on the host system. This bypasses the usual container isolation mechanisms and can cause security risks. For instance, if an attacker gains access to a privileged container, they can compromise the entire host system. * `Device and Capability Access`: Privileged mode lifts all limitations enforced by the device cgroup controller, allowing the container to interact with all devices on the host. This unrestricted access can be used by attackers to exploit critical system components or access sensitive data. * `Potential Exploitation`: If an attacker manages to exploit a vulnerability within an application running inside a privileged container (e.g., a Remote Code Execution vulnerability), they can use this access to escape the container and compromise the host system. ### Kyverno Policy Refer to the Nirmata curated policies - [disallow-privileged-containers.yaml](https://github.com/nirmata/kyverno-policies/blob/main/pod-security/baseline/disallow-privileged-containers/disallow-privileged-containers.yaml) ### References #### Configuration Settings The below configuration indicates that if the deployed resource contains one of `ephemeralContainers` or `initContainers` or `containers` in their `spec` field, **AND** if `securityContex.privileged` field is present, then the only acceptable value is `false` to be conformant with this security control. If the `securityContext.privileged` field is not present, then the resource is conformant by default. ```bash =(ephemeralContainers): - =(securityContext): =(privileged): "false" =(initContainers): - =(securityContext): =(privileged): "false" containers: - =(securityContext): =(privileged): "false" ``` #### Resource Example Below is a `Deployment` resource example where `securityContext.privileged` is set to `false` for both `initContainers` and `containers`. ```bash apiVersion: apps/v1 kind: Deployment metadata: name: gooddeployment spec: replicas: 1 selector: matchLabels: app: app template: metadata: labels: app: app spec: initContainers: - name: initcontainer01 image: dummyimagename securityContext: privileged: false - name: initcontainer02 image: dummyimagename containers: - name: container01 image: dummyimagename securityContext: privileged: false ```text --- ## Disallow Proc Mount ### Description The default /proc masks are set up to reduce attack surface, and should be required. This security control ensures nothing but the default procMount can be specified. **Restricted Fields** * spec.containers[*].securityContext.procMount * spec.initContainers[*].securityContext.procMount * spec.ephemeralContainers[*].securityContext.procMount **Allowed Values** * Undefined/nil * Default ### Risks It is recommended that you use the `Default` procMount as it defaults for readonly and masked paths for `/proc`. Most container runtimes mask certain paths in `/proc` to avoid accidental security exposure of special devices or information. When `procMount` is set to `Unmasked`, we encounter the following risks: * `Exposure of Sensitive Information`: With "Unmasked", the container has access to the entire `/proc` filesystem without restrictions. This can expose sensitive information about the host such as `cpuinfo`, `devices`, `diskstats` and other system related information. * `Increased Attack Surface`: An unmasked `/proc` can reveal detailed information about system processes and kernel internals. This can assist attackers in crafting more targeted attacks or exploits. ### Kyverno Policy Refer to the Nirmata curated policies - [disallow-proc-mount.yaml](https://github.com/nirmata/kyverno-policies/blob/main/pod-security/baseline/disallow-proc-mount/disallow-proc-mount.yaml) ### References #### Configuration Settings The below configuration indicates that if the deployed resource contains one of `ephemeralContainers` or `initContainers` or `containers` in their `spec` field, **AND** if `securityContext.procMount` field is present, then the only acceptable value is `Default` to be conformant with this security control. If the `securityContext` field is not present, then the resource is conformant by default. ```bash =(ephemeralContainers): - =(securityContext): =(procMount): "Default" =(initContainers): - =(securityContext): =(procMount): "Default" containers: - =(securityContext): =(procMount): "Default" ``` #### Resource Example Below is a `Deployment` resource example where `securityContext.procMount` is set to `Default` for both `initContainers` and `containers`. ```bash apiVersion: apps/v1 kind: Deployment metadata: name: gooddeployment spec: replicas: 1 selector: matchLabels: app: app template: metadata: labels: app: app spec: initContainers: - name: initcontainer01 image: dummyimagename securityContext: procMount: Default - name: initcontainer02 image: dummyimagename containers: - name: container01 image: dummyimagename securityContext: procMount: Default ```text --- ## Disallow SELinux ### Description Setting the SELinux type is restricted, and setting a custom SELinux user or role option is forbidden. **Restricted Fields for SELinux type** * spec.securityContext.seLinuxOptions.type * spec.containers[*].securityContext.seLinuxOptions.type * spec.initContainers[*].securityContext.seLinuxOptions.type * spec.ephemeralContainers[*].securityContext.seLinuxOptions.type **Allowed Values for SELinux type** * Undefined/"" * container_t * container_init_t * container_kvm_t **Restricted Fields for SELinux user** * spec.securityContext.seLinuxOptions.user * spec.containers[*].securityContext.seLinuxOptions.user * spec.initContainers[*].securityContext.seLinuxOptions.user * spec.ephemeralContainers[*].securityContext.seLinuxOptions.user * spec.securityContext.seLinuxOptions.role * spec.containers[*].securityContext.seLinuxOptions.role * spec.initContainers[*].securityContext.seLinuxOptions.role * spec.ephemeralContainers[*].securityContext.seLinuxOptions.role **Allowed Values for SELinux user** * Undefined/"" ### Risks Privilege escalation may result from allowing users, roles, or custom SELinux types that are not part of the predefined set (`container_t`, `container_init_t`, `container_kvm_t`). Configurations of SELinux that are too liberal or customized may provide containers greater access than necessary. ### Kyverno Policy Refer to the Nirmata curated policies - [disallow-selinux.yaml](https://github.com/nirmata/kyverno-policies/blob/main/pod-security/baseline/disallow-selinux/disallow-selinux.yaml) ### References #### Configuration Settings The below configuration indicates that if the deployed resource contains one of `ephemeralContainers` or `initContainers` or `containers` in their `spec` field, **AND** if `securityContext.seLinuxOptions.type` field is present, then the only acceptable value is `container_t`, `container_init_t`, or `container_kvm_t` to be conformant with this security control. If the `securityContext` field is not present, then the resource is conformant by default. ```bash =(securityContext): =(seLinuxOptions): =(type): "container_t | container_init_t | container_kvm_t" =(ephemeralContainers): - =(securityContext): =(seLinuxOptions): =(type): "container_t | container_init_t | container_kvm_t" =(initContainers): - =(securityContext): =(seLinuxOptions): =(type): "container_t | container_init_t | container_kvm_t" containers: - =(securityContext): =(seLinuxOptions): =(type): "container_t | container_init_t | container_kvm_t" ``` The below configuration indicates that if the deployed resource contains one of `ephemeralContainers` or `initContainers` or `containers` in their `spec` field, **AND** if `securityContext.seLinuxOptions.user` or `securityContext.seLinuxOptions.role` field is present, then the only acceptable value is `container_t`, `container_init_t`, or `container_kvm_t` to be conformant with this security control. If the `securityContext` field is not present, then the resource is conformant by default. ```bash =(securityContext): =(seLinuxOptions): X(user): "null" X(role): "null" =(ephemeralContainers): - =(securityContext): =(seLinuxOptions): X(user): "null" X(role): "null" =(initContainers): - =(securityContext): =(seLinuxOptions): X(user): "null" X(role): "null" containers: - =(securityContext): =(seLinuxOptions): X(user): "null" X(role): "null" ``` #### Resource Example Below is a `Deployment` resource example where `securityContext.seLinuxOptions.type` is set to one of `container_init_t`, `container_t`, or `container_kvm_t` for both `initContainers` and `containers`. ```bash apiVersion: apps/v1 kind: Deployment metadata: name: gooddeployment spec: replicas: 1 selector: matchLabels: app: app template: metadata: labels: app: app spec: initContainers: - name: initcontainer01 image: dummyimagename securityContext: seLinuxOptions: type: container_init_t - name: initcontainer02 image: dummyimagename securityContext: seLinuxOptions: type: container_t containers: - name: container01 image: dummyimagename ``` Below is a `Deployment` resource example where `securityContext.seLinuxOptions.type` is set to one of `container_init_t`, `container_t`, or `container_kvm_t` and `securityContext.seLinuxOptions.user` and `securityContext.seLinuxOptions.role` is not defined for both `initContainers` and `containers`. ```bash apiVersion: apps/v1 kind: Deployment metadata: name: selur-gooddeployment spec: replicas: 1 selector: matchLabels: app: app template: metadata: labels: app: app spec: initContainers: - name: initcontainer01 image: dummyimagename securityContext: seLinuxOptions: type: container_t - name: initcontainer02 image: dummyimagename securityContext: seLinuxOptions: level: "s0:c123,c456" containers: - name: container01 image: dummyimagename ```text --- ## Restrict Apparmor Profiles ### Description On supported hosts, the runtime/default AppArmor profile is applied by default. The baseline policy should prevent overriding or disabling the default AppArmor profile, or restrict overrides to an allowed set of profiles. **Restricted Fields** * metadata.annotations["container.apparmor.security.beta.kubernetes.io/*"] **Allowed Values** * Undefined/nil * runtime/default * localhost/* ### Risks Risks associated with overriding default or allowed set of profiles: * `Compromising Default Security`: The key idea is to ensure that only approved profiles are used, and that the security provided by the default profiles is not compromised. The default profile is designed to provide a baseline level of security, and bypassing it might expose containers to to potential attacks that the default profile would otherwise prevent. * `Misconfiguration of Custom Profiles`: Custom profiles specified must be accurately defined and thoroughly tested. Misconfigured profiles can provide more permissions than intended or fail to enforce necessary restrictions. ### Kyverno Policy Refer to the Nirmata curated policies - [restrict-apparmor-profiles.yaml](https://github.com/nirmata/kyverno-policies/blob/main/pod-security/baseline/restrict-apparmor-profiles/restrict-apparmor-profiles.yaml) ### References #### Configuration Settings Specifying other AppArmor profiles is disallowed. The annotation `container.apparmor.security.beta.kubernetes.io` if defined must not be set to anything other than `runtime/default` or `localhost/*`. ```bash =(metadata): =(annotations): =(container.apparmor.security.beta.kubernetes.io/*): "runtime/default | localhost/*" ``` #### Resource Example Below is a `Deployment` resource example where the annotation `container.apparmor.security.beta.kubernetes.io/container01` value is set to `runtime/default`. Another accepted value is `localhost/*` (example, `localhost/foo`). ```bash apiVersion: apps/v1 kind: Deployment metadata: name: gooddeployment02 spec: replicas: 1 selector: matchLabels: app: app template: metadata: labels: app: app annotations: container.apparmor.security.beta.kubernetes.io/container01: runtime/default spec: containers: - name: container01 image: dummyimagename ```text --- ## Restrict Seccomp ### Description Seccomp, stands for 'Secure Computing Mode,' and is a security mechanism within the Linux kernel. It functions by limiting the system calls that a process is allowed to execute. Since system calls serve as the primary interface between user applications and the kernel, controlling them through seccomp effectively safeguards the kernel, thereby protecting the host system and reinforcing the isolation that containers rely on. This policy ensures that Seccomp profile is not explicitly set to Unconfined. **Restricted Fields** * spec.securityContext.seccompProfile.type * spec.containers[*].securityContext.seccompProfile.type * spec.initContainers[*].securityContext.seccompProfile.type * spec.ephemeralContainers[*].securityContext.seccompProfile.type **Allowed Values** * Undefined/nil * RuntimeDefault * Localhost ### Risks Seccomp operates based on rules that are present within a file called seccomp profile. It is recommended that users do not use the `Unconfined` profile as it allows containers to invoke any syscall. Many syscalls are harmless, but others can be used to escalate privileges, adjust kernel settings, or perform other undesirable actions. Having a seccomp profile in place can help reduce the attack surface by restricting the syscalls that can be made. ### Kyverno Policy Refer to the Nirmata curated policies - [restrict-seccomp.yaml](https://github.com/nirmata/kyverno-policies/blob/main/pod-security/baseline/restrict-seccomp/restrict-seccomp.yaml) ### References #### Configuration Settings The below configuration indicates that if the deployed resource contains one of `ephemeralContainers` or `initContainers` or `containers` in their `spec` field, **AND** if `securityContext.seccompProfile.type` field is present, then the only acceptable values are `RuntimeDefault` or `Localhost` to be conformant with this security control. If the `securityContext.seccompProfile.type` field is not present, then the resource is conformant by default. ```bash =(securityContext): =(seccompProfile): =(type): "RuntimeDefault | Localhost" =(ephemeralContainers): - =(securityContext): =(seccompProfile): =(type): "RuntimeDefault | Localhost" =(initContainers): - =(securityContext): =(seccompProfile): =(type): "RuntimeDefault | Localhost" containers: - =(securityContext): =(seccompProfile): =(type): "RuntimeDefault | Localhost" ``` #### Resource Example Below is a `Deployment` resource example where `securityContext.seccompProfile.type` is set to either `Localhost` or `RuntimeDefault` for both `initContainers` and `containers`. ```bash apiVersion: apps/v1 kind: Deployment metadata: name: gooddeployment spec: replicas: 1 selector: matchLabels: app: app template: metadata: labels: app: app spec: initContainers: - name: initcontainer01 image: dummyimagename securityContext: seccompProfile: type: Localhost localhostProfile: operator/default/profile1.json - name: initcontainer02 image: dummyimagename securityContext: seccompProfile: type: RuntimeDefault containers: - name: container01 image: dummyimagename ```text --- ## Restrict Sysctls ### Description Sysctls can disable security mechanisms or affect all containers on a host, and should be disallowed except for an allowed "safe" subset. A sysctl is considered safe if it is namespaced in the container or the Pod, and it is isolated from other Pods or processes on the same Node. **Restricted Fields** * spec.securityContext.sysctls[*].name **Allowed Values** * Undefined/nil * kernel.shm_rmid_forced * net.ipv4.ip_local_port_range * net.ipv4.ip_unprivileged_port_start * net.ipv4.tcp_syncookies * net.ipv4.ping_group_range ### Risks Improper configuration of sysctls can pose security risks. Only an allowed "safe" subset of sysctls should be permitted, ensuring they are namespaced in the container or the Pod and isolated from other Pods or processes on the same Node. * `Device Parameters`: Modifications can affect device behavior. For example, altering kernel parameters related to device drivers might introduce vulnerabilities and other performance issues. * `Network Parameters`: For instance, tweaking parameters related to TCP/IP stack might expose the system to attacks or reduce its ability to handle network traffic efficiently. . * `File System`: Sysctls affecting file system behavior can lead to data corruption or security breaches. * `NFS (Network File System)`: Changes to sysctls related to NFS could impact the reliability and security of file sharing across networked systems. Misconfigurations may result in data loss or unauthorized access to shared resources. ### Kyverno Policy Refer to the Nirmata curated policies - [restrict-sysctls.yaml](https://github.com/nirmata/kyverno-policies/blob/main/pod-security/baseline/restrict-sysctls/restrict-sysctls.yaml) ### References #### Configuration Settings Setting additional sysctls above the allowed type is disallowed. The field `spec.securityContext.sysctls` must be unset or not use any other names than `kernel.shm_rmid_forced`, `net.ipv4.ip_local_port_range`, `net.ipv4.ip_unprivileged_port_start`, `net.ipv4.tcp_syncookies` and `net.ipv4.ping_group_range`. ```bash =(securityContext): =(sysctls): - =(name): "kernel.shm_rmid_forced | net.ipv4.ip_local_port_range | net.ipv4.ip_unprivileged_port_start | net.ipv4.tcp_syncookies | net.ipv4.ping_group_range" ``` #### Resource Example Below is a `Deployment` resource example where `securityContext.sysctls` is set to `net.ipv4.tcp_syncookies` for all `containers`. This value is from the subset of "safe" system controls. ```bash apiVersion: apps/v1 kind: Deployment metadata: name: gooddeployment05 spec: replicas: 1 selector: matchLabels: app: app template: metadata: labels: app: app spec: containers: - name: container01 image: dummyimagename securityContext: sysctls: - name: net.ipv4.tcp_syncookies value: "0" ```text