ONTAP 9

to Japanese version

Multi-admin verification overview

Beginning with ONTAP 9.11.1, you can use multi-admin verification (MAV) to ensure that certain operations, such as deleting volumes or Snapshot copies, can be executed only after approvals from designated administrators. This prevents compromised, malicious, or inexperienced administrators from making undesirable changes or deleting data.

Configuring multi-admin verification consists of:

After initial configuration, these elements can be modified only by administrators in a MAV approval group (MAV administrators).

When multi-admin verification is enabled, the completion of every protected operation requires three steps:

Multi-admin verification is not intended for use with volumes or workflows that involve heavy automation, because each automated task would require approval before the operation could be completed. If you want to use automation and MAV together, it’s recommended to use queries for specific MAV operations. For example, you could apply volume delete MAV rules only to volumes where automation is not involved, and you could designate those volumes with a particular naming scheme.

How multi-admin verification works

Multi-admin verification consists of:

  • A group of one or more administrators with approval and veto powers.

  • A set of protected operations or commands in a rules table.

  • A rules engine to identify and control execution of protected operations.

MAV rules are evaluated after role-based access control (RBAC) rules. Therefore, administrators who execute or approve protected operations must already possess the minimum RBAC privileges for those operations. Learn more about RBAC.

When multi-admin verification is enabled, system-defined rules (also known as guard-rail rules) establish a set of MAV operations to contain the risk of circumventing the MAV process itself. These operations cannot be removed from the rules table. Once MAV is enabled, operations designated by an asterisk ( * ) require approval by one or more administrators before execution, except for show commands.

  • security multi-admin-verify modify*

    Controls the configuration of multi-admin verification functionality.

  • security multi-admin-verify approval-group operations*

    Control membership in the set of administrators with multi-admin verification credentials.

  • security multi-admin-verify rule operations*

    Control the set of commands requiring multi-admin verification.

  • security multi-admin-verify request operations

    Control the approval process.

In addition to the system-defined commands, the following commands are protected by default when multi-admin verification is enabled, but you can modify the rules to remove protection for these commands.

  • security login password

  • security login unlock

  • set

The following commands can be protected in ONTAP 9.11.1 and later releases.

cluster peer delete

event config modify

security login create

security login delete

security login modify

system node run

system node systemshell

volume delete

volume flexcache delete

volume snapshot autodelete modify

volume snapshot delete

volume snapshot policy add-schedule

volume snapshot policy create

volume snapshot policy delete

volume snapshot policy modify

volume snapshot policy modify-schedule

volume snapshot policy remove-schedule

volume snapshot restore

vserver peer delete

The following command can be protected beginning with ONTAP 9.13.1:

  • volume snaplock modify

How multi-admin approval works

Any time a protected operation is entered on a MAV-protected cluster, an operation execution request is sent to the designated MAV administrator group.

You can configure:

  • The names, contact information, and number of administrators in the MAV group.

    A MAV administrator should have an RBAC role with cluster administrator privileges.

  • The number of MAV administrator groups.

    • A MAV group is assigned for each protected operation rule.

    • For multiple MAV groups, you can configure which MAV group approves a given rule.

  • The number of MAV approvals required to execute a protected operation.

  • An approval expiry period within which a MAV administrator must respond to an approval request.

  • An execution expiry period within which the requesting administrator must complete the operation.

Once these parameters are configured, MAV approval is required to modify them.

MAV administrators cannot approve their own requests to execute protected operations. Therefore:

  • MAV should not be enabled on clusters with only one administrator.

  • If there is only one person in the MAV group, that MAV administrator cannot enter protected operations; regular administrators must enter them and the MAV administrator can only approve.

  • If you want MAV administrators to be able to execute protected operations, the number of MAV administrators must be one greater than the number of approvals required. For example, if two approvals are required for a protected operation, and you want MAV administrators to execute them, there must be three people in the MAV administrators group.

MAV administrators can receive approval requests in email alerts (using EMS) or they can query the request queue. When they receive a request, they can take one of three actions:

  • Approve

  • Reject (veto)

  • Ignore (no action)

Email notifications are sent to all approvers associated with a MAV rule when:

  • A request is created.

  • A request is approved or vetoed.

  • An approved request is executed.

If the requestor is in the same approval group for the operation, they will receive an email when their request is approved.

Note: A requestor can’t approve their own requests, even if they are in the approval group. But they can get the email notifications. Requestors who are not in approval groups (that is, who are not MAV administrators) don’t receive email notifications.

How protected operation execution works

If execution is approved for a protected operation, the requesting user continues with the operation when prompted. If the operation is vetoed, the requesting user must delete the request before proceeding.

MAV rules are evaluated after RBAC permissions. As a result, a user without sufficient RBAC permissions for operation execution cannot initiate the MAV request process.

Top of Page