--- title: "Restricted profile" url: https://docs.nirmata.io/docs/policy-sets/podsecurity/restricted/ --- The Restricted policy is aimed at enforcing current Pod hardening best practices, at the expense of some compatibility. It is targeted at operators and developers of security-critical applications, as well as lower-trust users. Click on each of the controls to know more about them. - [disallow-capabilities-strict](./disallow-capabilities-strict/) - [disallow-privilege-escalation](./disallow-privilege-escalation/) - [require-run-as-non-root-user](./require-run-as-non-root-user/) - [require-run-as-non-root](./require-run-as-non-root/) - [restrict-seccomp-strict](./restrict-seccomp-strict/) - [restrict-volume-types](./restrict-volume-types/) --- ## Disallow Capabilities Strict ### Description Containers must drop `ALL` capabilities, and are only permitted to add back the `NET_BIND_SERVICE` capability. [This is Linux only policy](https://kubernetes.io/docs/concepts/security/pod-security-standards/#os-specific-policy-controls) in v1.25+ (`.spec.os.name != "windows"`) For `securityContext.capabilities.drop`: **Restricted Fields** * spec.containers[*].securityContext.capabilities.drop * spec.initContainers[*].securityContext.capabilities.drop * spec.ephemeralContainers[*].securityContext.capabilities.drop **Allowed Values** * Any list of capabilities that includes ALL For `securityContext.capabilities.add`: **Restricted Fields** * spec.containers[*].securityContext.capabilities.add * spec.initContainers[*].securityContext.capabilities.add * spec.ephemeralContainers[*].securityContext.capabilities.add **Allowed Values** * Undefined/nil * NET_BIND_SERVICE ### Risks This policy to restrict container capabilities is designed to enhance security by limiting the actions that containers can perform. Without this policy, containers might have access to system capabilities that could be misused. The following are some key risks associated with not enforcing this policy: * `Privilege Escalation`: Allowing containers to gain unnecessary capabilities can lead to privilege escalation. For instance, if a container is granted capabilities like `SYS_MODULE`, it might load malicious kernel modules or alter kernel behavior. * `Service Disruption`: Capabilities like `SYS_BOOT` allow processes to initiate a system reboot. If containers are not restricted from using such capabilities, attackers could cause service interruptions or system downtime. * `Performance Degradation`: Capabilities such as `SYS_NICE` enable processes to adjust priorities and scheduling policies. Unrestricted use of this capability could lead to an issue where an attacker might prioritize their processes over critical system tasks. ### Kyverno Policy Refer to the Nirmata curated policies - [disallow-capabilities-strict.yaml](https://github.com/nirmata/kyverno-policies/blob/main/pod-security/restricted/disallow-capabilities-strict/disallow-capabilities-strict.yaml) ### References #### Configuration Settings The below configuration indicates that in an resource, if `securityContext.capabilities.drop` is present, `ALL` **should** be part of that. ```bash securityContext: capabilities: drop: - ALL ``` The below configuration indicates that in an resource, if `securityContext.capabilities.add` is present, the only acceptable value is `NET_BIND_SERVICE`. Any other value leads to non-conformance with this security control. If `securityContext.capabilities.add` is not present at all, then the resource is conformant by default. ```bash securityContext: capabilities: add: - NET_BIND_SERVICE ``` #### Resource Example Below is a `Deployment` resource example where `securityContext.capabilities.drop` is set to `ALL`. ```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: drop: - ALL ``` Below is a `Deployment` resource example where `securityContext.capabilities.add` is set to `NET_BIND_SERVICE` for both the containers. ```bash apiVersion: apps/v1 kind: Deployment metadata: name: addcap-gooddeployment05 spec: replicas: 1 selector: matchLabels: app: app template: metadata: labels: app: app spec: containers: - name: container01 image: dummyimagename securityContext: capabilities: add: - NET_BIND_SERVICE - name: container02 image: dummyimagename securityContext: capabilities: add: - NET_BIND_SERVICE ```text --- ## Disallow Privilege Escalation ### Description Privilege escalation (such as via set-user-ID or set-group-ID file mode) should not be allowed. [This is Linux only policy](https://kubernetes.io/docs/concepts/security/pod-security-standards/#os-specific-policy-controls) in v1.25+ (`spec.os.name != windows`) **Restricted Fields** * spec.containers[*].securityContext.allowPrivilegeEscalation * spec.initContainers[*].securityContext.allowPrivilegeEscalation * spec.ephemeralContainers[*].securityContext.allowPrivilegeEscalation **Allowed Values** * false ### Risks The `allowPrivilegeEscalation` field controls whether processes in a container can gain more privileges than their parent process. Here are the associated risks if `allowPrivilegeEscalation` is set to `true`: * `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-privilege-escalation.yaml](https://github.com/nirmata/kyverno-policies/blob/main/pod-security/restricted/disallow-privilege-escalation/disallow-privilege-escalation.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.allowPrivilegeEscalation` field is present, then the only acceptable value is `false` to be conformant with this security control. If the `securityContext.allowPrivilegeEscalation` field is not present, then the resource is conformant by default. ```bash =(ephemeralContainers): - securityContext: allowPrivilegeEscalation: "false" =(initContainers): - securityContext: allowPrivilegeEscalation: "false" containers: - securityContext: allowPrivilegeEscalation: "false" ``` #### Resource Example Below is a `Deployment` resource example where `securityContext.allowPrivilegeEscalation` is set to `false` for all `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: allowPrivilegeEscalation: false - name: initcontainer02 image: dummyimagename securityContext: allowPrivilegeEscalation: false containers: - name: container01 image: dummyimagename securityContext: allowPrivilegeEscalation: false - name: container02 image: dummyimagename securityContext: allowPrivilegeEscalation: false ```text --- ## Require Run As Non-root ### Description Containers must be required to run as non-root users. **Restricted Fields** * spec.securityContext.runAsNonRoot * spec.containers[*].securityContext.runAsNonRoot * spec.initContainers[*].securityContext.runAsNonRoot * spec.ephemeralContainers[*].securityContext.runAsNonRoot **Allowed Values** * true *Note:* The container fields may be `undefined/nil` if the pod-level `spec.securityContext.runAsNonRoot` is set to true. ### Risks Here are some risks associated with running containers as root and why setting `runAsNonRoot: true` is important: * `Privilege Escalation`: Running containers as root increases the risk of privilege escalation. An attacker may be able to take over the host system or other containers by exploiting vulnerabilities if they manage to get access to a container that is running as root. Running containers as non-root users reduces this risk and lessens the possible impact of a security breach. * `Unintended Host Modifications`: Root-level containers have the ability to change system-level configurations, which may impact the host system's stability and security. ### Kyverno Policy Refer to the Nirmata curated policies - [require-run-as-nonroot.yaml](https://github.com/nirmata/kyverno-policies/blob/main/pod-security/restricted/require-run-as-nonroot/require-run-as-nonroot.yaml) ### References #### Configuration Settings Running as root is not allowed. Either the field `spec.securityContext.runAsNonRoot` must be set to `true`, or the fields `spec.containers[*].securityContext.runAsNonRoot`, `spec.initContainers[*].securityContext.runAsNonRoot`, and `spec.ephemeralContainers[*].securityContext.runAsNonRoot` must be set to `true`. ```bash securityContext: runAsNonRoot: "true" =(ephemeralContainers): - =(securityContext): =(runAsNonRoot): "true" =(initContainers): - =(securityContext): =(runAsNonRoot): "true" containers: - =(securityContext): =(runAsNonRoot): "true" ``` #### Resource Example Below is a `Deployment` resource example where `spec.securityContext.runAsNonRoot` is set to `true`. It is therefore valid for `containers` field to have `securityContext.runAsNonRoot` undefined. ```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: runAsNonRoot: true ``` Below is a `Deployment` resource example where `spec.securityContext.runAsNonRoot` field is not present. It is therefore absolutely necessary for the `containers` field to have `securityContext.runAsNonRoot` set to true in order for this resource to be conformant with this security control. ```bash apiVersion: apps/v1 kind: Deployment metadata: name: gooddeployment08 spec: replicas: 1 selector: matchLabels: app: app template: metadata: labels: app: app spec: initContainers: - name: initcontainer01 image: dummyimagename securityContext: runAsNonRoot: true containers: - name: container01 image: dummyimagename securityContext: runAsNonRoot: true ```text --- ## Require Run As Non-root User ### Description Containers must not set `runAsUser` to `0`. **Restricted Fields** * spec.securityContext.runAsUser * spec.containers[*].securityContext.runAsUser * spec.initContainers[*].securityContext.runAsUser * spec.ephemeralContainers[*].securityContext.runAsUser **Allowed Values** * any non-zero value * undefined/null ### Risks Here are some risks associated with running containers as the root user: * `Privilege Escalation`: Running containers as root increases the risk of privilege escalation. An attacker may be able to take over the host system or other containers by exploiting vulnerabilities if they manage to get access to a container that is running as root. Running containers as non-root users reduces this risk and lessens the possible impact of a security breach. * `Unintended Host Modifications`: Root-level containers have the ability to change system-level configurations, which may impact the host system's stability and security. ### Kyverno Policy Refer to the Nirmata curated policies - [require-run-as-non-root-user.yaml](https://github.com/nirmata/kyverno-policies/blob/main/pod-security/restricted/require-run-as-non-root-user/require-run-as-non-root-user.yaml) ### References #### Configuration Settings Running as root is not allowed. The fields `spec.securityContext.runAsUser`, `spec.containers[*].securityContext.runAsUser`, `spec.initContainers[*].securityContext.runAsUser`, and `spec.ephemeralContainers[*].securityContext.runAsUser` must be unset or set to a number greater than zero. ```bash =(securityContext): =(runAsUser): ">0" =(ephemeralContainers): - =(securityContext): =(runAsUser): ">0" =(initContainers): - =(securityContext): =(runAsUser): ">0" containers: - =(securityContext): =(runAsUser): ">0" ``` #### Resource Example Below is a `Deployment` resource example where `securityContext.runAsUser` is set to any number other than `0`. ```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: runAsUser: 1 - name: container02 image: dummyimagename securityContext: runAsUser: 2 securityContext: runAsUser: 10 ```text --- ## Restrict Seccomp Strict ### Description Seccomp profile must be explicitly set to one of the allowed values. Both the Unconfined profile and the absence of a profile are prohibited. [This is Linux only policy](https://kubernetes.io/docs/concepts/security/pod-security-standards/#os-specific-policy-controls) in v1.25+ (`spec.os.name != windows`) **Restricted Fields** * spec.securityContext.seccompProfile.type * spec.containers[*].securityContext.seccompProfile.type * spec.initContainers[*].securityContext.seccompProfile.type * spec.ephemeralContainers[*].securityContext.seccompProfile.type **Allowed Values** * 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-strict.yaml](https://github.com/nirmata/kyverno-policies/blob/main/pod-security/restricted/restrict-seccomp-strict/restrict-seccomp-strict.yaml) ### References #### Configuration Settings Use of custom Seccomp profiles is disallowed. The fields `spec.securityContext.seccompProfile.type`, `spec.containers[*].securityContext.seccompProfile.type`, `spec.initContainers[*].securityContext.seccompProfile.type`, and `spec.ephemeralContainers[*].securityContext.seccompProfile.type` must be set to `RuntimeDefault` or `Localhost`. ```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 `RuntimeDefault` or `Localhost` for all `initContainers`, `containers`, and `spec.securityContext`. ```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 securityContext: seccompProfile: type: RuntimeDefault ```text --- ## Restrict Volume Types ### Description In addition to restricting HostPath volumes, the restricted pod security profile limits usage of non-core volume types to those defined through PersistentVolumes. **Restricted Fields** * `spec.volumes[*]` **Allowed Values** Every item in the `spec.volumes[*]` list must set one of the following fields to a non-null value: * `spec.volumes[*].configMap` - Represents a configMap that should populate this volume. * `spec.volumes[*].csi` - Represents ephemeral storage that is handled by certain external CSI drivers. * `spec.volumes[*].downwardAPI` - Represents downward API about the pod that should populate this volume. * `spec.volumes[*].emptyDir` - Represents a temporary directory that shares a pod's lifetime. More info: [EmptyDir](https://kubernetes.io/docs/concepts/storage/volumes#emptydir). * `spec.volumes[*].ephemeral` - Represents a volume that is handled by a cluster storage driver. The volume's lifecycle is tied to the pod that defines it, it will be created before the pod starts, and deleted when the pod is removed. * `spec.volumes[*].persistentVolumeClaim` - Represents a reference to a PersistentVolumeClaim in the same namespace. More info: [PersistentVolumeClaims](https://kubernetes.io/docs/concepts/storage/persistent-volumes#persistentvolumeclaims). * `spec.volumes[*].projected` - Represents projected items for all-in-one resources secrets, configmaps, and downward API. * `spec.volumes[*].secret` - Represents a secret that should populate this volume. More info: [Secret](https://kubernetes.io/docs/concepts/storage/volumes#secret). ### Risks This policy restricts `hostPath` volumes and other non-core volumes. A `hostPath` volume mounts a file or directory from the host node's filesystem into your Pod. This is not something that most Pods will need, but it offers a powerful escape hatch for some applications. There are some risks associated with using `hostPath` volumes: * Access to the host filesystem can expose privileged system credentials (such as for the kubelet) or privileged APIs (such as the container runtime socket), that can be used for container escape or to attack other parts of the cluster. * Pods with identical configuration (such as created from a PodTemplate) may behave differently on different nodes due to different files on the nodes. * `hostPath` volume usage is not treated as ephemeral storage usage. You need to monitor the disk usage by yourself because excessive hostPath disk usage will lead to disk pressure on the node. Also, using Non-core volume types, especially those managed by external systems or third-party plugins, can introduce vulnerabilities. For instance, Container Storage Interface (CSI) drivers might have their own security flaws ### Kyverno Policy Refer to the Nirmata curated policies - [restrict-volume-types.yaml](https://github.com/nirmata/kyverno-policies/blob/main/pod-security/restricted/restrict-volume-types/restrict-volume-types.yaml) ### References #### Configuration Settings The `request.object.spec.volumes[]` should be one of the above mentioned volume types. #### Resource Example Below is a `Deployment` resource example where one of the keys in `volumes[]` is `ephemeral` and it is from the allowed list of volume types. ```bash apiVersion: apps/v1 kind: Deployment metadata: name: gooddeployment06 spec: replicas: 1 selector: matchLabels: app: app template: metadata: labels: app: app spec: containers: - name: container01 image: dummyimagename volumeMounts: - name: ephem mountPath: /ephem volumes: - name: ephem ephemeral: volumeClaimTemplate: metadata: labels: type: my-frontend-volume spec: accessModes: [ "ReadWriteOnce" ] storageClassName: "scratch-storage-class" resources: requests: storage: 1Gi ```text