Among a handful of new security features, OneFS 9.12 introduces Multi-Party Authorization (MPA). MPA is an administrative approval mechanism that requires at least one additional trusted party to sign off on a requested change, for certain privileged actions within a PowerScale cluster.
As such, MPA helps to mitigate the risk of data loss or system configuration damage from critical actions, by vastly reducing the likelihood of accidental or malicious execution of consequential operations. Conceptually, MPA is fairly analogous to a bank’s safe deposit box, which requires dual control: Both the authorized owner and a bank official must be present in order to open the vault and unlock the box, ensuring that no single party can access its contents independently (dual authorization). MPA enforces a similar security control mechanism wherein operations involving critical or sensitive systems or data require explicit approval from multiple authorized entities. This ensures that no single actor can execute high-impact actions unilaterally, thereby mitigating risk and enhancing operational integrity through enforced oversight.
As such, many enterprises require MPA in order to meet industry data protection requirements, in addition to internal security mandates and best practices.
MPA can be configured and managed from the CLI, WebUI or platform API, but note that the feature is not activated by default. Once MPA has been enabled and configured, all predefined ’privileged actions’ require additional approval from an authorizing user. So this is markedly different from earlier OneFS releases, where the original requester would likely have had the basic rights and been able to execute that action in its entirety themselves.
MPA provides an approval mechanism for a set of ‘privileged actions’, which are defined in OneFS. Additionally, a new default ‘approval admin’ RBAC role is added in OneFS 9.12 specifically for this purpose. This ApprovalAdmin role is automatically assigned all the required privileges for MPA approval and configuration. Specifically:
| System Zone Roles | Privilege | Permission |
| ApprovalAdmin | ISI_PRIV_MPA_APPROVAL | Write |
| ISI_PRIV_MPA_REQUEST | Write | |
| ISI_PRIV_MPA_SETTINGS_GLOBAL | Read | |
| ISI_PRIV_MPA_SETTINGS_ZONE | Read |
There are no special licensing requirements for enabling or running MPA. So, upon installation or upgrade to OneFS 9.12, once two or more approval users have been registered, the MPA feature itself can be enabled:
Note that MPA is incompatible with, and therefore not supported on, a PowerScale cluster that is already running in Compliance Mode.
Once MPA is up and running, any approval that’s granted for a privileged operation will remain valid and viable for a defined duration. When approving a request, the approver can specify an expiry time. Once that allotted time has passed, the approved request can no longer be used to execute an action, and a new approval must be generated. If the approver does not specify an expiry time, then, by default, their approval will be valid for seven days.
At a high-level, the MPA workflow is as follows:
- The first step is registration, which requires two users with the approval privilege, both registered as internal approvers. And note that merely having an RBAC approval privilege is not enough – there is a secure process to register the users. Once there are two registered approval users, the approval admin can enable the MPA feature.
With MPA is enabled, Privileged Action Approval Requests (PAA) can be generated – either manually, or automatically when a privileged action is attempted. Any of the predefined ‘privileged actions’ will require explicit approval from internal approvers. Next, one of the registered MPA approvers blesses or rejects the PAA Request. And finally, assuming approval was granted, the requesting administrator can now go ahead and execute their privileged action.
Step Action Description 1 Approver Registration Registration requires two users with the approval privilege, both registered as internal approvers. MPA requires a secure process to register the users. 2 MPA Enablement Enable MPA via the CLI, WebUI, or platform API. Any of the predefined ‘privileged actions’ will require explicit approval from internal approvers. 3 Request Creation Generate a Privileged Action Approval Request (PAA) – either manually, or automatically when a privileged action is attempted. 4 Request Approval One of the registered MPA approvers blesses or rejects the PAA request. 5 Request Execution Assuming approval was granted, the requesting administrator can now go ahead and execute their privileged action.
MPA approver users can only reside in the System Zone, and require the new ISI_PRIV_MPA_APPROVAL and ISI_PRIV_MPA_REQUEST privileges at a minimum. So while a request can be generated from any zone, an approver for that request must reside in the system zone.
An approval request can be in one of the following states:
| Approval Request State | Description | Expiry Time |
| Approved | Indicates request is approved by an approver. Will expire in 7 days by default, or at approver-configured expiry time. | 7 days |
| Cancelled | Indicates request is Cancelled by user who created the request. will be removed from system in 7 days. | 7 days |
| Completed | Approved request has been executed, and cannot be used again. Will be removed from system in 30 days. | 30 days |
| Pending | Awaiting for approval, prior to expiry in 7 days. | 7 days |
| Rejected | Indicates request is rejected by approver, and will be removed from system in 30 days. | 30 days |
Note that, in order to approve or reject requests, an approver needs to complete a secure one-time registration.
In OneFS 9.12, the MPA request lifecycle configuration is predefined, and no updates are supported. Only the Approval API (approval_valid_before) can shorten MPA request expiration time in approved status. MPA requests are zone scoped and managed by MPA request lifecycle configuration. An authorized user can view or update a request while it’s in a ‘pending’ state, but only an MPA approver user can move the request to an ‘approved’ or ‘rejected’ state. While an approval is valid (i.e. not expired), the original requester can use it to execute the privileged action. A request stays in an ‘approved’ state until its approval expires, at which point it is moved to a ‘completed’ state.
MPA includes privileged actions, which extend across the S3 protocol, supporting immutable bucket retention and logging, cluster hardening, and the main one which is the new secure snapshots functionality. These are available for selection in the MPA configuration, for example from the WebUI MPA Requests dropdown menu:
In the next article in this series, we’ll look closer at the architectural fundaments that constitute MPA.