- Introduction
- Get Started
- Deploy
- In Self-Managed Kubernetes
- In Public Cloud Kubernetes
- Deploy TiDB on ARM64 Machines
- Deploy TiFlash to Explore TiDB HTAP
- Deploy TiDB Across Multiple Kubernetes Clusters
- Deploy a Heterogeneous TiDB Cluster
- Deploy TiCDC
- Deploy TiDB Binlog
- Monitor and Alert
- Migrate
- Import Data
- Migrate from MySQL
- Migrate TiDB to Kubernetes
- Manage
- Secure
- Scale
- Upgrade
- Upgrade a TiDB Cluster
- Upgrade TiDB Operator
- Backup and Restore
- Overview
- Backup and Restore Custom Resources
- Grant Permissions to Remote Storage
- Amazon S3 Compatible Storage
- Google Cloud Storage
- Persistent Volumes
- Maintain
- Restart a TiDB Cluster
- Destroy a TiDB Cluster
- View TiDB Logs
- Modify TiDB Cluster Configuration
- Configure Automatic Failover
- Pause Sync of TiDB Cluster
- Maintain Different TiDB Clusters Separately Using Multiple TiDB Operator
- Maintain Kubernetes Nodes
- Migrate from Helm 2 to Helm 3
- Replace Nodes for a TiDB Cluster
- Disaster Recovery
- Troubleshoot
- FAQs
- Reference
- Release Notes
- v1.3
- v1.2
- v1.1
- v1.0
- v0
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 the containers controlled by Custom Resource (CR), you can configure security context in any CRs (TidbCluster
/DmCluster
/TidbInitializer
/TidbMonitor
/Backup
/BackupSchedule
/Restore
) to make the containers run as a non-root user.
You can use either of the following two types of configuration. If you configure both the cluster level and the component level for a component, only the configuration of the component level takes effect.
Configure
podSecurityContext
at the cluster level (spec.podSecurityContext
) for all components. The following is an example configuration:spec: podSecurityContext: runAsUser: 1000 runAsGroup: 2000 fsGroup: 2000
Configure at the component level for a specific component. For example, configuring
spec.tidb.podSecurityContext
forTidbCluster
,spec.master.podSecurityContext
forDMCluster
. The following is an example configuration:spec: pd: podSecurityContext: runAsUser: 1000 runAsGroup: 2000 fsGroup: 2000 tidb: podSecurityContext: runAsUser: 1000 runAsGroup: 2000 fsGroup: 2000