Configure OpenShift Security Context Constraints

You can configure Security Context Constraints (SCC) for your OpenShift Dremio deployment. Most SCC settings go in values-openshift-overrides.yaml. Specific scenarios such as strict-SELinux clusters go in values-overrides.yaml.

Dremio's Helm chart includes an opt-in SCC system. An SCC is the recommended way for a vendor to declare the exact security permissions their workloads require. The cluster administrator reviews the SCC, applies it to the cluster, and binds it to the Dremio service accounts via RBAC. The SCC then authorizes Dremio pods to run with the security context they request without weakening the cluster's default restricted-v2 policy for other workloads.

Three values under openshift.scc control this behavior:

values-openshift-overrides.yaml

openshift:
  scc:
    # Render the Dremio SCC + ClusterRole + RoleBindings for every Dremio
    # service account. Requires cluster-admin to apply.
    create: false
    # SCC name. When create=true and name="", renders "dremio-scc".
    # When create=false and name is set, binds Dremio service accounts to an
    # admin-managed SCC by that name (chart renders only RoleBindings).
    name: ""
    # SELinux confinement strategy. Default mirrors nonroot-v2.
    # Set to RunAsAny for strict-SELinux clusters where Dremio workloads need
    # to declare a non-default SELinux type (e.g., spc_t) via their own
    # podSecurityContext.seLinuxOptions.
    seLinuxStrategy: MustRunAs

useOpenShiftRoles: true is already set in values-openshift-overrides.yaml, so the first row below only applies if that value is explicitly removed. The scc.* values are what you configure to opt in.

useOpenShiftRoles	scc.create	scc.name	Result
false	—	—	No-op (no SCC resources rendered)
true	false	""	Default behavior. Two RoleBindings per coordinator/executor service account targeting the built-in nonroot and nonroot-v2 SCCs. Existing deployments are unaffected.
true	false	my-scc	One RoleBinding per Dremio service account targeting system:openshift:scc:my-scc. No SCC manifest rendered. Use this for the admin-managed SCC pattern.
true	true	""	Renders dremio-scc SCC + ClusterRole system:openshift:scc:dremio-scc + RoleBindings for all Dremio service accounts.
true	true	custom	Same as above with a custom SCC name.

When scc is opted in, bindings are applied to the following service accounts: coordinator, engine executor (dynamic), engine operator, catalog-server, catalog-services, mongodb, opensearch, zookeeper, nats, and each entry in executor.engines[] for legacy executor configurations.

Configure Strict-SELinux Clusters

On strict-SELinux clusters (such as OKD with custom container_t hardening), NATS pods may fail to form cluster routes due to a kernel-level denial on port 6222. Because per-OCP/OKD best practices discourage node-side SELinux policy modules, the correct fix is to enable the Dremio SCC with seLinuxStrategy: RunAsAny and then declare the required SELinux type on the affected workload's pod spec.

To unblock NATS, uncomment the SCC and NATS blocks in values-openshift-overrides.yaml. The relevant values are:

values-openshift-overrides.yaml

openshift:
  scc:
    create: true
    seLinuxStrategy: RunAsAny
nats:
  podTemplate:
    merge:
      spec:
        securityContext:
          seLinuxOptions:
            type: spc_t
          runAsNonRoot: true
          runAsUser: 1000
          runAsGroup: 1000
          fsGroup: 1000
          fsGroupChangePolicy: OnRootMismatch
          seccompProfile:
            type: RuntimeDefault
  container:
    merge:
      securityContext:
        runAsNonRoot: true
        runAsUser: 1000
        allowPrivilegeEscalation: false
        readOnlyRootFilesystem: false
        capabilities:
          drop: ["ALL"]
        seccompProfile:
          type: RuntimeDefault

The SCC permits the non-default SELinux type; each workload's pod spec requests it. These are two separate, intentional choices, not defaults. If the same SELinux denial affects ZooKeeper, OpenSearch, or MongoDB once NATS is unblocked, add the corresponding override via each workload's podSecurityContext in values-overrides.yaml:

values-overrides.yaml

zookeeper:
  podSecurityContext:
    seLinuxOptions:
      type: spc_t

Configure Admin-Managed SCC

If your platform team manages SCCs in a GitOps repository and wants to bind Dremio service accounts to an existing SCC without rendering a new one, uncomment Example 2 in values-openshift-overrides.yaml and replace the name with your SCC:

values-openshift-overrides.yaml

openshift:
  scc:
    name: "customer-managed-dremio-scc"

With create: false (the default), the chart skips the SCC manifest and renders only the RoleBindings pointing to the named SCC.