Separate capability from ownership
A global permission does not mean membership of every System. Check both layers when an ordinary account can see an action but cannot access the intended service. Platform administrator override is a distinct elevated case.
Bind environments deliberately
The supported built-ins are PlatformAdmin, ApprovalAdmin, DevelopmentEngineer, TestEngineer, SystemOperator and Viewer. Environment scope belongs on bindings, including allowed_environments. It must not be inferred from a role name or namespace spelling.
Test access outside the assignment
Use separate accounts to test the intended service, another team’s resource and an environment outside the binding. Successful access as PlatformAdmin does not demonstrate ordinary user isolation. Inspect server authorization as well as visible controls.
Walk through the task
Identify the business boundary
Decide which System owns the workload and which Services belong beneath it. Assign membership according to actual team responsibility.
Select the required capabilities
Use the current permission catalog and supported roles. Keep engineering work, ApprovalAdmin review and platform administration separate.
Read the canonical role definitionsSet and verify environment scope
Inspect allowed environments on bindings and the registered namespace environment. Test an allowed request and an out-of-scope request with a non-admin account.
Inspect resource and environment guardsReview resulting activity
Use an account with audit access to filter by actor, action or resource. Audit reading is a separate capability, not an automatic right of every VM user.
Inspect /audit-logs and audit:read
Requirements and limits
- Application authorization complements Kubernetes RBAC; it does not replace cluster service-account or infrastructure isolation.
- PlatformAdmin override means an administrator-only test cannot validate normal user scope.
- Demo role switching illustrates views; validate identity integration, bindings and denied requests in your installation.
Documentation and implementation
- Roles, membership and environments
Current role names and the two authorization layers.
- API authorization requirements
x-rbac describes capabilities, resource roles and scope filters.
- Operation approval requirement
Operation permission does not imply review bypass.
- Deployment responsibilities
Infrastructure access still needs correct installation configuration.
Common questions
Is DevelopmentEngineer always test-only?
The binding supplies environment scope. Inspect its allowed environments and registered namespace context rather than inferring scope from the role name.
Does membership grant approval authority?
No. Membership concerns resource access. Approval authority is a separate platform capability and responsibility.