tfmodules/kubernetes
gitops_test a45e39273a sync-modules: mirrored modules of release 3.2.0-F-feature-simpl-31671.658.0f17980a
+++ kubernetes/README.md
+++ kubernetes/ovh/credentials.tf
+++ kubernetes/ovh/variables.tf
2026-09-20 22:02:57 +00:00
..
ovh sync-modules: mirrored modules of release 3.2.0-F-feature-simpl-31671.658.0f17980a 2026-09-20 22:02:57 +00:00
README.md sync-modules: mirrored modules of release 3.2.0-F-feature-simpl-31671.658.0f17980a 2026-09-20 22:02:57 +00:00

kubernetes module

Provisions a managed Kubernetes cluster with one node pool and generates scoped access credentials. One submodule per cloud provider, selected by the provisioner from the cloud provider of the provisioning request:

  • ovh: an OVHcloud Managed Kubernetes Service (MKS) cluster (ovh_cloud_project_kube) with one node pool, public by default, optionally attached to an existing vRack private network

Contract

Variable Description
deployment_id Unique deployment identifier, used in resource names
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 Consumer ServiceAccount name, defaults to simpl-consumer, last segment of the Vault credentials path
credentials_version Opaque rotation marker for the consumer credential, defaults to 1. Changing the value recreates the consumer ServiceAccount and its token Secret, revoking every previously issued consumer token and publishing a fresh credential to Vault. Managed by the credential renewal workflow, not by the deployment script author
admin_username Management (renewer) ServiceAccount name, defaults to simpl-renewer
name_prefix Prefix for resource names, defaults to simpl
region OVH region for the cluster
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
k8s_version, k8s_update_policy Cluster version and upgrade policy
nodepool_* Node pool sizing: flavor, desired/min/max nodes, autoscale, anti affinity, billing
private_network_id, nodes_subnet_id, gateway_ip Optional vRack attachment, all null for a public cluster

Cloud credentials are never module inputs, they reach the provider from the runner environment.

Credentials, following the existing Vault contract: the OVH admin kubeconfig (client certificates) is never delivered. A kubernetes provider chained on the fresh cluster creates, in the same apply, the consumer and the management ServiceAccounts (cluster-admin), each with a non expiring legacy token Secret: credentials stay valid until a renewal is requested, and the renewal revokes them by changing the credentials_version input, which makes Terraform delete and recreate the ServiceAccount and its token Secret in the next apply. Both are delivered as assembled kubeconfigs written by the module to Vault: secret/{provider}/{cloud_account}/{requester_unique_id}/{username} with the consumer kubeconfig (companions: token, server, ca_data) and the admin sibling entry with the root kubeconfig and the management username. No secret material is ever part of an output or of the user body. 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.

Note: this module configures the kubernetes provider internally (chained on the cluster it creates), so the module block must not use count, for_each or depends_on.

Outputs:

Output Description
cluster_id Id of the managed cluster
cluster_name Name of the managed cluster
cluster_url Kubernetes API server endpoint
cluster_version Kubernetes version actually deployed
credentials_ref Vault path of the consumer credentials entry

Usage

The provisioner rewrites the {KUBERNETES_SOURCE} placeholder to this module's location for the cloud provider of the request (each catalog module has a placeholder derived from its directory name), so a deployment script only declares:

module "kubernetes" {
  source              = "{KUBERNETES_SOURCE}"
  deployment_id       = "{UUID}"
  region              = "<region>"
  cloud_account       = "{CLOUD_ACCOUNT}"
  requester_unique_id = "{REQUESTER_UNIQUE_ID}"

  nodepool_flavor        = "b3-8"
  nodepool_desired_nodes = 3
}

output "cluster_url" {
  value = module.kubernetes.cluster_url
}

output "credentials_ref" {
  value = module.kubernetes.credentials_ref
}

The root file must re-export the module outputs it wants published to the deployment outputs.