How do you create database users when deploying with GitOps?

November 14, 2026 5 answers
Asked by 1c+foldmark_927

When deploying a new component with GitOps, how do you handle its database user, permissions, and credentials? Can that all be declared alongside the deployment, or does it need a separate provisioning step?

Answers

r71+fusebox_840

Check whether your database operator supports managing users and databases through manifests. CloudNativePG supports this for PostgreSQL, and the MariaDB operator has options for managing database resources too.

That can put the database resources alongside the application deployment in Git. You still need to decide how the password reaches the application and how permissions are managed for your particular database.

1c+foldmark_927:

Does that mean the operator needs permission to create users and grant access in the database?

Merrick.8q:

Yes, the controller needs enough database privileges to manage the resources you ask it to create. Check the operator's documentation for its requirements.

Reply to this answer
7d~turnsignal_418

A secrets manager such as Vault can issue short lived database credentials instead of giving the application a long lived password. The application needs a way to obtain and renew credentials, and the database integration needs enough access to create or manage them.

That doesn't make authorization disappear. You still define what privileges the issued users should have, and the setup depends on the database.

Reply to this answer
Jevrick.82

Terraform is another option for provisioning the database access and generating a password, then wiring the secret into Kubernetes. The tradeoff is that database provisioning and application deployment may live in separate configurations, even if both are automated.

For static secrets, tools such as SOPS or Sealed Secrets can help keep encrypted values in Git. They handle the secret storage problem, not user creation or grants by themselves.

Reply to this answer
6y~checkout_153

Workload identity can reduce the need to distribute a database password where the database supports it. You still have to map that identity to database access and provision the required permissions, so plan for that part in your deployment automation too.

Reply to this answer
7n+buswatch_418

Keep service accounts separate from human database access. A new service may need its own production user, but that doesn't mean people need routine write access there. Set grants according to what each component actually needs and automate credential rotation where you can.

Reply to this answer

Add your answer

Answers are reviewed before publication.

Related Discussions