# CP9 Auth0 secret ownership for Premium and Dedicated

Date: 2026-08-18

Question: when CP9 starts Premium or Dedicated, does it read Auth0 secrets from
the 0414 account (`385595570414`)?

## Conclusion

There are two different paths:

1. **CP9's own Dev Full/session path: no.** Premium and Dedicated use different
   CP9 patch functions, but both stay on the session target account:

   - **Premium:** `account-svc-config` runs with `CP9_ACCOUNT_SESSION_CONTEXT`.
     It uses the session's target-account credentials to read
     `cp9/dev/auth0/account-central-management-m2m` and
     `cp9/dev/auth0/serverless-service`, then writes the merged config to the
     session `account_config_secret` and makes account-central use it.
   - **Dedicated:** the Dedicated-specific proxy patcher reads the Terraform
     `account_config_secret.name` with the session profile and target region,
     then materializes `dedicated-proxy-auth0-client`.

   For the 804 run, both Auth0 Secret Manager paths are in 804, not 0414. The
   0414 account can still appear as an ECR/PCA or management-plane account; that
   is not the Auth0 secret read path.

2. **Real auto-deploy-managed platform workloads: yes for dev, but not as a
   universal rule.** The External Secrets Operator (ESO) role is allowed to
   read `${env}-*` secrets from `local.seed_account`. Dev's seed/control-plane
   account is 0414; production uses its own seed account (the current prod
   metadata and ESO service account point to `380838443567`). The workload
   consumes Kubernetes Secrets; ESO is the AWS Secrets Manager reader.

`o11y_account_id` in the Dedicated Terraform is only an IAM trust principal.
It does not select the Secret Manager account or the secret-name prefix.

The 804 Dedicated initialization performed only IAM, PCA, and RAM work. It did
not read, create, or modify Auth0 secret values.

## Runtime flows

| Path | AWS Secret Manager reader | Secret source | Workload input |
|---|---|---|---|
| CP9 Premium account services | session target-account credentials | `cp9/dev/auth0/account-central-management-m2m` and `cp9/dev/auth0/serverless-service` | merged config is written to target-account `account_config_secret`; account-central reads it |
| CP9 Dedicated proxy | CP9 session runtime profile | target-account `account_config_secret` | `dedicated-proxy-auth0-client` |
| Auto-deploy platform | ESO IRSA role | `${env}-proxy-auth0-client` and `${env}-o11y-auth0-client` in the seed/control-plane account | Kubernetes `proxy-auth0-client` and `o11y-auth0-client` |

## CP9 Starter control flow

`cp9/dev/auth0/serverless-service` is a bundle, not a proxy-only secret. Its
payload contains both `auth0Secret` and `proxyAuth0ClientSecret`.

The CP9 Starter sequence is:

1. Terraform creates/owns the bundle in the session target account.
2. Premium account services run first. Their `account-svc-config` path reads
   the bundle (and the account-central M2M secret) with session credentials and
   writes the merged YAML to the target-account `account_config_secret`.
3. `serverless-service` depends on `account-svc`. Its kustomize helper reads
   that updated `account_config_secret` with the session profile and target
   region, extracts both Auth0 fields, and patches the
   `serverless-service`/`serverless-service-brworker` ConfigMaps.
4. Kubernetes applies the workload. The running Starter service reads the
   ConfigMap; it does not independently select 0414's Secret Manager.

`serverless-global-service` receives the session PCA/KMS/account contract but
does not enter the Starter Auth0 extraction branch. It starts after
`serverless-service` and `account-svc`.

## Evidence

Sources were read at these exact heads:

- CP9 `548220412541d553105dce586303f6f0a0893ffd`
  - `terraform/aws/cp9-substrate/README.md:9-35,48-52,112-120,149-153` — the substrate is per-session, persists `target_account` and `aws_profile`, and explicitly does not create shared Premium/Dedicated product infrastructure.
  - `terraform/cp9-developer/auth0.tf:1-25,28-52` — CP9 owns `cp9/dev/auth0/serverless-service` and `cp9/dev/auth0/account-central-management-m2m` in the runtime region/account.
  - `personas/dev-full/runtime/example.Tiltfile:2054-2088,2090-2100` — Premium `account-svc-config` is applied with `CP9_ACCOUNT_SESSION_CONTEXT`, before the account workloads that depend on it.
  - `personas/dev-full/runtime/example.Tiltfile:2238-2261` and `personas/dev-full/runtime/scripts/apply-aws-creds-secret.sh:121-161,215-321` — `premium-source-aws-credentials` mints the target session credentials used by the Premium account path.
  - `personas/dev-full/runtime/example.Tiltfile:886-895,2684-2717` — Starter local/global resources receive the session context; `serverless-service` depends on `account-svc`, while `serverless-global-service` is downstream of both.
  - `personas/dev-full/runtime/scripts/apply-kustomize-images.sh:797-863,865-1040` — Starter's serverless branch reads `account_config_secret`, extracts `auth0Secret` and `proxyAuth0ClientSecret`, and patches the serverless ConfigMaps.
  - `personas/dev-full/runtime/scripts/apply-kustomize-images.sh:1049-1108` — Dedicated proxy Auth0 reads the Terraform output `account_config_secret.name` using the session runtime profile and target region.
  - `personas/dev-full/runtime/scripts/apply-kustomize-images.sh:1160-1317,1398-1477` — the Premium account path reads the two `cp9/dev/auth0/...` secrets, writes the merged payload to the target-account session secret, and points account-central at it.

- auto-deploy `83d171a6f7ea09740f88c9c80a94db3c04dcfd59`
  - `terraform/aws/premium/iam.tf:22-30` — the ESO module receives `local.seed_account` as `controlplane_account`.
  - `terraform/aws/aws_modules/iam-external-secrets-operator/controlplane/main.tf:34-56` — the ESO policy grants `secretsmanager:GetSecretValue` for `${secret_prefix}-*` in that account.
  - `terraform/aws/region/secret.tf:1-33` — regional Terraform copies `${env}-proxy-auth0-client` and `${env}-o11y-auth0-client` from the us-west-2 source provider.
  - `meta/dev.yaml:4,61-68,76-88` — dev uses the 0414 account for the auto-deploy role/PCA and names `dev-o11y-auth0-client`.
  - `meta/prod.yaml:54-72` — prod uses the `prod-*` secret pair and a different seed/PCA account.

- app-delivery `origin/main` `cbdd23d2d44f7af6c745160e2d6d00deed657781`
  - `secretstore/envs/prod-us-west-2/secretstore.yaml:1-14` — the ClusterSecretStore uses AWS Secrets Manager through the ESO service account.
  - `secretstore/envs/prod-us-west-2/secretstore-sa.yaml:1-8` — the ESO service account assumes the prod seed-account role.
  - `dedicated-cluster-service/cluster-controller/envs/prod-us-west-2/secrets.yaml:1-31` — ESO maps the two AWS secrets to Kubernetes Secrets.
  - `dedicated-cluster-service/cluster-controller/base/deployment.yaml:35-55` — the controller reads the Kubernetes Secrets, not AWS Secret Manager directly.