Approvals and roles
Deployments separate requesting a change from approving it. Requesting queues a plan; approving executes it against a real AWS account. The two are distinct permissions so that one person cannot silently push infrastructure into production.
The five roles
Section titled “The five roles”StackTakt seeds five roles. Roles reach people through groups: a group holds role grants at a scope, and members inherit the union of their groups’ grants.
| Role | Can request | Can approve | Notes |
|---|---|---|---|
| Organization Admin | Yes | Yes | Full control of the organization, including identity. |
| Tenant Admin | Yes | Yes | Run, approve, and manage people within their tenants. Cannot manage the organization. |
| Operator | Yes | No | Read and write, and request deployments. |
| Requester | Yes | No | Read, and request deployments for an approver to act on. |
| Read Only | No | No | Read-only access to inventory, deployments, compliance, and audit. |
Grants scope to the whole organization, one tenant, or a single AWS account inside a tenant. Details are in Users, groups, and grants.
The self-approval rule
Section titled “The self-approval rule”A user who requested a deployment cannot approve it when anyone else with approval permission exists in that tenant. The approval fails with a clear message: ask a user with approval permission to review the plan.
There is one deliberate exception: when the requester is the sole
eligible approver in the tenant (a one-person team), the approval goes
through, and the audit event records sole_approver: true so the
condition is visible to anyone reviewing the trail later.
Approval is always a distinct recorded action. Even in the sole-approver case, the plan was created, reviewed, and approved as separate audit events under one correlation ID.
What approvers see
Section titled “What approvers see”The approval screen is the full plan: every resource with its action, the parameters as entered, the cost while running, and the control mapping the template version asserts. The apply runs exactly the reviewed plan artifact. If the plan is stale or wrong, the approver’s move is to not approve; the requester can destroy the planned deployment and create a new one.