arcodange-org/tools
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

feat(multi-env): Phase D2 — Vault policies for erp-sandbox #3

Merged
arcodange merged 1 commits from claude/phaseD-erp-sandbox-vault into main 2026-06-28 17:19:35 +02:00
Conversation 0 Commits 1 Files Changed 1 +1 -1
arcodange commented 2026-06-28 17:15:38 +02:00
Owner
Copy Link

Summary

Phase D2 of ADR-0002 — the Vault layer for the ERP sandbox. erp gains envs = ["prod", "sandbox"], which flows into the app_policy module (main.tf:81 envs = each.value.envs). For erp the module now resolves instances = ["erp", "erp-sandbox"].

Expected plan (~1 add, 1 change, 0 destroy)

action resource why
add vault_policy.app_non_prod["erp-sandbox"] new runtime policy erp-sandbox → reads kvv2/data/erp-sandbox/* + postgres/creds/erp-sandbox* (the sandbox pod's VSO uses it)
change (in-place) vault_policy.ops["erp"] erp-ops CI policy gains the erp-sandbox kvv2/{data,delete,undelete,destroy,metadata} rules + erp-sandbox entries in the k8s-role allowed_parameter lists, so CI can manage the sandbox
— everything else prod erp runtime policy + all other apps render byte-identical (envs still defaults to ["prod"]); glob rules like postgres/roles/erp* already covered sandbox

No destroy/replace. The merge gate is the CI tofu apply showing exactly this shape.

Note: pre-existing latent bug spotted (NOT fixed here)

The cms entry uses the object key ops_policies, but the root schema field is policies (the module input is ops_policies, wired at main.tf:82 as ops_policies = each.value.policies). Terraform silently drops the unknown ops_policies attribute on the cms object, so cms's factory__cf_r2_arcodange_tf policy is not actually attached to gitea_cicd_cms. Out of scope for this PR — flagging for a separate fix.

Phase D sequence

  • D1 — factory postgres DB + role → factory#17 ✅ merged
  • D2 (this PR) — Vault runtime policy + CI ops widening
  • D3 — erp iac/main.tf for_each → Vault k8s auth role + postgres/creds/erp-sandbox + kvv2/erp-sandbox/config
  • D4 — factory ArgoCD erp-sandbox Application

🤖 Generated with Claude Code

## Summary **Phase D2** of [ADR-0002](https://gitea.arcodange.lab/arcodange-org/factory/src/branch/main/vibe/ADR/0002-per-application-environments.md) — the Vault layer for the ERP sandbox. `erp` gains `envs = ["prod", "sandbox"]`, which flows into the `app_policy` module (`main.tf:81` `envs = each.value.envs`). For erp the module now resolves `instances = ["erp", "erp-sandbox"]`. ### Expected plan (~1 add, 1 change, 0 destroy) | action | resource | why | |---|---|---| | **add** | `vault_policy.app_non_prod["erp-sandbox"]` | new runtime policy `erp-sandbox` → reads `kvv2/data/erp-sandbox/*` + `postgres/creds/erp-sandbox*` (the sandbox pod's VSO uses it) | | **change (in-place)** | `vault_policy.ops["erp"]` | `erp-ops` CI policy gains the erp-sandbox `kvv2/{data,delete,undelete,destroy,metadata}` rules + erp-sandbox entries in the k8s-role `allowed_parameter` lists, so CI can manage the sandbox | | — | everything else | prod `erp` runtime policy + all other apps render byte-identical (`envs` still defaults to `["prod"]`); glob rules like `postgres/roles/erp*` already covered sandbox | No destroy/replace. The merge gate is the CI `tofu apply` showing exactly this shape. ### Note: pre-existing latent bug spotted (NOT fixed here) The `cms` entry uses the object key `ops_policies`, but the root schema field is `policies` (the *module* input is `ops_policies`, wired at `main.tf:82` as `ops_policies = each.value.policies`). Terraform silently drops the unknown `ops_policies` attribute on the `cms` object, so cms's `factory__cf_r2_arcodange_tf` policy is **not actually attached** to `gitea_cicd_cms`. Out of scope for this PR — flagging for a separate fix. ### Phase D sequence - D1 — factory postgres DB + role → [factory#17](https://gitea.arcodange.lab/arcodange-org/factory/pulls/17) ✅ merged - **D2 (this PR)** — Vault runtime policy + CI ops widening - D3 — erp `iac/main.tf` for_each → Vault k8s auth role + `postgres/creds/erp-sandbox` + `kvv2/erp-sandbox/config` - D4 — factory ArgoCD `erp-sandbox` Application 🤖 Generated with [Claude Code](https://claude.com/claude-code)
arcodange added 1 commit 2026-06-28 17:15:49 +02:00
feat(multi-env): Phase D2 — Vault policies for erp-sandbox
Some checks failed
Helm Charts / Library charts tool (push) Blocked by required conditions
Details
Helm Charts / Application charts pgcat (push) Blocked by required conditions
Details
Helm Charts / Library charts tool (pull_request) Blocked by required conditions
Details
Helm Charts / Application charts pgcat (pull_request) Blocked by required conditions
Details
Helm Charts / Detect changed charts (pull_request) Failing after 11m29s
Details
Helm Charts / Detect changed charts (push) Failing after 12m7s
Details
25569eb29d 
ADR-0002 Phase D, Vault layer. `erp` gains `envs = ["prod", "sandbox"]`,
which flows into the app_policy module (main.tf:81 `envs = each.value.envs`).
For erp the module now resolves instances = ["erp", "erp-sandbox"], so the
apply:
  - ADDS  vault_policy.app_non_prod["erp-sandbox"] — the runtime policy
          named `erp-sandbox` (read kvv2/data/erp-sandbox/* +
          postgres/creds/erp-sandbox*), consumed by the sandbox pod's VSO.
  - UPDATES vault_policy.ops["erp"] in place — the `erp-ops` CI policy
          gains the erp-sandbox kvv2 data/delete/undelete/destroy/metadata
          rules + the erp-sandbox values in the k8s-role allowed_parameter
          lists, so CI can manage the sandbox instance. The glob rules
          (postgres/roles/erp*, kvv1/cloudflare/erp*, auth/kubernetes/role/erp*)
          already covered erp-sandbox, so they don't change.

No destroy/replace. prod `erp` runtime policy + every other app render
byte-identical (their envs still default to ["prod"]).

Diff kept to the single erp line — the pre-existing cms/crowdsec/plausible
alignment is left as-is on main (not reformatting unrelated entries).

D2 of Phase D. D1 (postgres DB+role) = factory#17 (merged). D3 (erp iac
creds + KV) and D4 (ArgoCD) follow.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
arcodange merged commit fd93359f2e into main 2026-06-28 17:19:35 +02:00
arcodange deleted branch claude/phaseD-erp-sandbox-vault 2026-06-28 17:19:43 +02:00
Sign in to join this conversation.
Reviewers
No Reviewers
Labels
No items
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
arcodange
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: arcodange-org/tools#3
Delete Branch "claude/phaseD-erp-sandbox-vault"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?