From ade8a7358eb4498a6fd5df6f801ccdb17440a1ac Mon Sep 17 00:00:00 2001 From: gitops_test Date: Thu, 24 Sep 2026 14:59:51 +0000 Subject: [PATCH] sync-modules: mirrored modules of release 3.2.0-F-feature-simpl-31672.683.51d1d4ae +++ dbaas/README.md +++ dbaas/ovh/main.tf +++ dbaas/ovh/variables.tf --- dbaas/README.md | 3 ++- dbaas/ovh/main.tf | 12 ++++++++---- dbaas/ovh/variables.tf | 6 ++++++ 3 files changed, 16 insertions(+), 5 deletions(-) diff --git a/dbaas/README.md b/dbaas/README.md index 035b5af..ae4fc67 100644 --- a/dbaas/README.md +++ b/dbaas/README.md @@ -12,6 +12,7 @@ Provisions a managed database and generates the consumer access credentials. One | `cloud_account` | Cloud account (environment) name, second segment of the Vault credentials path, filled by the provisioner from the cloudAccount header via the `{CLOUD_ACCOUNT}` placeholder | | `requester_unique_id` | Requester unique id, third segment of the Vault credentials path, filled by the provisioner from the requesterUniqueId header via the `{REQUESTER_UNIQUE_ID}` placeholder | | `username` | Database user name, defaults to `simpl_app_user`, last segment of the Vault credentials path | +| `credentials_version` | Opaque rotation marker for the database user credential, defaults to `1`. Changing the value makes OVHcloud regenerate the user password and republishes the fresh credential to Vault. Managed by the credential renewal workflow, not by the deployment script author | | `name_prefix` | Prefix for resource names, defaults to `simpl` | | `region` | OVH macro region for the database nodes (for example SBG, GRA, DE), not the datacenter suffixed region used for instances | | `project_id` | Optional override of the OVH project; by default the provider resolves it from the `OVH_CLOUD_PROJECT_SERVICE` variable of the runner environment, which the provisioner derives from the `OVH_PROJECT_ID` key of the cloud account configuration | @@ -22,7 +23,7 @@ Provisions a managed database and generates the consumer access credentials. One Cloud credentials are never module inputs, they reach the provider from the runner environment. -Credentials, following the existing Vault contract: the OVHcloud managed database password is always generated server side (it cannot be set to an arbitrary value), read from the computed attribute of the user resource and written by the module to Vault: `secret/{provider}/{cloud_account}/{requester_unique_id}/{username}` with the keys username, password, host, port, database and a ready to use connection uri. No secret material is ever part of an output or of the user body. There is no admin sibling entry: day 2 credential renewal follows the same Terraform rotation flow as the other catalog modules, making OVHcloud regenerate the password and republishing the Vault entry in the same apply (the rotation marker input is added by the credential renewal ticket). The Vault provider configuration is generated by the provisioner next to the deployment script, and it authenticates through the Vault Kubernetes auth method with the service account of the Terraform runner, against a Vault role configured at installation time. +Credentials, following the existing Vault contract: the OVHcloud managed database password is always generated server side (it cannot be set to an arbitrary value), read from the computed attribute of the user resource and written by the module to Vault: `secret/{provider}/{cloud_account}/{requester_unique_id}/{username}` with the keys username, password, host, port, database and a ready to use connection uri. No secret material is ever part of an output or of the user body. There is no admin sibling entry: day 2 credential renewal follows the same Terraform rotation flow as the other catalog modules, changing the `credentials_version` input, which makes OVHcloud regenerate the password server side and republishes the Vault entry in the same apply. The Vault provider configuration is generated by the provisioner next to the deployment script, and it authenticates through the Vault Kubernetes auth method with the service account of the Terraform runner, against a Vault role configured at installation time. Outputs: diff --git a/dbaas/ovh/main.tf b/dbaas/ovh/main.tf index 92a0279..0f81873 100644 --- a/dbaas/ovh/main.tf +++ b/dbaas/ovh/main.tf @@ -33,11 +33,15 @@ resource "ovh_cloud_project_database_database" "this" { // The user password is ALWAYS generated server side by OVHcloud, it cannot // be set to an arbitrary value: it is read from the computed .password -// attribute and delivered only through the Vault entry. +// attribute and delivered only through the Vault entry. password_reset is +// the provider's native rotation marker: any change to credentials_version +// makes OVHcloud regenerate the password in place, and the Vault entry is +// updated with the fresh credential in the same apply. resource "ovh_cloud_project_database_postgresql_user" "this" { - service_name = ovh_cloud_project_database.this.service_name - cluster_id = ovh_cloud_project_database.this.id - name = var.username + service_name = ovh_cloud_project_database.this.service_name + cluster_id = ovh_cloud_project_database.this.id + name = var.username + password_reset = var.credentials_version // Serialize operations against the cluster: OVH DBaaS processes one // operation at a time per cluster, and concurrent destroys (user + diff --git a/dbaas/ovh/variables.tf b/dbaas/ovh/variables.tf index 1ca6164..f594118 100644 --- a/dbaas/ovh/variables.tf +++ b/dbaas/ovh/variables.tf @@ -36,6 +36,12 @@ variable "username" { default = "simpl_app_user" } +variable "credentials_version" { + description = "Opaque rotation marker for the database user credential. Changing the value makes OVHcloud regenerate the user password server side and republishes the fresh credential to Vault in the same apply. Managed by the credential renewal workflow, not by the deployment script author." + type = string + default = "1" +} + variable "engine_version" { description = "PostgreSQL engine version to provision" type = string