Why: teabot's implementer and reviewer bot users should mint ephemeral,
scoped Gitea tokens on demand instead of holding standing personal access
tokens (Gitea tokens never expire on their own). This registers and mounts
the new vault-plugin-secrets-gitea engine 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.
- Add gitea_secret_backend + gitea_secret_backend_role modules and wire them
through config.hcl, terragrunt.hcl, and vault_cluster variables/main, using
the giteavaultsecret provider (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).
- Add teabot-implementer (write:repository, write:issue) and teabot-reviewer
(read:repository, write:issue) roles, ttl 1h / max_ttl 4h.
Claude-Session: https://claude.ai/code/session_015ur3i7D2azsMAWTSVABApv
## Why
v0.1.0 of the rancher plugin minted non-functional tokens — it returned `status.value` (the secret fragment) instead of `status.bearerToken` (`ext/<name>:<secret>`), so every cred and every root rotation 401'd against Rancher. Fixed in plugin v0.1.1 (PR #2, released).
## Changes
- `config/plugins/vault-plugin-secrets-rancher.yaml` sha256 → v0.1.1 binary `9e597cd9…d5955` (verified against both v0.1.1 RPMs). Re-registers the catalog entry so OpenBao launches the fixed binary.
## Deploy coordination
1. Puppet installs the v0.1.1 RPM on the vault nodes (separate puppet-prod PR).
2. Merge this → apply re-registers the catalog with the new sha.
3. `vault plugin reload -plugin=vault-plugin-secrets-rancher` so the running plugin swaps to v0.1.1 (its sha must match this catalog entry).
---------
Co-authored-by: Ben Vincent <neotheo@gmail.com>
Reviewed-on: #96
Co-authored-by: Ben Vincent <ben@unkin.net>
Co-committed-by: Ben Vincent <ben@unkin.net>
Bring the litellm plugin under terraform management like the gpg one, using the new plugin-import module (#89).
## Why
The litellm plugin was registered **manually** before terraform owned the catalog. If we just add it to `config/plugins/`, the first apply tries to *create* a catalog entry that already exists and fails. So its state must be imported first.
## Changes
- Add `config/plugins/vault-plugin-secrets-litellm.yaml` (`sha256` = released **v0.1.1** openbao binary from the RPM Puppet installs).
## Manual pre-step (before apply)
Import the existing registration into state, and verify the sha matches the live catalog:
```sh
cd environments/au/syd1
# confirm the live sha first:
bao read sys/plugins/catalog/secret/vault-plugin-secrets-litellm
# import into state:
terragrunt import \
'module.plugin["vault-plugin-secrets-litellm"].vault_plugin.this' \
secret/vault-plugin-secrets-litellm
```
If the live sha differs from the yaml, update the yaml to match (or expect a benign re-register to the on-disk v0.1.1 sha). Needs the deployer's plugin-catalog access (#88, already merged).
Reviewed-on: #90
Co-authored-by: Ben Vincent <ben@unkin.net>
Co-committed-by: Ben Vincent <ben@unkin.net>
## Why
Register the released v0.1.0 rancher secrets plugin so the engine can be mounted. Uses the existing config/plugins discovery + plugin module (added for gpg in #89). Mirrors #90 (litellm import).
## Changes
- Add `config/plugins/vault-plugin-secrets-rancher.yaml` (`type: secret`, `command: vault-plugin-secrets-rancher`, `sha256` pinned to the released binary `d2b17f45…ec574a`, verified against both the vault and openbao v0.1.0 RPMs).
## Merge order
Part 2 of 4. Requires the binary on disk (puppet-prod install) and the deployer policy (#91). Merge before the backend PR.
---------
Co-authored-by: Ben Vincent <neotheo@gmail.com>
Reviewed-on: #92
Co-authored-by: Ben Vincent <ben@unkin.net>
Co-committed-by: Ben Vincent <ben@unkin.net>
Split plugin catalog registration out of the per-engine backend modules into its own concern (previously bundled into #87's gpg_secret_backend).
## Changes
- New generic `plugin` module (`vault_plugin`: type/name/command/sha256/plugin_version) that imports a binary into the catalog.
- New `config/plugins/` discovery group (filename = catalog name = mount type), wired through `vault_cluster` (`plugins` variable + module) and the syd1 environment.
- `config/plugins/vault-plugin-secrets-gpg.yaml` pins the released v0.1.0 binary sha256 (`0e92d740…a7b20`, from the published RPM). Puppet installs the RPM floating, so bump this in lockstep on upgrade.
Any engine now registers its plugin by dropping a file in `config/plugins/`; its `*_secret_backend` module just mounts the registered type.
Needs the deployer's plugin-catalog access (#88). Merge order: **#88 → this → #87**.
Reviewed-on: #89
Co-authored-by: Ben Vincent <ben@unkin.net>
Co-committed-by: Ben Vincent <ben@unkin.net>
unkinben