Skip to main content
Domino leverages Kubernetes security contexts to deploy pods with the least privileges necessary for them to function. By default, pods created by Domino run with the following settings:
  • Run as a non-root user with runAsRoot: false, runAsNonRoot: true, and privileged: false set.
  • Acquisition of additional system-level capabilities must be prevented with drop: ["ALL"].
Domino does not support a policy where readOnlyRootFilesystem is set. In addition, due to inconsistency between SELinux support and volume relabeling, all Domino pods run with an SELinux type option spc_t. This setting purposefully bypasses volume relabeling due to the performance impact of volume relabeling while creating Domino user workloads. Pods that do not adhere to the policies above, such as requiring root privileges or additional capabilities, are documented below with privileged indicating pods that need additional user or root privileges and capabilities indicated pods that may require additional system-level capabilities.
Pod NameExceptionsDescription
aws-ebs-csi-driver-nodecapabilities
privileged
runAsRoot		Requires access to host node resources to provision and manage AWS EBS volumes for Domino. Is not installed if AWS EBS is not configured as a storage provider during installation.
aws-efs-csi-driver-controllercapabilities
runAsRoot		Requires access to host node resources in order manage AWS EFS volumes for Domino. Is not installed if AWS EFS is not configured as a storage provider during installation.
aws-efs-csi-driver-nodecapabilities
privileged
runAsRoot		Requires access to host node resources in order manage AWS EFS volumes for Domino. Is not installed if AWS EFS is not configured as a storage provider during installation.
csi-driver-smb-controllercapabilities
privileged
runAsRoot		Requires access to host node resources to manage SMB volumes for Domino. Is not installed if SMB volume management is not configured during installation.
csi-driver-smb-linuxcapabilities
privileged
runAsRoot		Requires access to host node resources to manage SMB volumes for Domino. Is not installed if SMB volume management is not configured during installation.
dcgm-exportercapabilities
runAsRoot		Requires access to host node resources to communicate with NVIDIA host engine and expose GPU metrics. Only runs on nodes with NVIDIA GPUs. An option to disable this service is available by setting gpu_monitoring_enabled to false in deploy.yaml
docker-registry-cert-mgrrunAsRootRequires access to host node resources to manage trusted certificates for Docker when Domino is configured to use a self-provided image registry. Is not installed if an external Docker registry is configured during installation.
domino-workbench-backupcapabilities
runAsRoot		Requires privileged access to filesystem resources for data backup.
domino-workbench-backup-checkcapabilities
runAsRoot		Requires privileged access to filesystem resources for data backup.
domino-data-importercapabilities
runAsRoot		Requires privileged access to filesystem resources for disaster recovery and data access. This service does not run by default and must be enabled by admins when needed.
elasticsearch-tlscapabilities
privileged
runAsRoot		Requires privileged access to system to set a mandatory system limit. If the system setting can be managed outside of Domino, elevated privileges can be removed by setting the following: 
elasticsearch:
enable_sysctl: false
falcoprivileged
runAsRoot		Requires access to host node resources to audit system events using eBPF.
fluentdcapabilities
runAsRoot		Requires access to host node resources to follow container logs which are used to view workload output within Domino.
hephaestus-buildkitcapabilities
privileged
runAsRoot		BuildKit powers container image building for the environments feature of Domino. By default, requires privileged access to utilize overlay mounts for performance during container image building. If your operating system supports rootless overlayfs natively, the privileges can be removed by setting the following: 
image_building:
rootless: true
image-caching-agentrunAsRootRequires access to host node resources to communicate with the container runtime when caching container images for faster workload scheduling. Can be disabled by setting the following: 
image_caching:
enabled: false
istio-cni-nodeprivileged
runAsRoot		Requires access to host node resources to facilitate network setup for Istio. Is not installed if Istio is not enabled or the CNI option is disabled.
newrelic-infrastructurecapabilities
privileged
runAsRoot		Requires access to host node resources to effectively monitor CPU, memory, network, and disk usage and report to New Relic. Is not installed if New Relic is not configured for Domino during installation.
newrelic-loggingcapabilities
runAsRoot		Requires access to host node resources to follow container logs and report to New Relic. Is not installed if New Relic is not configured for Domino during installation.
nfs-client-provisionercapabilities
runAsRoot		NFS Client Provisioner requires privileged access to filesystem resources to manage NFS volumes for Domino. Is not installed if NFS is not configured as a storage provider during installation.
nvidia-device-plugincapabilities
privileged
runAsRoot		Requires access to host node resources to communicate with the Kubernetes device API and expose NVIDIA GPU resources to the cluster. Is not installed if GPU capabilities are not configuring during installation.
nvidia-device-plugin-mps-control-daemoncapabilities
privileged
runAsRoot		Requires access to host node resources to communicate with the Kubernetes device API and expose NVIDIA GPU resources to the cluster. Is not installed if GPU capabilities are not configuring during installation.
nvidia-driver-installercapabilities
privileged
runAsRoot		Requires access to host node resources to install and manage NVIDIA drivers for GPU-enabled instance types. Only required for installations on GKE clusters.
openebscapabilities
runAsRoot		Requires access to host node resources to manage storage volumes. Is not installed if OpenEBS is not configured as a storage provider during installation.
smarter-device-managerrunAsRootRequires access to host node resources to communicate with the Kubernetes device API and expose FUSE devices to the cluster.
All user-generated pods from workspaces, jobs, apps, or on-demand compute clusters run with a user and capabilities according to the Configuration record entry for com.cerebro.domino.computegrid.kubernetes.nonRootExecutions.enabled. See Configuration records and non-root executions release notes for details. All user-generated pods from models run as a non-root user but with privilege-escalation capability. Please see Pod Security Policies for an overview of how policies are enforced and specific information about the removal of Pod Security Policies in Kubernetes 1.25.

​
Pod security policies

A Pod Security Policy (PSP) is a cluster-level resource that controls security-sensitive aspects of the pod specification. PodSecurityPolicy objects define a set of conditions that a pod must run with to be accepted into the system, as well as defaults for the related fields. Pod security policies serve two purposes in helping secure a Domino installation:
  • They prevent the admission (creation) of pods in the cluster if their security stance does not meet the defined policy.
  • They mutate (modify) pods that have been allowed by the policy to set defaults matching the PSP (where no values are set).

​
Pod security policy deprecation and removal

As of Kubernetes 1.21, PSPs are a deprecated feature. In Kubernetes 1.25, support for PSPs has been completely removed. To support the removal of Pod Security Policies, Domino 5.4 and above do not create per-service PSPs as part of the installation. Instead, all pods define an explicit security context. This removes the need for duplicate modification of security contexts during pod creation by PSPs. Domino does not support a replacement for runtime policy enforcement. Because Domino controls the definition of all pods created in its namespaces, PSP enforcement of security boundaries after installation (during “runtime”) is not necessary. Domino can control and report (during “build time”) the security context of every pod to ensure all services meet our security standards. See Kubernetes Pod Security for an overview with specifics and exemptions.

​
OpenShift

OpenShift maintains its own version of pod security policies named “Security Context Constraints” and Red Hat has laid out a different evolution for that feature going forward from upstream Kubernetes. Domino does not deploy any custom security contexts but makes use of OpenShift-provided SCCs (anyuid and privileged) bound to all Domino namespaces. Any additional SCCs cause the installation of Domino to fail. In addition, UID remapping is not supported in Domino and all services run as the user ID defined in their container images.

​
Kubernetes < 1.25 support

Domino binds a blanket unrestricted policy for clusters where PSPs are still enabled. Many cluster providers, such as EKS, already do this. If Domino is the only application deployed in a cluster running Kubernetes < 1.25, it is advisable to turn off pod security policy support entirely.
Last modified on July 16, 2026

Related topics

Security at DominoDeploy Domino endpointsKubernetes infrastructureAdvanced hardware tier settings