Skip to content

Policy Engine

UDS Core enforces security policies via Pepr admission webhooks. These policies align with the Kubernetes Pod Security Standards (restricted profile) and add Istio-specific controls to prevent unauthorized overrides to service mesh behavior.

Policy names below link to the upstream standard or reference documentation. For how-to guidance on creating exemptions, see Create UDS policy exemptions. For troubleshooting denied or mutated resources, see the Policy Violations runbook.

Exemptions can be specified by an Exemption CR.

If a resource is exempted, it will be annotated as uds-core.pepr.dev/uds-core-policies.<POLICY>: exempted

MutationMutated FieldsMutation Logic
Disallow Privilege Escalationcontainers[].securityContext.allowPrivilegeEscalationMutates allowPrivilegeEscalation to false if undefined, unless the container is privileged or CAP_SYS_ADMIN is added.
Require Non-root UsersecurityContext.runAsUser, runAsGroup, fsGroup, runAsNonRootSets runAsNonRoot: true if undefined. Also defaults runAsUser, runAsGroup, and fsGroup to 1000 if undefined. These defaults can be overridden with the uds/user, uds/group, and uds/fsgroup pod labels.
Drop All Capabilitiescontainers[].securityContext.capabilities.dropEnsures all capabilities are dropped by setting capabilities.drop to ["ALL"] for all containers.
Policy NameExemption NamePolicy Description
Disallow Host NamespacesDisallowHostNamespacesSubject: Pod
Severity: high

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. This policy ensures fields which make use of these host namespaces are set to false.
Disallow NodePort ServicesDisallowNodePortServicesSubject: Service
Severity: medium

A Kubernetes Service of type NodePort uses a host port to receive traffic from any source. A NetworkPolicy cannot be used to control traffic to host ports. Although NodePort Services can be useful, their use must be limited to Services with additional upstream security checks. This policy validates that any new Services do not use the NodePort type.
Disallow Privileged Escalation and PodsDisallowPrivilegedSubject: Pod
Severity: high

Privilege escalation, such as via set-user-ID or set-group-ID file mode, should not be allowed. Privileged mode also disables most security mechanisms and must not be allowed. This policy ensures the allowPrivilegeEscalation field is set to false and privileged is set to false or undefined.
Disallow SELinux OptionsDisallowSELinuxOptionsSubject: Pod
Severity: high

SELinux options can be used to escalate privileges. This policy ensures that the seLinuxOptions specified are not used.
Drop All CapabilitiesDropAllCapabilitiesSubject: Pod
Severity: medium

Capabilities permit privileged actions without giving full root access. All capabilities should be dropped from a Pod, with only those required added back. This policy ensures that all containers explicitly specify drop: ["ALL"].
Require Non-root UserRequireNonRootUserSubject: Pod
Severity: high

Following the least privilege principle, containers should not be run as root. This policy ensures containers either have runAsNonRoot set to true or runAsUser > 0.
Restrict CapabilitiesRestrictCapabilitiesSubject: Pod
Severity: high

Capabilities permit privileged actions without giving full root access. Adding capabilities beyond the default set must not be allowed. This policy ensures users cannot add additional capabilities beyond the allowed list to a Pod.
Restrict External NamesRestrictExternalNamesSubject: Service
Severity: medium

ExternalName services resolve to a DNS CNAME record, which can be used to redirect traffic to malicious endpoints. An attacker can point back to localhost or internal IP addresses for exploitation. This policy restricts services using external names to a specified list.
Restrict hostPath Volume Writable PathsRestrictHostPathWriteSubject: Pod
Severity: medium

hostPath volumes consume the underlying node’s file system. If hostPath volumes are not universally disabled, they should be required to be read-only. Pods which are allowed to mount hostPath volumes in read/write mode pose a security risk even if confined to a “safe” file system on the host and may escape those confines. This policy checks containers for hostPath volumes and validates they are explicitly mounted in readOnly mode.
Restrict Host PortsRestrictHostPortsSubject: Pod
Severity: high

Access to host ports allows potential snooping of network traffic and should not be allowed, or at minimum restricted to a known list. This policy ensures only approved ports are defined in container’s hostPort field.
Restrict Proc MountRestrictProcMountSubject: Pod
Severity: high

The default /proc masks are set up to reduce the attack surface. This policy ensures nothing but the specified procMount can be used. By default only “Default” is allowed.
Restrict SeccompRestrictSeccompSubject: Pod
Severity: high

The SecComp profile should not be explicitly set to Unconfined. This policy, requiring Kubernetes v1.19 or later, ensures that the seccompProfile.Type is undefined or restricted to the values in the allowed list. By default, this is RuntimeDefault or Localhost.
Restrict SELinux TypeRestrictSELinuxTypeSubject: Pod
Severity: high

SELinux options can be used to escalate privileges. This policy ensures that the seLinuxOptions type field is undefined or restricted to the allowed list.
Restrict Istio UserRestrictIstioUserSubject: Pod
Severity: high

The Istio proxy user/group (1337) should only be used by trusted Istio components. This policy enforces that only Istio waypoint pods, Istio gateways, or Istio proxies (sidecars) can run as UID/GID 1337. This prevents unauthorized pods from running with elevated privileges that could be used to bypass security controls.
Restrict Istio Sidecar Configuration OverridesRestrictIstioSidecarOverridesSubject: Pod
Severity: high

Certain Istio sidecar configuration annotations can be used to override secure defaults, potentially introducing security risks. This policy prevents the usage of dangerous Istio annotations that can modify secure sidecar configuration, such as custom proxy images or bootstrap configurations.

Blocked annotations: sidecar.istio.io/bootstrapOverride, sidecar.istio.io/discoveryAddress, sidecar.istio.io/proxyImage, proxy.istio.io/config, sidecar.istio.io/userVolume, sidecar.istio.io/userVolumeMount.
Restrict Istio Traffic Interception OverridesRestrictIstioTrafficOverridesSubject: Pod
Severity: high

Istio traffic annotations or labels can be used to modify how traffic is intercepted and routed, which can lead to security bypasses or unintended network paths. This policy prevents the usage of annotations or labels that can potentially bypass secure networking controls, including disabling sidecar injection via label or annotation.

Blocked annotations: sidecar.istio.io/inject, traffic.sidecar.istio.io/excludeInboundPorts, traffic.sidecar.istio.io/excludeInterfaces, traffic.sidecar.istio.io/excludeOutboundIPRanges, traffic.sidecar.istio.io/excludeOutboundPorts, traffic.sidecar.istio.io/includeInboundPorts, traffic.sidecar.istio.io/includeOutboundIPRanges, traffic.sidecar.istio.io/includeOutboundPorts, sidecar.istio.io/interceptionMode, traffic.sidecar.istio.io/kubevirtInterfaces, istio.io/redirect-virtual-interfaces.

Blocked labels: sidecar.istio.io/inject.
Restrict Istio Ambient Mesh OverridesRestrictIstioAmbientOverridesSubject: Pod
Severity: high

Istio ambient mesh annotations can be used to modify secure mesh behavior. This policy prevents the usage of annotations that could potentially bypass secure ambient mesh controls.

Blocked annotations: ambient.istio.io/bypass-inbound-capture.
Restrict Volume TypesRestrictVolumeTypesSubject: Pod
Severity: medium

Volume types, beyond the core set, should be restricted to limit exposure to potential vulnerabilities in Container Storage Interface (CSI) drivers. In addition, HostPath volumes should not be allowed. Allowed types: configMap, emptyDir, ephemeral, persistentVolumeClaim, secret, projected, downwardAPI, csi.

UDS Core policies were partially inspired by Big Bang Kyverno policies created for the DoD Big Bang platform. The table below maps each policy between the two platforms.

Full policy comparison
UDS Core PolicyNotes
RestrictIstioUserBlocks non-Istio pods from running as UID/GID 1337
RestrictIstioSidecarOverridesBlocks dangerous sidecar configuration annotations
RestrictIstioTrafficOverridesBlocks traffic interception bypass annotations/labels
RestrictIstioAmbientOverridesBlocks ambient mesh bypass annotations
UDS Core PolicyBig Bang PolicyNotes
DisallowHostNamespacesdisallow-host-namespaces
DisallowNodePortServicesdisallow-nodeport-services
DisallowPrivilegeddisallow-privilege-escalationCombined with privileged containers check
DisallowPrivilegeddisallow-privileged-containersCombined with privilege escalation check
DisallowSELinuxOptionsdisallow-selinux-options
DropAllCapabilitiesrequire-drop-all-capabilitiesEnforced as both mutation and validation
RequireNonRootUserrequire-non-root-userEnforced as both mutation and validation
RestrictCapabilitiesrestrict-capabilities
RestrictExternalNamesrestrict-external-names
RestrictHostPathWriterestrict-host-path-write
RestrictHostPortsrestrict-host-ports
RestrictProcMountrestrict-proc-mount
RestrictSeccomprestrict-seccomp
RestrictSELinuxTyperestrict-selinux-type
RestrictVolumeTypesrestrict-volume-types

The following Big Bang Kyverno policies are not yet implemented in UDS Core and will be evaluated for future inclusion.

Big Bang PolicyNotes
restrict-sysctlsPSS Baseline.
restrict-apparmorPSS Baseline.
restrict-host-path-mount-pv
restrict-host-path-mount
restrict-image-registriesIn UDS, Zarf handles registry control at the packaging layer.
require-image-signatureDisabled in Big Bang by default.
restrict-external-ips
require-non-root-groupPartially mitigated — RequireNonRootUser mutation defaults runAsGroup to 1000.
disallow-auto-mount-service-account-tokenAudit-only in Big Bang.