Policy and Approvals

Approval policies define rules that require human approval before high-risk operations can proceed. They provide governance guardrails across the entire deployment lifecycle — from release deployments and promotions to cluster operations and infrastructure changes. Policies ensure that sensitive actions are reviewed by the right people before execution.

Approval Workflow

The following diagram shows the complete lifecycle of an approval-gated action:

Approval Policy Templates

Policy templates are reusable policy definitions managed at /approval-policies. They define the rules, approvers, and conditions without being bound to specific resources.

Template Structure

Managing Templates

Policy Bindings

Policy bindings attach templates to specific resources. A single template can be bound to multiple resources, and a single resource can have multiple policies bound to it.

Binding Levels

Binding Resolution

When an action is initiated, the system evaluates all bindings that match:

Quorum Rules

Quorum rules determine how many approvals are required for a policy to pass. The quorum model uses the AccessApprovalQuorum structure:

All quorum fields are combined with AND logic. There is no percentage-based, unanimous, or time-limited quorum mode as separate types.

Example: A production deployment policy might require:

• At least 2 approvals total (minApprovals: 2)
• Approvals from at least 2 different teams (minDistinctTeams: 2)
• At least 1 approval from the SRE team (requiredTeamIds)
• At least 1 approval from a user with the tech-lead role (requiredOrgRoles)
• The requester cannot be one of the approvers (requesterCanApprove: false)

Condition Constraints

Policies can include conditions that control when the policy applies:

The real AccessApprovalPolicyConditions model supports these fields:

Name: Production Deploy Gate
Scope: Environment (production)
Conditions: None (always applies)
Quorum: minApprovals 2, requiredTeamIds [SRE]
requesterCanApprove: false

Name: Off-Hours Change Gate
Scope: Organization
Conditions:
  startHour: 18, endHour: 9
  weekdays: [saturday, sunday]
  timezone: Europe/Istanbul
  requireReason: true
Quorum: minApprovals 1

Name: Production Release Approval
Scope: Project
Conditions:
  environments: [production]
Quorum: minApprovals 2, requiredTeamIds [security]
requesterCanApprove: false

Protected High-Risk Actions

The following actions can be gated behind approval policies:

Project Actions

Cluster Actions

Security Actions

Approvals Inbox

The approvals inbox at /approvals provides a unified queue for all pending approval requests.

Inbox Features

Approval Request Details

Each approval request shows:

Request Lifecycle

Self-Approval Prevention

By default, the person who initiated an action cannot approve their own request. This enforces separation of duties (SoD).

Break-Glass Override

In emergencies, a break-glass session can bypass approval requirements. Break-glass is designed for incidents where the normal approval process would cause unacceptable delay.

Break-Glass Flow

Break-Glass Audit Trail

Every break-glass action creates enhanced audit entries:

• Session ID: Links all actions to the break-glass session
• Justification: The reason provided when initiating the session
• Bypassed Policies: Which approval policies were overridden
• Actor: The user who performed each action
• Duration: Total time the session was active
• Prominent Flag: Break-glass events are visually highlighted in the audit log

Troubleshooting

Best Practices

1. Start lightweight, increase strictness over time — Begin with simple approval requirements and add complexity as your governance needs evolve
2. Always require production approvals — Production deployments should never be un-gated
3. Monitor approval latency — Track how long approvals take and optimize escalation paths to reduce deployment delays
4. Use conditions to avoid over-gating — Don't require approval for every action in every environment; focus on production and critical operations
5. Enable self-approval prevention — Separation of duties is a fundamental governance principle
6. Review break-glass events — Every break-glass session should be followed up with a review to understand why normal processes were insufficient
7. Review stale requests regularly — Approval requests that sit indefinitely create confusion; cancel and resubmit if circumstances have changed
8. Document policies clearly — Use descriptive names and descriptions so approvers understand what they are approving and why
9. Test policies in staging first — Validate that your policies work as expected before applying them to production
10. Combine with notifications — Ensure approvers receive timely notifications via Slack, email, or other channels to minimize delays