gitops_test/tfmodules
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

sync-modules: mirrored modules of release 3.2.0-F-feature-simpl-31672.683.51d1d4ae

Browse Source 
+++ dbaas/README.md
+++ dbaas/ovh/main.tf
+++ dbaas/ovh/variables.tf
This commit is contained in:
gitops_test 2026-09-24 14:59:51 +00:00
parent 3668b94644
commit ade8a7358e
3 changed files with 16 additions and 5 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

3
dbaas/README.md
View File

@ -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:

6
dbaas/ovh/main.tf
View File

@ -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
password_reset = var.credentials_version
// Serialize operations against the cluster: OVH DBaaS processes one
// operation at a time per cluster, and concurrent destroys (user +

6
dbaas/ovh/variables.tf
View File

@ -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