GitLab variable-administration credential

The Platform variable-distribution script uses the expiring tierpoint/prodtech group-owned token stored as hcs-platform-gitlab-prodtech-variable-admin-token in kv-hcs-vault-01. It has api scope and Owner access within that group, which is required for group-variable administration. It is not an estate-wide personal PAT. Record its owner and rotation in the secret inventory.

Do not recreate or use hcs-platform-gitlab-tp-godmode-pat: GitLab rejected it, its CI copies were removed, and its Key Vault name was soft-deleted on 2026-09-17. Do not seed PLATFORM_PAT or any GitLab API token into CI variables or browser bundles. The high-privilege ptlmgmt management SPN is also excluded from variable distribution.

Before running variable distribution

1. Sign in to Azure CLI with read access to kv-hcs-vault-01 and any source vaults required for the specific configured group. Check that the group token's Key Vault version is enabled and has not expired.
2. Run Invoke-GitLabVariableDistribution.ps1 -DryRun with an exact -GroupFilter for the intended group. Review the variable names and source vaults; the dry run must not list PLATFORM_PAT or the ptlmgmt SPN pair.
3. Execute the same group filter without -DryRun only after reviewing the target group's need for each credential and its masking/protection settings. Never distribute an unmasked secret to make a write succeed.
4. Run Test-PlatformSecrets.ps1 and independently read back the target variable metadata. Do not print values. Treat a failed provider check as a failed cutover, even if the Key Vault lookup succeeded.

The script's default token name is already the group-owned token. Avoid an explicit -PatKvSecretName unless a reviewed replacement has been staged in Key Vault. A separate least-privilege CI identity is required before adding new KV_SP_* variables for the POC group.

Rotation and rollback

Before the token's 90-day expiry, create a replacement group-owned token with the same minimum group-variable authority, store it as a new tagged and expiring Key Vault version, and verify group-variable read plus a non-secret create/read/delete probe. Re-run the exact dry run and intended distribution, then retire the prior token only after the consumer passes. If verification fails, restore the previous Key Vault version while it remains valid; do not fall back to the rejected personal PAT or expose a token through CI.

For Phase 1 evidence and remaining Cloudflare gates, see the remediation plan.