Namespace service account token map keys by account #31

2026-08-29T23:11:26+10:00

unkin-agent commented

2026-08-29 23:11:26 +10:00

Review finding carried over from #30: local.service_account_tokens was keyed by the bare token identifier, so if two config/service_accounts/*.yaml ever declared the same identifier, merge() would silently collapse them and one token would never be created. Its sibling service_account_permissions already namespaces keys as "<account>/<permission>".

Changes

Key service_account_tokens as "<service_account>/<identifier>", mirroring the permissions local.
Carry the bare identifier as a field on the map value and use it for authentik_token.identifier, so the Authentik-side identifier is unchanged.
vault_kv_secret_v2.service_account_token keeps indexing the token by each.key; both maps re-key together.

State impact

Re-keying a for_each re-addresses existing instances, which would otherwise destroy+recreate the live sa-agent-api token and rotate the key published to Vault. Two moved {} blocks map the old addresses to the new ones, so the token is not recreated — the plan should show only the re-address, no changes:

authentik_token.service_account["agent-api-token"] -> ["sa-agent-api/agent-api-token"]
vault_kv_secret_v2.service_account_token["agent-api-token"] -> ["sa-agent-api/agent-api-token"]

These are one-off migration blocks (the repo used none before) and can be deleted after this applies.

Verified with pre-commit run (tofu fmt / validate / tflint all pass).

Review finding carried over from #30: `local.service_account_tokens` was keyed by the bare token identifier, so if two `config/service_accounts/*.yaml` ever declared the same identifier, `merge()` would silently collapse them and one token would never be created. Its sibling `service_account_permissions` already namespaces keys as `"<account>/<permission>"`. ## Changes - Key `service_account_tokens` as `"<service_account>/<identifier>"`, mirroring the permissions local. - Carry the bare `identifier` as a field on the map value and use it for `authentik_token.identifier`, so the Authentik-side identifier is unchanged. - `vault_kv_secret_v2.service_account_token` keeps indexing the token by `each.key`; both maps re-key together. ## State impact Re-keying a `for_each` re-addresses existing instances, which would otherwise destroy+recreate the live `sa-agent-api` token and rotate the key published to Vault. Two `moved {}` blocks map the old addresses to the new ones, so **the token is not recreated** — the plan should show only the re-address, no changes: - `authentik_token.service_account["agent-api-token"]` -> `["sa-agent-api/agent-api-token"]` - `vault_kv_secret_v2.service_account_token["agent-api-token"]` -> `["sa-agent-api/agent-api-token"]` These are one-off migration blocks (the repo used none before) and can be deleted after this applies. Verified with `pre-commit run` (tofu fmt / validate / tflint all pass).

unkin-agent added 1 commit 2026-08-29 23:11:26 +10:00

Namespace service account token map keys by account

ci/woodpecker/pr/pre-commit Pipeline was successful

Details

ci/woodpecker/pr/plan Pipeline was successful

Details

0c6a9104c0

Two service_accounts declaring the same token identifier collapsed into a
single entry under merge(), silently dropping one token. Key the map by
account/identifier the way service_account_permissions already does, and
carry the bare identifier as a field for the authentik_token attribute.

benvin merged commit 5ecd03cdd5 into main

2026-08-30 00:03:12 +10:00

benvin deleted branch benvin/token-foreach-namespacing

2026-08-30 00:03:12 +10:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: unkin/terraform-authentik#31