You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Render allowPrivilegeEscalation: false on every container, in both implementations #294
Render allowPrivilegeEscalation: false on every container the estate renders, sidecars included, in both the TypeScript implementation and the model-driven implementation under emf/.
Why
The restricted hardening posture now lists five controls, not four: chapter 10, Hardening, chapter 20, the hardening: restricted row of chapter 30 and 0020. The spec change was made on its own; neither implementation renders the new control yet, and no committed rendered tree carries it.
Without it, a setuid binary in an image can still raise its process to uid 0 even though the process runs non-root with every capability dropped. Kubernetes' own restricted Pod Security Standard requires the field, so a namespace that enforces that standard refuses the pods as rendered today.
The TypeScript kubernetes adapter sets allowPrivilegeEscalation: false in every container's securityContext.
The model-driven implementation's Acceleo templates do the same.
Every rendered oracle tree under spec/v1/examples/*/rendered/ gains the field on every container, edited and reviewed by hand. No oracle is regenerated.
Acceptance
Every container and sidecar in every committed rendered tree carries allowPrivilegeEscalation: false.
The five controls hold on every container except where the Platform admits a deviation: a catalog Node Agent (#356) or a named capability (#351). A deviation relaxes only the control it needs: a net-admin container keeps allowPrivilegeEscalation: false and runAsNonRoot. The spec change states that rule. #257 is closed as a duplicate of this issue. TypeScript only, after emf/ is deleted (#99).
Done by #524 (merged 2026-10-21), read back on main the same day.
Both implementations render the field: src/adapters/kubernetes/render.ts (the shared container posture), catalog.ts and migration.ts in the TypeScript adapter, and six sites in emf/bundles/render/model/render.mtl.
Every committed rendered tree under spec/v1/examples/*/rendered/ was parsed for every container and init container: 41 of 42 carry allowPrivilegeEscalation: false.
The one without it is the VPN native sidecar beside karakeep. That is the decided exception, not a gap: chapter 14 makes it "the one container the posture lets hold NET_ADMIN and NET_RAW, and the one that runs as root", per 0020 and 0107. It supersedes this issue's 2026-10-09 re-scope note that a net-admin container keeps the control. If that note should still hold, reopen this, because the spec and the gate both say otherwise.
Activity
ExtraToast commentedon Oct 9, 2026
Re-scoped by Decide the fate of the open work that predates the map
The five controls hold on every container except where the Platform admits a deviation: a catalog Node Agent (#356) or a named capability (#351). A deviation relaxes only the control it needs: a
net-admincontainer keepsallowPrivilegeEscalation: falseandrunAsNonRoot. The spec change states that rule. #257 is closed as a duplicate of this issue. TypeScript only, afteremf/is deleted (#99).ExtraToast commentedon Oct 21, 2026
Done by #524 (merged 2026-10-21), read back on
mainthe same day.src/adapters/kubernetes/render.ts(the shared container posture),catalog.tsandmigration.tsin the TypeScript adapter, and six sites inemf/bundles/render/model/render.mtl.spec/v1/examples/*/rendered/was parsed for every container and init container: 41 of 42 carryallowPrivilegeEscalation: false.NET_ADMINandNET_RAW, and the one that runs as root", per 0020 and 0107. It supersedes this issue's 2026-10-09 re-scope note that anet-admincontainer keeps the control. If that note should still hold, reopen this, because the spec and the gate both say otherwise.