# Dedicated account registration

Dedicated Product runs customer data-plane workloads in a *shoot* AWS account, driven by regional seed EKS clusters that already exist in a seed/management account. This skill is the two-account handshake (data-plane roles, seed-side assume grants, RAM PCA shares, per-region shared buckets), the dedicated regional-server GitOps overlay that publishes those names, and the image-policy pull grant for the shoot account. It does not bootstrap a seed and does not write the global `Account` CR. Premium shoot uses a different role contract.

## Who

- Data-plane account admin and seed-account admin (two identities).
- Image-policy lives in `tidbcloud/docker-image-controller`. This registration writes that grant. Seed IAM, `account-list`, and `ProviderConfig` do not grant image pulls. Region image sync must already exist; a merged policy PR is not apply evidence.

## When

- Registering a new Dedicated shoot with one or more existing regional seeds.
- Adding a Region to an already-registered shoot (that Region needs its own image-pull evidence even when the account is reused).

Daily sessions stay on `cp9 up`. Developer-role bootstrap is [`../../cp9-developer/SKILL.md`](../../cp9-developer/SKILL.md).

## Floor

Read [`../../live-floor.md`](../../live-floor.md) and run those steps. Seed EKS, OIDC, and source roles must already exist.

| Name | Lookup |
|---|---|
| `auto-deploy-cli` | `iam get-role` — present trust stays |
| `cicd-role` | `iam get-role` |
| `full-manager-service-role` | `iam get-role` |
| `full-manager-eks-role` | `iam get-role` |

Also, for each selected regional seed (`env`, `logical-region`):

- data-plane target roles: `{env}-{region}-dp4drs`, `{env}-{region}-cluster-controller-assumed-role`, `readonly-{env}-{region}-cluster-controller-assumed-role`, `{env}-{region}-dm-controller-assumed-role`, `{env}-{region}-import-controller-assumed-role`
- seed-side additive inline `cp9-dedicated-dp-<data-plane-account-id>` on the existing source roles (exact target ARNs only — other data planes stay)
- RAM PCA shares `pca-{default,signClient,signServer,signBlank,revoke}-<data-plane-account-id>`
- shared bucket prefix `{env}-sb-<data-plane-account-id>-<region>-000-`

Then, for each selected regional seed, the app-delivery overlay `dedicated-regional-server/regional-server/envs/aws-{env}-{logical-region}/`. Copy a sibling shoot already in that overlay; substitute this account, org, live role ARNs, and the live bucket name:

- `account/account-list.yaml` — `awsAccount`, `awsRole` `{env}-{region}-dp4drs`, `sharedBucketBundle` from live bucket
- `account/binding.yaml` — ConfigMap `tenant-<org>` defaulting to the data-plane account
- `account/providerconfig.yaml` — `ProviderConfig` named by account ID, `assumeRoleARN` of that `dp4drs`
- `config/root-config.yaml` `authorizedSubjects` — `full-manager-service-role`, `{env}-{region}-dm-controller-assumed-role`, `{env}-{region}-import-controller-assumed-role`

GitOps uses live `GetRole` / `GetBucket` values. Open a PR in `tidbcloud/app-delivery`; merge stays with that repo's owners.

Then grant pull in `tidbcloud/docker-image-controller`. Copy a sibling account already in `ecr-cross-account-dev.yaml` (or the prod counterpart) for the selected Regions; add this data-plane account. Open a PR. Apply evidence is the `Update-ECR-Policy-Dev` (or prod) insert run — that yaml is not on the push path filter, so dispatch after merge.

Destroy is decommissioning of live Dedicated dependencies.

## Completion

Name table for the account-level roles plus every selected regional AWS name, the four overlay files containing this account and org, and the image-policy insert run for those Regions. Existing `auto-deploy-cli` is `left-in-place`. Product acceptance still needs a real data-plane workload to pull shared images in that Region.