unkinben
0e6da5cdd3
ci/woodpecker/push/apply Pipeline was successful
## Why Agentic workloads currently need cluster-admin/root kubeconfig contexts to do routine per-domain work. This adds domain-scoped, Vault-issued kubernetes credentials plus an `agents` AppRole so agents get least-privilege access instead of escalating. ## Changes - Add `kubernetes_secret_backend_role` configs `agent-dhcp`, `agent-dns`, `agent-certs`, `agent-storage` (au/syd1): - **agent-dhcp** (Role, ns `dhcp-system`): full verbs on `kea.unkin.net` CRDs; get/list/watch pods/services/configmaps/events + pods/log. - **agent-dns** (`service_account_name` mode): mints tokens for the static `agent-dns` SA (argocd-apps#332) whose per-namespace RoleBindings confine access to bind-system/bind-internal/bind-external/externaldns. `allowed_kubernetes_namespaces: [bind-system]` (the SA's namespace). - **agent-certs** (Role, ns `cert-manager`): full verbs on `cert-manager.io` + `acme.cert-manager.io` (closes the orders/challenges debugging gap); get/list/watch/delete secrets; get/list/watch pods + pods/log. Secret delete confined to `cert-manager`. - **agent-storage** (Role, ns `cephrgw-system`): full verbs on `ceph.unkin.net` CRDs (buckets/bucketaccesses/objectstoreusers); get/list/watch pods + pods/log. - Extend the `kubernetes_secret_backend_role` module with an optional `service_account_name`; when set, `generated_role_rules`/`kubernetes_role_type` are omitted (the SA's own bindings supply RBAC). - Add creds policies for each role, bound to the `kubernetes_au_syd1_cluster_operator` ldap group (human kubectl use) and the `agents` AppRole (programmatic use). - Add the `agents` AppRole (mirrors the certmanager approle schema): `bind_secret_id: false` (role_id-only login), `token_bound_cidrs: [10.10.12.200/32]` (agent workstation wg0 addr), deterministic role_id, 1h/4h TTLs. - Add `policies/kv/kubernetes/agents.yaml` granting the AppRole create/read/update/list on `kv/data/kubernetes/*` + read/list on `kv/metadata/kubernetes/*` (no delete). ## Ordering argocd-apps#332 (the `agent-dns` SA + ClusterRole + per-namespace RoleBindings) must sync **before** the `agent-dns` creds here are usable — Vault mints tokens for a service account that must already exist. https://claude.ai/code/session_01JUoARVdmhxKQHyyyp1pxeT Reviewed-on: #109 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