unkinben 8ccc5f1393
ci/woodpecker/push/apply Pipeline was successful
Add the netbox backend and terraform-infra role (#117)
## Why

- The netbox engine modules stand ready but mount nothing and create no identity until backend and role data exist, so terraform-infra still reads a static NetBox token instead of minting ephemeral scoped tokens.

## How

- Add `config/netbox_secret_backend/netbox.yaml` to mount the engine at `netbox` and point it at the syd1 NetBox URL; the admin token is read from KV, not stored here.
- Add `config/netbox_secret_backend_role/netbox/terraform-infra.yaml` as the single declarative source for the terraform-infra identity: filename-derived role name and NetBox username, write access, short TTLs, and an inline permissions block. Nothing in the file repeats the filename.
- Scope terraform-infra to view/add/change/delete on the IPAM/DCIM objects it manages: prefixes, ip-addresses, ip-ranges, devices, interfaces, mac addresses.
- Add `policies/netbox/creds/terraform-infra.yaml` letting the terraform-infra AppRole and its Woodpecker k8s role read `netbox/creds/terraform-infra`; it attaches to nothing until the separate terraform-infra Vault onboarding lands.

## Dependency order

- Stacked on the modules PR (#115), which stacks on the plugin registration PR. Merge order: plugin -> #115 -> this.

## CI note

- The plan step is red only on the external admin_token KV seed at `kv/data/service/vault/au/syd1/secret_backend/netbox/config` (a NetBox token with add_token + grant_token / superuser). Seeding that path is an environmental prerequisite, not a code defect; everything else validates.

---------

Co-authored-by: BenVincent <benvin@main.unkin.net>
Reviewed-on: #117
Co-authored-by: Ben Vincent <ben@unkin.net>
Co-committed-by: Ben Vincent <ben@unkin.net>
2026-08-11 20:43:04 +10:00
2024-09-09 22:57:00 +10:00
2026-05-21 23:52:30 +10:00
2024-09-23 22:01:18 +10:00

terraform-vault

A repository to manage the configuration of Vault secret engines, authentication modes and policies.

Usage

  1. 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.

  1. 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.
  1. 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
S
Description
A repository to manage the configuration of Vault secret engines, authentication modes and policies.
Readme MIT 1.1 MiB
Languages
HCL 99.3%
Makefile 0.7%