feat: add T Cloud Public CCE provider support#370
Draft
Matthiator wants to merge 93 commits into
Draft
Conversation
Signed-off-by: Jan Larwig <jan@larwig.com>
Signed-off-by: Jan Larwig <jan@larwig.com>
…ry page Signed-off-by: Jan Larwig <jan@larwig.com>
The OpenTelekomCloud provider marks the identity credential access key as a sensitive attribute, so the root output that surfaces it must declare sensitive = true or terraform apply fails with "Output refers to sensitive values". The secret access key output already had it; this aligns the access key output. terraform output -raw still works for the documented set-env workflow.
Collapse the verbose OpenBao/optional-secret section of the set-env templates. Drop the inline clouds.yaml example, the velero terraform-output command snippets, and the obvious "don't shadow AWS_ACCESS_KEY_ID" note. The optional secrets are now three commented TF_VAR_* exports the user fills in after reading the relevant outputs.
…ed blob Configuring the ExternalDNS webhook no longer means pasting a whole multi-line clouds.yaml into a TF_VAR. The OpenBao secrets.tf-example now builds the clouds.yaml with yamlencode from individual variables: - external_dns_os_username / external_dns_os_password are the only per-deployment values the user sets in set-env - domain, project and region reuse the TF_VAR_t_cloud_public_* values already exported for the other layers set-env replaces the TF_VAR_t_cloud_public_clouds_yaml placeholder with the two scalar credential exports. Tests and the provisioning doc are updated to the field-based form.
Match the clouds.yaml approach for Velero: instead of pasting a whole AWS credentials file into TF_VAR_velero_s3_credentials_cloud, provide the two access keys as scalars and let Terraform assemble the [default] credentials block. - secrets.tf-example: velero_s3_credentials_cloud -> velero_access_key_id + velero_secret_access_key; the resource builds the cloud value inline. - set-env: the single velero export becomes TF_VAR_velero_access_key_id and TF_VAR_velero_secret_access_key (fill from the infrastructure outputs velero_credential_access_key / velero_credential_secret_access_key). - render tests updated.
ESO's Vault kubernetes auth schema has no audiences field directly under auth.kubernetes; the token audiences belong to the ServiceAccountSelector (serviceAccountRef.audiences). The misplaced field made the SecretStore / ClusterSecretStore apply fail with: field not declared in schema: .spec.provider.vault.auth.kubernetes.audiences Move audiences under serviceAccountRef in all six stores (the cluster-wide external-secrets ClusterSecretStore plus the namespaced SecretStores for external-dns, argo-cd, kube-prometheus-stack, oauth2-proxy and velero). The OpenBao k8s-auth roles require the vault audience, so the token must still carry it - just declared in the correct place.
With Traefik forwardAuth, oauth2-proxy reconstructs the originally requested URL as an absolute redirect from the X-Forwarded-* headers and validates it against whitelist_domains. The generated config never set whitelist_domains, so after a successful login every redirect back to the app was rejected with "domain / port not in whitelist" (403 on /oauth2/), dead-ending the user before they reached homer-dashboard / argocd / etc. Add whitelist_domains = [ <cluster dnsName> ] so the post-auth redirect to the cluster host is allowed.
# Conflicts: # docs/content/3_components/backup_and_recovery.md # docs/content/3_components/components_overview.md # src/internal/catalog/built-in/customer-service-catalog/helm/example/velero/values.yaml.tplt # src/internal/catalog/built-in/managed-service-catalog/helm/kyverno-policies/CHANGELOG.md # src/internal/catalog/built-in/managed-service-catalog/helm/kyverno-policies/Chart.yaml # src/internal/catalog/built-in/managed-service-catalog/helm/velero/CHANGELOG.md # src/internal/catalog/built-in/managed-service-catalog/helm/velero/templates/volumesnapshotclass.yaml # src/internal/catalog/built-in/managed-service-catalog/helm/velero/values.yaml # src/internal/catalog/built-in/services/velero.yaml # src/internal/config/factory_test.go # src/internal/config/store_test.go # src/internal/render/render_test.go
Contributor
Author
|
I agree that this PR would benefit from being split before it becomes review-ready. The first step should be to get #366 merged and then rebase this branch, because the current diff still includes the Velero work. After that, I would suggest splitting the remaining T Cloud Public work roughly like this:
This keeps the architectural decisions and shared refactoring separate from the provider implementation, makes each review focused, and avoids asking reviewers to reason about 100+ files at once. We can already prepare the branch split before #366 is merged, but I would avoid opening final review-ready PRs against |
This was referenced Jun 11, 2026
15 tasks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
📝 Summary
Adds T Cloud Public CCE provider support, including generated Terraform stacks for backend bootstrap, cluster infrastructure, OpenBao configuration, provider-specific Helm values, and setup documentation.
Main pieces:
env.auto.tfvarsThis draft currently includes PR #366 in its diff because this branch was built on top of that Velero work. Please merge #366 first; after that this branch should be rebased onto
mainso this PR only shows the T Cloud Public delta.🧩 Type of change
No intended breaking changes. T Cloud Public is added as a new provider path.
🧪 Testing
Ran locally:
make testmake build-binarymake docs-validatemake docs-buildterraform fmt -check -recursive src/internal/catalog/built-in/managed-service-catalog/terraform/providers/t-cloud-public/modules/networkterraform init -backend=falseandterraform validatefor the T Cloud Public network modulegit diff --checkCluster-level validation should be confirmed before marking this PR ready for review.
🔗 Related Issues / Tickets
Depends on #366
✅ Checklist
📎 Additional Context (optional)
Open as draft until PR #366 is merged and this branch has been rebased onto the updated
main.