privilegedescalation/org
12
0
Fork 0
Code Issues 1 Pull Requests Actions Packages Projects Releases Wiki Activity

Clarify two-stage GitOps deployment pipeline in POLICIES.md

Browse Source 
Agents were assuming the org infra repo is what Flux watches directly.
The actual flow is: org/infra → cpfarhood/kubernetes (Flux watches this).

New policy explains:
- Existing resources: commit to org infra repo, Flux picks it up
- New resources (namespaces, kustomizations, secrets): also needs
  a cpfarhood/kubernetes change — escalate to the board
- Never assume committing to org infra repo is always sufficient

Co-Authored-By: Paperclip <noreply@paperclip.ing>
This commit is contained in:
Chris Farhood
2026-03-21 11:24:21 -04:00
parent 2bf860016d
commit e687d9abfc
1 changed files with 11 additions and 2 deletions
Download Patch File Download Diff File Expand all files Collapse all files
POLICIES.md
+11 -2
View File
@@ -33,9 +33,18 @@ The following services are available in the cluster. Use them via their operator
## Infrastructure Deployment
All infrastructure changes deploy via **Flux GitOps**. Flux reconciles the org's `infra` repo to the cluster automatically.
Infrastructure deploys through a two-stage GitOps pipeline:
- **The only way to change Kubernetes resources is through the infra repo.** Commit manifests, push, and Flux deploys. There is no other path.
1. **Org infra repo** (`<org>/infra`) — contains the Kubernetes manifests for this org's applications (deployments, services, CNPG clusters, etc.)
2. **Platform repo** (`cpfarhood/kubernetes`) — contains Flux Kustomizations that reference each org's infra repo. Flux watches THIS repo, not the org infra repos directly.
When you need an infrastructure change:
1. Commit the manifest change to your org's infra repo (e.g., `cartsnitch/infra`, `groombook/infra`)
2. If the change requires a NEW resource that Flux doesn't already reference (new Kustomization, new namespace, new sealed secret), a corresponding change to `cpfarhood/kubernetes` is also needed — create a Paperclip issue for the board
3. If the change is to an EXISTING resource already tracked by Flux, committing to the org infra repo is sufficient — Flux will pick it up on the next reconciliation cycle
**Do NOT assume that committing to the org infra repo is always sufficient.** New resources, new namespaces, and new secrets require platform repo changes that only the board can make.
- **`kubectl` is available** and agents have the following access:
- **Cluster-wide**: read-only (`get`, `list`, `watch`) across all namespaces
- **`privilegedescalation` namespace**: read-write (production — changes MUST go through Flux, not kubectl)