# Pod Security Standards

Pod Security StandardsA detailed look at the different policy levels defined in the Pod Security Standards.The Pod Security Standards define three different policies to broadly cover the security spectrum. These policies are cumulative and range from highly-permissive to highly-restrictive. This guide outlines the requirements of each policy.ProfileDescriptionPrivilegedUnrestricted policy, providing the widest possible level of permissions. This policy allows for known privilege escalations.BaselineMinimally restrictive policy which prevents known privilege escalations. Allows the default (minimally specified) Pod configuration.RestrictedHeavily restricted policy, following current Pod hardening best practices.Profile DetailsPrivilegedThe Privileged policy is purposely-open, and entirely unrestricted. This type of policy is typically aimed at system- and infrastructure-level workloads managed by privileged, trusted users.The Privileged policy is defined by an absence of restrictions. If you define a Pod where the Privileged security policy applies, the Pod you define is able to bypass typical container isolation mechanisms. For example, you can define a Pod that has access to the node's host network.BaselineThe Baseline policy is aimed at ease of adoption for common containerized workloads while preventing known privilege escalations. This policy is targeted at application operators and developers of non-critical applications. The following listed controls should be enforced/disallowed:Note:In this table, wildcards (*) indicate all elements in a list. For example, spec.containers[*].securityContext refers to the Security Context object for all defined containers. If any of the listed containers fails to meet the requirements, the entire pod will fail validation.Baseline policy specificationControlPolicyHostProcessWindows Pods offer the ability to run HostProcess containers which enables privileged access to the Windows host machine. Privileged access to the host is disallowed in the Baseline policy.FEATURE STATE: Kubernetes v1.26 [stable]Restricted Fieldsspec.securityContext.windowsOptions.hostProcessspec.containers[*].securityContext.windowsOptions.hostProcessspec.initContainers[*].securityContext.windowsOptions.hostProcessspec.ephemeralContainers[*].securityContext.windowsOptions.hostProcessAllowed ValuesUndefined/nilfalseHost NamespacesSharing the host namespaces must be disallowed.Restricted Fieldsspec.hostNetworkspec.hostPIDspec.hostIPCAllowed ValuesUndefined/nilfalsePrivileged ContainersPrivileged Pods disable most security mechanisms and must be disallowed.Restricted Fieldsspec.containers[*].securityContext.privilegedspec.initContainers[*].securityContext.privilegedspec.ephemeralContainers[*].securityContext.privilegedAllowed ValuesUndefined/nilfalseCapabilitiesAdding additional capabilities beyond those listed below must be disallowed.Restricted Fieldsspec.containers[*].securityContext.capabilities.addspec.initContainers[*].securityContext.capabilities.addspec.ephemeralContainers[*].securityContext.capabilities.addAllowed ValuesUndefined/nilAUDIT_WRITECHOWNDAC_OVERRIDEFOWNERFSETIDKILLMKNODNET_BIND_SERVICESETFCAPSETGIDSETPCAPSETUIDSYS_CHROOTHostPath VolumesHostPath volumes must be forbidden.Restricted Fieldsspec.volumes[*].hostPathAllowed ValuesUndefined/nilHost PortsHostPorts should be disallowed entirely (recommended) or restricted to a known listRestricted Fieldsspec.containers[*].ports[*].hostPortspec.initContainers[*].ports[*].hostPortspec.ephemeralContainers[*].ports[*].hostPortAllowed ValuesUndefined/nilKnown list (not supported by the built-in Pod Security Admission controller)0Host Probes / Lifecycle Hooks (v1.34+)The Host field in probes and lifecycle hooks must be disallowed.Restricted Fieldsspec.containers[*].livenessProbe.httpGet.hostspec.containers[*].readinessProbe.httpGet.hostspec.containers[*].startupProbe.httpGet.hostspec.containers[*].livenessProbe.tcpSocket.hostspec.containers[*].readinessProbe.tcpSocket.hostspec.containers[*].startupProbe.tcpSocket.hostspec.containers[*].lifecycle.postStart.tcpSocket.hostspec.containers[*].lifecycle.preStop.tcpSocket.hostspec.containers[*].lifecycle.postStart.httpGet.hostspec.containers[*].lifecycle.preStop.httpGet.hostspec.initContainers[*].livenessProbe.httpGet.hostspec.initContainers[*].readinessProbe.httpGet.hostspec.initContainers[*].startupProbe.httpGet.hostspec.initContainers[*].livenessProbe.tcpSocket.hostspec.initContainers[*].readinessProbe.tcpSocket.hostspec.initContainers[*].startupProbe.tcpSocket.hostspec.initContainers[*].lifecycle.postStart.tcpSocket.hostspec.initContainers[*].lifecycle.preStop.tcpSocket.hostspec.initContainers[*].lifecycle.postStart.httpGet.hostspec.initContainers[*].lifecycle.preStop.httpGet.hostAllowed ValuesUndefined/nil""AppArmorOn supported hosts, the RuntimeDefault 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 Fieldsspec.securityContext.appArmorProfile.typespec.containers[*].securityContext.appArmorProfile.typespec.initContainers[*].securityContext.appArmorProfile.typespec.ephemeralContainers[*].securityContext.appArmorProfile.typeAllowed ValuesUndefined/nilRuntimeDefaultLocalhostmetadata.annotations["container.apparmor.security.beta.kubernetes.io/*"]Allowed ValuesUndefined/nilruntime/defaultlocalhost/*SELinuxSetting the SELinux type is restricted, and setting a custom SELinux user or role option is forbidden.Restricted Fieldsspec.securityContext.seLinuxOptions.typespec.containers[*].securityContext.seLinuxOptions.typespec.initContainers[*].securityContext.seLinuxOptions.typespec.ephemeralContainers[*].securityContext.seLinuxOptions.typeAllowed ValuesUndefined/""container_tcontainer_init_tcontainer_kvm_tcontainer_engine_t (since Kubernetes 1.31)Restricted Fieldsspec.securityContext.seLinuxOptions.userspec.containers[*].securityContext.seLinuxOptions.userspec.initContainers[*].securityContext.seLinuxOptions.userspec.ephemeralContainers[*].securityContext.seLinuxOptions.userspec.securityContext.seLinuxOptions.rolespec.containers[*].securityContext.seLinuxOptions.rolespec.initContainers[*].securityContext.seLinuxOptions.rolespec.ephemeralContainers[*].securityContext.seLinuxOptions.roleAllowed ValuesUndefined/""/proc Mount TypeThe default /proc masks are set up to reduce attack surface, and should be required.Restricted Fieldsspec.containers[*].securityContext.procMountspec.initContainers[*].securityContext.procMountspec.ephemeralContainers[*].securityContext.procMountAllowed ValuesUndefined/nilDefaultSeccompSeccomp profile must not be explicitly set to Unconfined.Restricted Fieldsspec.securityContext.seccompProfile.typespec.containers[*].securityContext.seccompProfile.typespec.initContainers[*].securityContext.seccompProfile.typespec.ephemeralContainers[*].securityContext.seccompProfile.typeAllowed ValuesUndefined/nilRuntimeDefaultLocalhostSysctlsSysctls 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 Fieldsspec.securityContext.sysctls[*].nameAllowed ValuesUndefined/nilkernel.shm_rmid_forcednet.ipv4.ip_local_port_rangenet.ipv4.ip_unprivileged_port_startnet.ipv4.tcp_syncookiesnet.ipv4.ping_group_rangenet.ipv4.ip_local_reserved_ports (since Kubernetes 1.27)net.ipv4.tcp_keepalive_time (since Kubernetes 1.29)net.ipv4.tcp_fin_timeout (since Kubernetes 1.29)net.ipv4.tcp_keepalive_intvl (since Kubernetes 1.29)net.ipv4.tcp_keepalive_probes (since Kubernetes 1.29)RestrictedThe 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. The following listed controls should be enforced/disallowed:Note:In this table, wildcards (*) indicate all elements in a list. For example, spec.containers[*].securityContext refers to the Security Context object for all defined containers. If any of the listed containers fails to meet the requirements, the entire pod will fail validation.Restricted policy specificationControlPolicyEverything from the Baseline policyVolume TypesThe Restricted policy only permits the following volume types.Restricted Fieldsspec.volumes[*]Allowed ValuesEvery item in the spec.volumes[*] list must set one of the following fields to a non-null value:spec.volumes[*].configMapspec.volumes[*].csispec.volumes[*].downwardAPIspec.volumes[*].emptyDirspec.volumes[*].ephemeralspec.volumes[*].persistentVolumeClaimspec.volumes[*].projectedspec.volumes[*].secretPrivilege Escalation (v1.8+)Privilege escalation (such as via set-user-ID or set-group-ID file mode) should not be allowed. This is Linux only policy in v1.25+ (spec.os.name != windows)Restricted Fieldsspec.containers[*].securityContext.allowPrivilegeEscalationspec.initContainers[*].securityContext.allowPrivilegeEscalationspec.ephemeralContainers[*].securityContext.allowPrivilegeEscalationAllowed ValuesfalseRunning as Non-rootContainers must be required to run as non-root users.Restricted Fieldsspec.securityContext.runAsNonRootspec.containers[*].securityContext.runAsNonRootspec.initContainers[*].securityContext.runAsNonRootspec.ephemeralContainers[*].securityContext.runAsNonRootAllowed ValuestrueThe container fields may be undefined/nil if the pod-level spec.securityContext.runAsNonRoot is set to true.Running as Non-root user (v1.23+)Containers must not set runAsUser to 0Restricted Fieldsspec.securityContext.runAsUserspec.containers[*].securityContext.runAsUserspec.initContainers[*].securityContext.runAsUserspec.ephemeralContainers[*].securityContext.runAsUserAllowed Valuesany non-zero valueundefined/nullSeccomp (v1.19+)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 in v1.25+ (spec.os.name != windows)Restricted Fieldsspec.securityContext.seccompProfile.typespec.containers[*].securityContext.seccompProfile.typespec.initContainers[*].securityContext.seccompProfile.typespec.ephemeralContainers[*].securityContext.seccompProfile.typeAllowed ValuesRuntimeDefaultLocalhostThe container fields may be undefined/nil if the pod-level spec.securityContext.seccompProfile.type field is set appropriately. Conversely, the pod-level field may be undefined/nil if _all_ container- level fields are set.Capabilities (v1.22+)Containers must drop ALL capabilities, and are only permitted to add back the NET_BIND_SERVICE capability. This is Linux only policy in v1.25+ (.spec.os.name != "windows")Restricted Fieldsspec.containers[*].securityContext.capabilities.dropspec.initContainers[*].securityContext.capabilities.dropspec.ephemeralContainers[*].securityContext.capabilities.dropAllowed ValuesAny list of capabilities that includes ALLRestricted Fieldsspec.containers[*].securityContext.capabilities.addspec.initContainers[*].securityContext.capabilities.addspec.ephemeralContainers[*].securityContext.capabilities.addAllowed ValuesUndefined/nilNET_BIND_SERVICEPolicy InstantiationDecoupling policy definition from policy instantiation allows for a common understanding and consistent language of policies across clusters, independent of the underlying enforcement mechanism.As mechanisms mature, they will be defined below on a per-policy basis. The methods of enforcement of individual policies are not defined here.Pod Security Admission ControllerPrivileged namespaceBaseline namespaceRestricted namespaceAlternativesNote: This section links to third party projects that provide functionality required by Kubernetes. The Kubernetes project authors aren't responsible for these projects, which are listed alphabetically. To add a project to this list, read the content guide before submitting a change. More information.Other alternatives for enforcing policies are being developed in the Kubernetes ecosystem, such as:KubewardenKyvernoOPA GatekeeperPod OS fieldKubernetes lets you use nodes that run either Linux or Windows. You can mix both kinds of node in one cluster. Windows in Kubernetes has some limitations and differentiators from Linux-based workloads. Specifically, many of the Pod securityContext fields have no effect on Windows.Note:Kubelets prior to v1.24 don't enforce the pod OS field, and if a cluster has nodes on versions earlier than v1.24 the Restricted policies should be pinned to a version prior to v1.25.Restricted Pod Security Standard changesAnother important change, made in Kubernetes v1.25 is that the Restricted policy has been updated to use the pod.spec.os.name field. Based on the OS name, certain policies that are specific to a particular OS can be relaxed for the other OS.OS-specific policy controlsRestrictions on the following controls are only required if .spec.os.name is not windows:Privilege EscalationSeccompLinux CapabilitiesUser namespacesUser Namespaces are a Linux-only feature to run workloads with increased isolation. How they work together with Pod Security Standards is described in the documentation for Pods that use user namespaces.FAQWhy isn't there a profile between Privileged and Baseline?The three profiles defined here have a clear linear progression from most secure (Restricted) to least secure (Privileged), and cover a broad set of workloads. Privileges required above the Baseline policy are typically very application specific, so we do not offer a standard profile in this niche. This is not to say that the privileged profile should always be used in this case, but that policies in this space need to be defined on a case-by-case basis.SIG Auth may reconsider this position in the future, should a clear need for other profiles arise.What's the difference between a security profile and a security context?Security Contexts configure Pods and Containers at runtime. Security contexts are defined as part of the Pod and container specifications in the Pod manifest, and represent parameters to the container runtime.Security profiles are control plane mechanisms to enforce specific settings in the Security Context, as well as other related parameters outside the Security Context. As of July 2021, Pod Security Policies are deprecated in favor of the built-in Pod Security Admission Controller.What about sandboxed Pods?There is currently no API standard that controls whether a Pod is considered sandboxed or not. Sandbox Pods may be identified by the use of a sandboxed runtime (such as gVisor or Kata Containers), but there is no standard definition of what a sandboxed runtime is.The protections necessary for sandboxed workloads can differ from others. For example, the need to restrict privileged permissions is lessened when the workload is isolated from the underlying kernel. This allows for workloads requiring heightened permissions to still be isolated.Additionally, the protection of sandboxed workloads is highly dependent on the method of sandboxing. As such, no single recommended profile is recommended for all sandboxed workloads.Items on this page refer to third party products or projects that provide functionality required by Kubernetes. The Kubernetes project authors aren't responsible for those third-party products or projects. See the CNCF website guidelines for more details.You should read the content guide before proposing a change that adds an extra third-party link.