Kryptkeeper
Feature

Approvals and guardrails

Sensitive changes need a second person, and show their impact first.

Requests, policies and exceptions can require a second approver. Before anything destructive, Kryptkeeper shows the blast radius: what will break and who owns it.

kryptkeeper.example.com/inbox

How it works

  1. Approve a pending request

    A second person reviews and approves a certificate request.

    5 steps

  2. Decide requests with the approver role

    A dedicated approver decides requests on the templates that name them.

    2 steps

  3. Reject a request

    Turn a request down with a reason the requester can read.

    4 steps

  4. Approve a policy or exception

    Approve a proposed policy change or risk exception before it takes effect.

    6 steps

  5. Check the blast radius first

    See every certificate and service a destructive change would affect.

    9 steps

Paths that use this