cloud_deps: read auth0 creds from terraform_remote_state - #45
Conversation
Replace the sops_file-based lookup of auth0_config.yaml with a data.terraform_remote_state.auth0 reference so the cloud_deps state can consume the live values produced by the auth0 terraform run instead of relying on a separately-encrypted committed file. - core_resource_deps.tf: data.sops_file.auth0 -> data.terraform_remote_state.auth0 - variables.tf: new auth0_state_* vars (backend config for the remote state) - provider.tf: drop the sops provider (no longer referenced) Outputs expected on the auth0 state: pixie_client_id, pixie_client_secret.
|
Warning Review limit reached
More reviews will be available in 57 minutes and 57 seconds. Learn how PR review limits work. Your organization has used up its prepaid credits, and credit purchases are no longer available. Enable the review add-on in the billing tab to keep reviews running — you're only billed for reviews past your plan's rate limits ($0.25/file). ⌛ How to resolve this issue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based credits. 🚦 How do rate limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan refill rate. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, the refill rate gradually slows as usage increases. The highest same-day bursts are limited more strictly. Please see our Fair Usage Limits Policy for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: Organization UI Review profile: ASSERTIVE Plan: Pro Plus Run ID: 📒 Files selected for processing (10)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
GitHub Actions
Inactive
Brings the cockpit overlay in line with the SovereignSOC ckp2 deploy:
- cloud_ingress / proxy_envoy / servers_transport / domain_config
all swap pixie.austrianopencloudcommunity.org for
test.austrianopencloudcommunity.org (matches the cloud_domain
tfvar fed into cloud_deps cert-manager, so cert SAN ↔ ingress
host stop conflicting).
- new oauth_config.yaml patches pl-oauth-config away from the hydra
defaults inherited from k8s/cloud_deps/public/configs.yaml.
PL_OAUTH_PROVIDER=auth0 and PL_AUTH_URI point at our auth0
tenant; the auth-server already has the matching client_id /
client_secret via the cloud-auth0-secrets Secret created by
cloud_deps from terraform_remote_state.
- kustomization.yaml: register the new oauth_config patch.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
GitHub Actions
Inactive
kustomize patches: can only modify resources already in the build, but pl-oauth-config lives in k8s/cloud_deps/public/configs.yaml (deployed by terraform, not by cockpit). The previous commit registered it under patches: and kustomize rightly errored: error: no resource matches strategic merge patch "ConfigMap.v1.[noGrp]/pl-oauth-config.[noNs]" Move it to resources: so cockpit emits its own pl-oauth-config; the subsequent kubectl apply overwrites whatever the cloud_deps terraform state previously wrote. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
GitHub Actions
Inactive
The Certificate's issuerRef previously specified only `name`, which makes cert-manager default to `kind: Issuer` (namespaced). For any deployment whose `public_issuer` is a ClusterIssuer — e.g. the `letsencrypt-prod` ClusterIssuer commonly used on Traefik-based clusters — the CertificateRequest then sits forever with: Referenced "Issuer" not found: issuer.cert-manager.io "letsencrypt-prod" not found while the (Cluster)Issuer is right there with Ready=True at the cluster scope. cloud-proxy and vzconn-server consequently can't mount the cloud-proxy-tls-certs Secret and hang in ContainerCreating. Pin the kind explicitly. Hardcoding ClusterIssuer here is fine because nothing else in this repo creates a namespaced public Issuer — the self-signed and pixie-cloud-ca Issuers below are intentionally namespaced and already specify their kinds via the default. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
GitHub Actions
Inactive
ae8e96e to
5af7ad6
Compare
Signed-off-by: Duck <70207455+entlein@users.noreply.github.com>
1 participant
Stacks on top of #44 (cockpit typo fix) which stacks on #41.
Replace the sops_file-based lookup of
terraform/credentials/cockpit/auth0_config.yamlwithdata.terraform_remote_state.auth0. Lets the cloud_deps state consume client_id/secret from the live auth0 terraform state instead of relying on a committed SOPS file (which only contains one specific tenant's values).Changes
core_resource_deps.tf—data.sops_file.auth0→data.terraform_remote_state.auth0;kubernetes_secret_v1.cloud_auth0readsoutputs.pixie_client_id/outputs.pixie_client_secret.variables.tf— newauth0_state_*vars to configure the remote state backend.provider.tf— drop thesopsprovider (no longer used).Required on the auth0 state
The remote state must expose:
output "pixie_client_id"output "pixie_client_secret"(sensitive)These wrap whichever
auth0_client/auth0_client_credentialsresource pair represents Pixie Cloud in the relevant tenant.