📣
TiDB Cloud Premium is now in public preview. Unlimited growth, instant elasticity, advanced security for enterprise workloads. Try it out →
​
Sign InStart for Free
AI
Developer
Best Practices
API
​
Sign InStart for Free

Run Containers as a Non-root User

In some Kubernetes environments, containers cannot be run as the root user. In this case, you can set securityContext to run containers as a non-root user.

Configure TiDB Operator containers

For TiDB Operator containers, you can configure security context in the Helm values.yaml file. All TiDB Operator components (at <controllerManager/scheduler/advancedStatefulset/admissionWebhook>.securityContext) support this configuration.

The following is an example configuration:

controllerManager:
  securityContext:
    runAsUser: 1000
    runAsGroup: 2000
    fsGroup: 2000

Configure containers controlled by CR

For containers controlled by Custom Resources (CRs), you can configure the security context at the Pod or container level. The supported fields vary by CR.

Configure the Pod-level security context

podSecurityContext defines Pod-level security settings, such as volume ownership, and provides default security settings for all containers in the generated Pod.

For TidbCluster and DMCluster, you can configure podSecurityContext at the following levels:

  • Cluster level: configure spec.podSecurityContext to apply the settings to all components:

    spec:
  podSecurityContext:
    runAsUser: 1000
    runAsGroup: 2000
    fsGroup: 2000

  • Component level: configure spec.<component>.podSecurityContext to apply the settings to a specific component. For example, use spec.tidb.podSecurityContext for the TiDB component of a TidbCluster, or spec.master.podSecurityContext for the master component of a DMCluster:

    spec:
  pd:
    podSecurityContext:
      runAsUser: 1000
      runAsGroup: 2000
      fsGroup: 2000
  tidb:
    podSecurityContext:
      runAsUser: 1000
      runAsGroup: 2000
      fsGroup: 2000

If both levels are configured, the component-level podSecurityContext replaces the cluster-level podSecurityContext for that component.

Other CRs, including TidbDashboard, TidbNGMonitoring, TidbInitializer, TidbMonitor, Backup, BackupSchedule, and Restore, also support Pod-level security context settings. For the supported fields and paths, refer to the API documentation.

Configure the container-level security context

Starting from TiDB Operator v1.6.6, the following CRs support container-level security context:

  • For TidbCluster and DMCluster, configure spec.<component>.securityContext, such as spec.pd.securityContext, spec.tidb.securityContext, spec.master.securityContext, or spec.worker.securityContext. These CRs do not support cluster-level spec.securityContext.
  • For TidbDashboard, configure spec.securityContext.
  • For TidbNGMonitoring, configure spec.ngMonitoring.securityContext. Configuring top-level spec.securityContext has no effect on the generated container.
  • For TidbMonitor, configure securityContext for each generated container. The supported paths include spec.initializer.securityContext, spec.prometheus.securityContext, spec.grafana.securityContext, spec.reloader.securityContext, spec.prometheusReloader.securityContext, spec.thanos.securityContext, and spec.dm.initializer.securityContext.

TidbInitializer, Backup, BackupSchedule, and Restore do not support container-level securityContext.

For the complete ComponentSpec.securityContext schema, refer to the ComponentSpec API documentation.

For example, the following configuration runs the PD container as a non-root user, sets the group ownership of its volumes, and prevents container processes from gaining more privileges than their parent processes:

spec:
  pd:
    podSecurityContext:
      fsGroup: 2000
    securityContext:
      runAsNonRoot: true
      runAsUser: 1000
      runAsGroup: 2000
      allowPrivilegeEscalation: false

Was this page helpful?