unkinben
96a6a7d728
ci/woodpecker/push/apply Pipeline was successful
## Why teabot's implementer and reviewer bot users should mint **ephemeral, scoped Gitea tokens** on demand rather than holding standing personal access tokens — Gitea tokens never expire on their own, so a leak lasts until someone notices. This registers and mounts the new `vault-plugin-secrets-gitea` engine (released v0.1.0) and declares its roles, mirroring the rancher engine wiring. ## Change - Register the plugin in the catalog (`config/plugins/vault-plugin-secrets-gitea.yaml`), pinned to the released v0.1.0 binary `sha256 8f67fbc216effada5fd7399888a710b62fad83be0b31761a439e7dec3d56509b` (sha256 of `/opt/openbao-plugins/vault-plugin-secrets-gitea` from the released `openbao-plugin-secrets-gitea-0.1.0` RPM). - Add `gitea_secret_backend` + `gitea_secret_backend_role` modules and wire them through `config.hcl`, `environments/au/syd1/terragrunt.hcl`, and `modules/vault_cluster` variables/main, using the `giteavaultsecret` provider from the `terraform-unkin` registry (v0.1.0). - Mount the engine at `gitea/` against `https://git.unkin.net`; seeded site-admin credentials are read from KV (`service/vault/au/syd1/secret_backend/gitea/config`, keys `admin_username`/`admin_password`) — not stored in git. - **The seed is consumed create-only**: `lifecycle ignore_changes` on `admin_username`/`admin_password` means the engine reads the KV seed only when first creating `gitea/config`. After `rotate-root` diverges the live password from the seed, a later apply never pushes the stale seed back. - Add roles with conservative, minimal scopes (write: implies read:): - `teabot-implementer` — `write:repository`, `write:issue` (clone/push, open PRs, comment). - `teabot-reviewer` — `read:repository`, `write:issue` (read diffs, post PR reviews/comments). - TTLs: `ttl` 1h / `max_ttl` 4h on both roles. ## The site-admin bot + KV seed are now provisioned by Terraform (no manual gap) Per Ben's review, creating the site-admin bot and seeding its credential is no longer a manual step: - **terraform-git #46** creates the `gitea-vault-admin` site-admin bot and writes its generated password **once** to `kv/service/vault/au/syd1/secret_backend/gitea/config` (create-only KV write; never updated). - **terraform-vault #102** grants terraform-git write access to that KV path. ## Ordering (merge + apply) 1. **puppet-prod #498** — installs the plugin binary on the vault nodes (Puppet must run). 2. **terraform-vault #100** (`benvin/gitea-deployer-access`) — deployer access to the gitea mount. 3. **terraform-vault #102** (`benvin/gitea-kv-writer`) — terraform-git KV write grant. 4. **terraform-git #46** (`benvin/gitea-vault-admin`) — creates the bot + seeds KV. 5. **This PR** — mounts the engine (reads the seed) and declares roles. Files here are disjoint from #100 and #102 (no conflict). **CI note:** the plan for this PR may hard-fail in CI if the plugin isn't yet registered/installed or the KV seed isn't present in the plan's target. If CI plan fails for that ordering reason, that is expected — do not force; apply only once steps 1–4 are live. ## Remaining manual step (one, ordered) After this PR's first apply, run `vault write -f gitea/config/rotate-root` so the standing seed password is replaced by one only Vault holds. (On future binary upgrades, bump the RPM version in puppet-prod and the catalog `sha256` here together, then `vault write sys/plugins/reload/backend plugin=vault-plugin-secrets-gitea`.) https://claude.ai/code/session_015ur3i7D2azsMAWTSVABApv Reviewed-on: #101 Co-authored-by: Ben Vincent <ben@unkin.net> Co-committed-by: Ben Vincent <ben@unkin.net>
terraform-vault
A repository to manage the configuration of Vault secret engines, authentication modes and policies.
Usage
- Initialize Terraform
Once you have your backend block configured, you need to initialize your Terraform working directory to configure the backend:
terraform init
This command initializes the backend and checks the connection to Consul. If everything is set up correctly, Terraform will start using Consul as its backend for storing the state.
- Common terraform init Errors
If you encounter errors while running terraform init, check the following:
Consul server is reachable: Make sure that the address is correct and that you can connect to the Consul server.
Consul token (if using ACLs): Verify that the token has the correct permissions to write to the specified path in the Consul KV store.
- Example Consul KV Structure
In Consul, the state file will be stored in the KV store under the specified path:
terraform/state
You can check the Consul KV store by accessing the Consul UI or using the consul kv command to see the stored Terraform state:
consul kv get terraform/state