Skip to main content

Multi-Admin Approval

Multi-Admin Approval makes sure that sensitive operations on a StorONE system only run after several authorized administrators agree to them. No single administrator account can carry out a protected operation alone: the operation is recorded as a pending action, the authorized reviewers are notified, and it runs only once the required number of administrators has approved it.

You turn this protection on by creating action policies. Each policy names an operation that needs approval (for example, deleting a volume), the administrators who may review it, and how many approvals are required.

If you used vSnapLock (immutable scheduled snapshots) in an earlier StorONE version, it's now part of Multi-Admin Approval. You turn it on with a Snapshot scheduler policy, described below.

What it protects against

Threat What Multi-Admin Approval does Accidental changes A destructive operation, such as deleting the wrong volume or shortening a snapshot retention period, is held as a pending action and reviewed by other administrators before it runs. A mistake is caught before any data is lost. Insider threats A single administrator can't delete volumes, weaken snapshot retention, or remove the protection itself without the agreement of their peers. Every request, approval, and decline is recorded in the audit log. Compromised credentials An attacker who obtains one administrator account still can't delete volumes or run any other protected operation. Scheduled snapshots stay immutable, so a clean point in time remains available for recovery.

What you can protect

An action policy is defined by an entity type (the kind of thing it governs) and an operation type (what kind of change to it needs approval). These combinations are supported, and each can have one policy:

Entity type Operation What needs approval Volume Delete Deleting a volume. Snapshot scheduler Edit Changing a snapshot schedule. Also makes scheduled snapshots immutable. Action Policy Create, Edit, Delete Changing the approval policies themselves, so the protection can't be weakened by one administrator.

A policy is named after its entity type and operation, for example Volume Delete or Snapshot scheduler Edit.

Protecting scheduled snapshots

A Snapshot scheduler Edit policy does two things: it puts the snapshot schedule behind approval, and it makes the snapshots the scheduler creates immutable.

Diagram: what a Snapshot scheduler Edit policy protects. Changes to the snapshot schedule become pending actions that need approval. Deletion of scheduled snapshots is rejected for everyone, and the scheduler removes them when their retention ends. On-demand snapshots are not covered and are managed normally.

    Scheduled snapshots are immutable. Any request to delete a snapshot that was created by the snapshot scheduler is rejected — for all users, through every interface — with the message Action policy of type "Snapshot scheduler" blocks this operation. Retention still works. The snapshot scheduler keeps removing snapshots itself when their retention period ends, so capacity is reclaimed on a predictable schedule. The schedule is protected. Changing a schedule's frequency or retention, or disabling one of its entries, becomes a pending action that needs approval from the configured number of administrators. On-demand snapshots stay flexible. Snapshots an administrator takes manually are managed normally and can be created and removed as needed.

    The protection applies to every existing scheduled snapshot from the moment the policy is created. See Snapshots for how snapshot schedules work.

    How it works

      A user starts a protected operation. StorONE doesn't run it. It records a pending action, locks the objects involved, and emails every authorized reviewer. Reviewers approve or decline. If the user who started the operation is also an authorized reviewer, their request counts as the first approval. The operation runs automatically once the number of approvals reaches the policy's minimum and nobody has declined. The initiator or any Admin can cancel the request at any time, and nothing is applied.

      Pending Actions shows the whole lifecycle in a diagram and covers each step, including what a decline does and the safeguards built into the workflow.

      Summary of capabilities

      Capability Supported Immutable scheduled snapshots (formerly vSnapLock) Yes. All snapshots created by the snapshot scheduler, enforced across the web interface, CLI, and REST API. Automatic, retention-based snapshot expiry Yes. Approval for snapshot schedule changes Yes. Approval for volume deletion Yes. Approval for changes to the approval policies Yes: create, edit, and delete. Configurable approval threshold Yes. Two or more administrators, from a named list of reviewers. Email notification to reviewers Yes. Full audit trail Yes. System event log and audit notifications. Per-system policy configuration Yes. Configure each system separately, including replication targets. Interfaces Web interface, CLI, and REST API.

      Where to go next

        Deploying Multi-Admin Approval — the recommended set of policies, an example with three administrators, and a step-by-step setup. Action Policies — creating, editing, listing, and deleting policies. Pending Actions — reviewing, approving, declining, and cancelling. Best practices — choosing reviewers and thresholds, and keeping the protection effective. Troubleshooting — what the messages mean and what to do about them.