unkin/terraform-vault
3
0
Fork 0
Code Issues 2 Pull Requests Actions Packages Projects Releases Wiki Activity

vault: add ghp k8s auth role + kv read policy #120

Closed
unkin-agent wants to merge 1 commits from benvin/ghp-vault into master
pull from: benvin/ghp-vault
merge into: unkin:master
Conversation 1 Commits 1 Files Changed 2
+24
unkin-agent commented 2026-08-13 19:32:14 +10:00
Member
Copy Link
Copy Source

Why

ghp (a GitHub proxy) deploys to k8s namespace ghp (ServiceAccount ghp) and must read its GitHub App credentials and encryption key from Vault kv at kv/kubernetes/ghp/* (.../github-app, .../app), delivered to the pod by VSO. ghp uses the postgres storage backend, so it needs Vault only to read those kv secrets — no storage-backend CRUD. Values are populated separately by Ben via runbook; this PR adds structure only.

How

Mirrors the existing per-app pattern (reference apps: artifactapi, logging_logarchiver):

  • k8s auth role ghp (config/auth_kubernetes_role/k8s/au/syd1/ghp.yaml) bound to ServiceAccount ghp in namespace ghp, token_ttl/token_max_ttl 600s, audience: vault — same shape as other apps; the differing SA-name case follows logging_logarchiver.
  • read-only kv policy (policies/kv/kubernetes/ghp/read.yaml): read on kv/data/kubernetes/ghp/*, read+list on kv/metadata/kubernetes/ghp/*; assigns to k8s/au/syd1 role ghp. No create/update/delete.

No DB/CNPG role added: the estate mints app DB access via CNPG-generated k8s Secrets (postgres storage backend), not a Vault database engine — consistent with other apps.

terraform fmt clean; yamllint + pre-commit hooks pass. terragrunt validate exercises HCL/YAML parsing successfully (new YAML decodes fine) and only fails at Vault provider init in the sandbox (missing CA bundle) — not applied.

## Why ghp (a GitHub proxy) deploys to k8s namespace `ghp` (ServiceAccount `ghp`) and must read its GitHub App credentials and encryption key from Vault kv at `kv/kubernetes/ghp/*` (`.../github-app`, `.../app`), delivered to the pod by VSO. ghp uses the **postgres** storage backend, so it needs Vault only to **read** those kv secrets — no storage-backend CRUD. Values are populated separately by Ben via runbook; this PR adds structure only. ## How Mirrors the existing per-app pattern (reference apps: **artifactapi**, **logging_logarchiver**): - **k8s auth role `ghp`** (`config/auth_kubernetes_role/k8s/au/syd1/ghp.yaml`) bound to ServiceAccount `ghp` in namespace `ghp`, `token_ttl`/`token_max_ttl` 600s, `audience: vault` — same shape as other apps; the differing SA-name case follows logging_logarchiver. - **read-only kv policy** (`policies/kv/kubernetes/ghp/read.yaml`): `read` on `kv/data/kubernetes/ghp/*`, `read`+`list` on `kv/metadata/kubernetes/ghp/*`; assigns to `k8s/au/syd1` role `ghp`. No create/update/delete. No DB/CNPG role added: the estate mints app DB access via CNPG-generated k8s Secrets (postgres storage backend), not a Vault database engine — consistent with other apps. `terraform fmt` clean; yamllint + pre-commit hooks pass. `terragrunt validate` exercises HCL/YAML parsing successfully (new YAML decodes fine) and only fails at Vault provider init in the sandbox (missing CA bundle) — not applied.
unkin-agent added 1 commit 2026-08-13 19:32:14 +10:00
vault: add ghp k8s auth role + kv read policy
ci/woodpecker/pr/plan Pipeline was successful
Details
ci/woodpecker/pr/pre-commit Pipeline was successful
Details
1dace21b37 
ghp (a GitHub proxy) reads its GitHub App credentials and encryption key from kv/kubernetes/ghp/*; it uses the postgres storage backend so it only needs read access to those kv secrets.

- add k8s/au/syd1 auth role ghp bound to ServiceAccount ghp in namespace ghp (ttl 600s, audience vault)
- add read-only kv policy granting read on kv/data/kubernetes/ghp/* and read+list on kv/metadata/kubernetes/ghp/*
- mirrors the artifactapi / logging_logarchiver per-app pattern (app-SA-bound k8s role + single kv read policy consumed by VSO)
unkin-agent commented 2026-08-13 19:59:13 +10:00
Author
Member
Copy Link
Copy Source

Closing as redundant. The templated policies/kv/kubernetes/default.yaml already grants the default k8s role (bound to SA default in all namespaces) read on kv/kubernetes/namespace/<namespace>/default/*. ghp will follow the estate convention (SA default, VaultAuth role default, secrets under kv/kubernetes/namespace/ghp/default/*) — same as artifactapi — so no bespoke ghp role or policy is needed.

Closing as redundant. The templated `policies/kv/kubernetes/default.yaml` already grants the `default` k8s role (bound to SA `default` in all namespaces) read on `kv/kubernetes/namespace/<namespace>/default/*`. ghp will follow the estate convention (SA `default`, VaultAuth role `default`, secrets under `kv/kubernetes/namespace/ghp/default/*`) — same as artifactapi — so no bespoke ghp role or policy is needed.
unkin-agent closed this pull request 2026-08-13 19:59:14 +10:00
All checks were successful
ci/woodpecker/pr/plan Pipeline was successful
Required
Details
ci/woodpecker/pr/pre-commit Pipeline was successful
Required
Details

Pull request closed

Please reopen this pull request to perform a merge.
Sign in to join this conversation.
Reviewers
No Reviewers
Labels
No items
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
benvin (BenVincent) unkin-agent (Unkin Agent) unkinben (Ben Vincent)
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: unkin/terraform-vault#120
Delete Branch "benvin/ghp-vault"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?