unkin-agent
392c5d2ac7
ci/woodpecker/push/apply Pipeline failed
## Why Reverts the temporary removal in #129. That PR deleted the ghp backend + role config YAMLs to unblock the `master` apply, which was failing with: ``` Error: no secret found at "kv/data/service/vault/au/syd1/secret_backend/ghp/config" from module.ghp_secret_backend["ghp"].data.vault_kv_secret_v2.config ``` The ghp config KV is now seeded: `kv/data/service/vault/au/syd1/secret_backend/ghp/config` holds key `admin_token`, and the ghp service secret `kv/kubernetes/namespace/ghp/default/app` carries the matching `service_token`. With the KV populated, `data.vault_kv_secret_v2.config` resolves, so the ghp secret backend + role can be created. The ghp module wiring, plugin registration, and policies were never removed (they stayed on `master`), so restoring these two YAMLs re-populates the `for_each` maps and instantiates the backend + role against the seeded config. ## Changes - Restore `config/ghp_secret_backend/ghp.yaml`. - Restore `config/ghp_secret_backend_role/ghp/agent.yaml`. Net diff vs `master` is exactly the re-addition of those two files (byte-identical to their pre-#129 content, the mirror-inverse of #129). ## Sequence Final step (4/4) of the remove -> grant write policy -> seed KV -> add-back sequence: #129 (remove) -> #128 (grant) -> KV seed -> this PR (add back). ## Verification - `tofu fmt` clean, `yamllint` passes (pre-commit hooks green), `terragrunt validate` succeeds (only unrelated `vault_kv_secret_v2` deprecation warnings). - `tofu init` installs the `vault-secrets-ghp` provider with no plugin/catalog error. - ghp config KV path confirmed seeded with `admin_token`, so the previously-failing data source now resolves. - A full privileged `plan` is not runnable under the agent AppRole (it lacks the policy to mint the consul backend token), so the created/destroyed resource counts are not machine-confirmed here; the git diff is exactly the two file additions, so no config-driven destroys are introduced. - Note: the ghp backend mount at apply requires the `vault-plugin-secrets-ghp` binary present on the OpenBao nodes (pre-existing Puppet-managed plugin). Reviewed-on: #130 Co-authored-by: unkin-agent <unkin-agent@unkin.net> Co-committed-by: unkin-agent <unkin-agent@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