Use declarative operators or Kustomize to manage database users in GitOps, ensuring consistency and auditability across environments.

When deploying components that require database access, user creation must align with GitOps principles: declarative, version-controlled, and automated. Here’s how to handle it without resorting to ad-hoc scripts or manual interventions.

Context

Database user provisioning often involves:

• Creating users with specific grants
• Managing credentials securely
• Ensuring idempotency across environments

Operators (e.g., Percona for MySQL, mariadb-operator) or Kustomize patches can codify these steps. AWS Aurora with IAM authentication introduces additional constraints, but the core GitOps workflow remains similar.

Actionable Workflow

1. Choose an Operator or Method

   • For MySQL: Use Percona XtraDB Cluster Operator or Cloud Native MySQL
   • For MariaDB: Use mariadb-operator
   • For AWS Aurora: Leverage IAM authentication or RDS client tools

2. Define User and Database Resources
   Example Percona XtraDB CRD snippet:

   apiVersion: percona.com/v1alpha1  
   kind: User  
   metadata:  
     name: app-user  
   spec:  
     password: "encrypted-secret-reference"  
     grants:  
     - database: appdb  
       tables:  
       - "*"  
       privileges:  
       - SELECT  
       - INSERT  
       - UPDATE  
   

3. Sync with GitOps Tooling
   Apply manifests via ArgoCD, Flux, or Tekton pipelines. Ensure secrets are managed via SealedSecrets or external vault integration.

4. Validate

   • Check operator logs: kubectl logs -l app=percona-operator
   • Verify user existence in database:

     SELECT User FROM mysql.user;  
     

Policy Example

Enforce user creation via Kustomize patch:

apiVersion: kustomize.config.k8s.io/v1beta1  
kind: Kustomization  
resources:  
  - mysql-user.yaml  
patchesStrategicMerge:  
  - user-grants.patch.yaml  

In user-grants.patch.yaml:

spec:  
  grants:  
  - database: appdb  
    privileges:  
    - SELECT  
    - INSERT  

Tooling

• Operators: Percona XtraDB Operator, mariadb-operator, AWS RDS Controller
• GitOps: ArgoCD (for sync), SealedSecrets (for credentials)
• Validation: mysql-cli pod, PostgreSQL psql client, or database-specific tools

Tradeoffs

• Operators: Reduce boilerplate but add dependency on third-party controllers. Version upgrades can break existing CRDs.
• Kustomize/Helm: More control but require manual patch management. Prone to drift if not strictly enforced.
• AWS Aurora IAM: Centralized auth but limited to AWS environments; complicates cross-cloud portability.

Troubleshooting

• User not created:
  • Check operator CRD status: kubectl describe user app-user
  • Ensure database is reachable from the operator pod (network policies, DNS)
• Permission errors:
  • Validate grants in CRD match database expectations
  • Check for typos in database name (case-sensitive in some systems)
• Sync failures:
  • Verify GitOps tool has permissions to create CRDs
  • Look for duplicate user definitions in other manifests

By codifying user creation alongside application manifests, you eliminate manual steps and ensure parity between environments. Just don’t overlook the operator’s lifecycle management—it’s not set-and-forget.

Source thread: How do you deal with database user creation in Gitops?