coulomb/the-custodian
Archived
2
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

feat(canon): add Privileged Execution Control standard v0.2 and schemas

Browse Source 
Maturity model and schemas for handling necessary privilege escalation
across three contexts: OS sudo, Kubernetes RBAC, and CI/CD pipelines.
To be applied to the codebase once initial Railiance setup is complete.

Files:
- privileged-execution-control_v0.2 (standard)
- privileged-execution-control-schema_v0.2.1.md (base schema)
- privileged-execution-control-schema-os-sudo_v0.2.1.md
- privileged-execution-control-schema-kubernetes-rbac_v0.2.1.md
- privileged-execution-control-schema-cicd_v0.2.1.md

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
This commit is contained in:
Bernd Worsch
2026-03-11 01:13:02 +01:00
parent 890b2f9fc7
commit 2be217f51a
5 changed files with 5436 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

540
canon/standards/privileged-execution-control_v0.2 Normal file
View File

@@ -0,0 +1,540 @@
PrivilegedExecutionControlStandard
*Maturity model to minimize privileged attack surfaces*
# Privileged Execution Control Standard (PECS)
### A maturity model and reference framework for controlling privileged execution in software systems
**Version:** 0.2 (Draft)
**Status:** Candidate Architecture Standard
**Authoring Context:** DevSecOps / Platform Engineering / Secure Automation
**Audience:**
* Software architects
* DevOps engineers
* Security engineers
* CI/CD maintainers
* AI coding agents operating within repositories
---
# 1. Purpose
The **Privileged Execution Control Standard (PECS)** defines a structured approach to controlling **privileged operations** in software systems.
It provides:
1. **Terminology and conceptual model**
2. **A multidimensional maturity assessment**
3. **Design patterns for privilege boundaries**
4. **Implementation guidance for common environments**
5. **Mapping to existing security frameworks**
The goal is to ensure that systems:
* minimize privileged attack surfaces
* provide deterministic authorization of privileged operations
* enable secure automation
* remain auditable and maintainable
---
# 2. Scope
PECS applies to **software systems that contain privileged operations**, including:
* DevOps pipelines
* build systems
* operational tooling
* infrastructure automation
* platform management systems
* cluster orchestration
Privileged execution environments include:
* OS-level root privileges
* container runtime privileges
* Kubernetes cluster permissions
* administrative API credentials
* infrastructure automation roles
---
# 3. Core Security Principles
PECS builds on established security principles.
## 3.1 Least Privilege
Privileged permissions must be limited to **the smallest possible scope**.
---
## 3.2 Explicit Privilege Boundaries
All privileged execution must occur through **clearly defined entry points**.
---
## 3.3 Deterministic Authorization
Privilege elevation must rely on **explicit authorization mechanisms**, not implicit behavior.
---
## 3.4 Integrity Binding
Authorization must bind to **specific executable artifacts**.
---
## 3.5 Auditability
The system must provide verifiable answers to:
* What privileged operations exist?
* Who approved them?
* What code was approved?
* What executed?
---
# 4. Conceptual Model
The PECS conceptual model is **implementation independent**.
## 4.1 Privileged Execution
An operation requiring elevated authority beyond the normal execution context.
Examples:
* root access
* administrative API access
* cluster-level operations
* privileged containers
---
## 4.2 Privileged Entry Point (PEP)
A programmatic interface that performs privileged actions.
Examples:
```
backup-root
rootctl snapshot
kubectl apply (cluster-admin)
```
---
## 4.3 Privileged Invocation
The act of executing a privileged entry point.
---
## 4.4 Privileged Execution Surface (PES)
The set of all privileged entry points in a system.
---
## 4.5 Privileged Authorization Artifact (PAA)
A machine-readable document defining which privileged operations are approved.
---
## 4.6 Integrity Binding
A mechanism that links approval to a **specific artifact version**.
Examples:
* SHA256 digest
* signed binary
* provenance metadata
---
## 4.7 Privileged Execution Gateway (PEG)
A centralized system responsible for executing privileged actions.
Example:
```
rootctl
```
---
# 5. Multidimensional Maturity Model
PECS maturity is evaluated along **five independent dimensions**.
| Dimension | Description |
| ------------------------ | ----------------------------- |
| Privilege Boundary | isolation of privileged logic |
| Authorization Governance | approval workflow |
| Integrity Assurance | binding approvals to code |
| Execution Enforcement | runtime enforcement |
| Auditability | execution tracking |
---
# 6. Maturity Levels
Each dimension has maturity levels from **0–5**.
---
# 6.1 Dimension 1 — Privilege Boundary Isolation
| Level | Description |
| ----- | --------------------------------- |
| 0 | privilege used anywhere |
| 1 | privilege isolated in scripts |
| 2 | dedicated privileged entry points |
| 3 | centralized gateway |
| 4 | restricted execution environment |
| 5 | formally defined privileged API |
---
# 6.2 Dimension 2 — Authorization Governance
| Level | Description |
| ----- | --------------------------------- |
| 0 | no approval process |
| 1 | manual review |
| 2 | documented allowlist |
| 3 | fingerprint approval |
| 4 | signed approvals |
| 5 | policy-based automated governance |
---
# 6.3 Dimension 3 — Integrity Assurance
| Level | Description |
| ----- | ------------------------- |
| 0 | no verification |
| 1 | manual checks |
| 2 | checksums |
| 3 | hash verification |
| 4 | signed artifacts |
| 5 | supply chain attestations |
---
# 6.4 Dimension 4 — Execution Enforcement
| Level | Description |
| ----- | ------------------------------ |
| 0 | uncontrolled privilege use |
| 1 | wrapper enforcement |
| 2 | tool-level restrictions |
| 3 | platform enforcement |
| 4 | policy engines |
| 5 | zero-trust privilege mediation |
---
# 6.5 Dimension 5 — Auditability
| Level | Description |
| ----- | -------------------------- |
| 0 | no logging |
| 1 | local logs |
| 2 | structured logs |
| 3 | centralized logging |
| 4 | tamper-resistant logs |
| 5 | cryptographic audit trails |
---
# 7. Example Maturity Assessment
Example system:
| Dimension | Level |
| ------------ | ----- |
| Boundary | 2 |
| Governance | 2 |
| Integrity | 3 |
| Enforcement | 2 |
| Auditability | 1 |
Result:
```
PECS maturity profile:
(2,2,3,2,1)
```
This allows targeted improvements.
---
# 8. Reference Authorization Artifact
Example YAML:
```yaml
version: 1
privileged_commands:
- id: backup
entrypoint: scripts/backup-root
sha256: 3d9c9c21d0c82a4c9f
reviewer: security-team
approved: 2026-03-10
- id: snapshot
entrypoint: scripts/snapshot-root
sha256: 7e2f15b1c93b
```
---
# 9. Privileged Invocation Contract
Every PEP should define:
* command identity
* allowed arguments
* execution context
* expected effects
Example:
```
rootctl snapshot
arguments:
volume: string
allowed-callers:
CI-backup
```
---
# 10. Implementation Guides
The following chapters map PECS to practical environments.
---
# 11. Implementation Guide — Linux / sudo
## Design Pattern
```
make backup
|
prepare.sh
|
sudo rootctl backup
```
---
## Example root entrypoint
```bash
#!/usr/bin/env bash
set -euo pipefail
if [[ "$EUID" -ne 0 ]]; then
echo "ERROR: must run as root"
exit 1
fi
case "$1" in
backup)
./backup-logic.sh
;;
*)
echo "unknown command"
exit 1
esac
```
---
## sudoers example
```
ci-runner ALL=(root) NOPASSWD: /usr/local/bin/rootctl
```
---
## Hash validation example
```
sha256sum rootctl
```
---
# 12. Implementation Guide — Kubernetes / RBAC
Privilege boundaries map to **cluster roles**.
Example:
```
ClusterRole: backup-controller
```
---
Example policy:
```
apiGroups:
- ""
resources:
- persistentvolumes
verbs:
- get
- list
```
---
Privileged gateway concept becomes:
```
controller operator
```
---
# 13. Implementation Guide — CI/CD Pipelines
Example:
```
pipeline
|
build
|
privileged step
|
deploy
```
Privileged step invokes **approved gateway**.
---
Example GitHub Action:
```
sudo rootctl deploy
```
---
Policy checks verify:
* artifact fingerprint
* approval metadata
---
# 14. Assessment Procedure
Assess a system using:
1. Identify privileged operations
2. Map entry points
3. Evaluate each maturity dimension
4. Produce maturity profile
5. Identify gaps
6. generate improvement roadmap
---
# 15. Regulatory Mapping
PECS aligns with:
| Standard | Relevant Controls |
| --------------- | ---------------------- |
| NIST 800-53 | AC-6, CM-3, SI-7 |
| NIST Zero Trust | policy enforcement |
| OWASP CI/CD | least privilege |
| CIS Controls | privilege management |
| SLSA | supply chain integrity |
---
# 16. Enterprise Tooling Mapping
Common enterprise tools implementing similar concepts.
| Category | Examples |
| -------------- | --------------------- |
| PAM systems | CyberArk, BeyondTrust |
| Policy engines | OPA |
| CI/CD security | GitHub OIDC policies |
| Audit logging | Splunk |
PECS can integrate with these.
---
# 17. Appendix — Terminology
PEP — Privileged Entry Point
PES — Privileged Execution Surface
PAA — Privileged Authorization Artifact
PEG — Privileged Execution Gateway
---
# 18. Appendix — Relationship to Existing Patterns
Similar concepts exist in:
* sudo command restrictions
* Microsoft JEA
* Kubernetes RBAC
* in-toto supply chain controls
PECS unifies these into **one architectural model**.
---
# 19. Future Extensions
Potential additions:
* signed execution policies
* hardware root of trust
* runtime policy agents
* AI-assisted security review
---
# Summary
This refined standard provides:
✔ stable abstract model
✔ multidimensional maturity framework
✔ practical implementation guides
✔ regulatory mapping
✔ extensibility across environments
xxx