tfmodules/kubernetes/README.md

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
admin_username	Management (renewer) ServiceAccount name, defaults to simpl-renewer
name_prefix	Prefix for resource names, defaults to simpl
project_id, region	OVH project and region
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
token_ttl_seconds	TTL of the consumer ServiceAccount token, defaults to 3600

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 ServiceAccount (cluster-admin, bound token with TTL) and the management ServiceAccount (cluster-admin, non expiring legacy token Secret, the credential the renewal workflow uses on day 2 and revocable by deleting the ServiceAccount). 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, ttl_seconds) 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 its token comes from the runner environment.

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}"
  project_id          = "<ovh project id>"
  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.