AC-06 Least Privilege
Control statement
Employ the principle of least privilege, allowing only authorized accesses for users (or processes acting on behalf of users) that are necessary to accomplish assigned organizational tasks.
Guidance
Organizations employ least privilege for specific duties and systems. The principle of least privilege is also applied to system processes, ensuring that the processes have access to systems and operate at privilege levels no higher than necessary to accomplish organizational missions or business functions. Organizations consider the creation of additional processes, roles, and accounts as necessary to achieve least privilege. Organizations apply least privilege to the development, implementation, and operation of organizational systems.
Implementation
Evidence reader (read-only RBAC)
The assessment job holds only get/list on services, pods, statefulsets, daemonsets, Flux kustomizations and gitrepositories, and SPIRE clusterspiffeids; no secrets, no write verb; tokens and talosconfig expire after one hour and live only in /dev/shm. Implemented on the canary (kubectl auth can-i --list as the reader, 2026-10-24).
Status: implemented.
Evidence:
OpenBao SPIFFE JWT auth and policies (canary)
Least privilege: per-agent read-only policy on its own path; tokens 15 min TTL, 1 h max; the operator role platform-admin manages only ACL policies and JWT roles and reads sys/auth, no secret paths. Partial, manual: not checked live; no review of the policies by a second person.
Status: partial.
Evidence:
All controls. Source: OSCAL component definition reti-platform and NIST SP 800-53 Rev 5 (public domain).