OneFS 9.12 sees the addition of a new Secure Snapshots feature. The core ethos of this new functionality is to provide snapshot immutability, in order to protect them from being altered or deleted – either by accident or by a malicious actor. In addition to the snapshots themselves, Secure Snapshots functionality also includes protection of the snapshot schedules. Since these schedules are responsible for creating future snapshots, tampering with them could also lead to unforeseen and undesirable consequences, such as schedule modification which overwhelms the cluster with snapshots, or ceases to generate snapshots all together.
Secure snapshots are predicated upon OneFS multi-party authorization (MPA), which prevents a user from executing configuration changes on snapshots and snapshot schedules without additional approval.
Secure Snapshots in conjunction with MPA protect a subset of snapshot operations, or ‘privileged actions’. These include:
- Deleting a snapshot prior to its expiry date
- Shortening the expiry date of a snapshot
- Renaming a snapshot using reserved name
- Modifying a snapshot schedule
These following highlighted snapshot operations are privileged and require secondary approval when MPA is enabled:
| Snapshot Operation | MPA Required? |
| Deletion of a snapshot without an expiry date | No |
| Deletion of a snapshot with an expiry date once that expiry date has passed | No |
| Deletion of a snapshot that has an expiry date before that expiry date has passed | Yes |
| Modifying a snapshot schedule | Yes |
| Adding an expiry date to a snapshot | No |
| Extending the expiry date of a snapshot | No |
| Reducing the expiry date of a snapshot | Yes |
| Renaming a snapshot using reserved name used | Yes |
| Adding a lock to a snapshot | No |
| Removing a lock from a snapshot | No |
With Secure Snapshots, you cannot delete or modify snapshots with expiration dates or modify a snapshot schedule without these actions going through MPA first. So when you make these requests, the information about the request is also sent to MPA so that approver can see what changes you’re trying to make so they know exactly what they are actually approving or not.
OneFS 9.12 also checks whether user-generated snapshots have overlapping names with snapshots that could be potentially created by demons on the cluster. So the basic workflow is that users will make a request to delete a snapshot or edit a snapshot and then will have to go through MPA and make the exact same request again. If the approver grants the request, the snapshot deletion will proceed. If the approver rejects or does not respond to the request, if they have approved the request, no action occurs. They’ve made the same request a second time, and if they haven’t responded or if they haven’t, if they’ve rejected the request, it just will not make the request or issue a new request.
There are three principal prerequisites for deploying Secure Snapshots, which are as follows:
- Secure Snapshots can only be enabled once the cluster has been committed to OneFS 9.12 or later.
- SnapshotIQ needs to be licensed and the ISI_PRIV_SNAPSHOT privilege is required.
- MPA must already be active on the cluster and configured for two or more approvers.
The MPA enablement and approver registration workflow is as follows:
1. First, Create users and grant approval privilege.
Approver registration be configured from the CLI with the following set of commands.
First, configure two approver users – in this case ‘mpa-approver1’ and ‘mpa-approver2’:
# isi auth users create mpa-approver1 --enabled true --password <passwd> # isi auth users create mpa-approver2 --enabled true --password <passwd>
Next, create a group for these users. Eg. ‘mpa-group’:
# isi auth group create mpa-group
Add the approver users to their new group:
# isi auth group modify mpa-group --add-user mpa-approver1 # isi auth group modify mpa-group --add-user mpa-approver2
Then add the new group (mpa-group) to the RBAC ApprovalAdmin role:
# isi –debug auth roles modify ApprovalAdmin --add-group mpa-group
If needed, configure approvers’ SSH login to the cluster.
# isi auth roles create ssh-role # isi auth roles modify ssh-role --add-group mpa-group --add-priv-read ISI_PRIV_LOGIN_SSH
Next, add the approver users to MPA and complete their registration. This involves initiating registration, using the secret or embedded URL in conjunction with a third party code generator to create a time-based one-time password or TOTP.
Here, the ‘mpa-approver1’ user is registered first:
# isi mpa initiate-registration Initiated registration successfully: (Online utility can be used to convert URL to QR code for use with authenticator) account: Dell Technologies algorithm: SHA1 digits: 6 issuer: mpa-approver1 period: 30 secret: 5KHIHISJZPB7UTPRNEBLSIMI5L4R6K6UI url: otpath://totp/Dell%Technologies:mpa-approver1?secret=5KHIHISJZPB7UTPRNEBLSIMI5L4R6K6UI&issuer=Dell%20Technologies&algorithm=SHA1&digits=6&period=30
The user secret or URL returned can be used to set up a TOTP in Google Authenticator, or another similar application.
This secure one-time registration can be performed as follows:
a. First, initiate the OneFS registration process to obtain a URI, which can then be generated into a QR code by a 3rd party app. For example:
b. Next, convert the QR code (or URI) into a time-based one-time password code via Google Authenticator, Microsoft Authenticator, or another TOTP app:
c. Finally, complete the OneFS approver registration wizard:
This can be performed from the CLI as follows:
# isi mpa complete-registration totp_code: ****** Approver registered.
Or from the WebUI, under WebUI under Access > Multi-Party Authorization > Registration:
This process should then be repeated for the second (ie. ‘mpa-approver2’) role.
- Once the approvers are registered, MPA can now be enabled via its global settings.
This can be performed from the WebUI under Access > Multi-Party Authorization > Settings:
Note that MPA cannot be enabled on clusters without having at least two registered approvers.
When successfully enabled, the following status banner will be displayed:
Alternatively, enabling via the CLI can be done with the following command syntax:
# isi mpa settings global modify –enable true # isi mpa settings global view Multi Party Authorization is enabled
Once MPA is enabled on a cluster, any requests to delete Secure Snapshots or modify their schedules, etc, are paused pending approval.
In the next article in this series, we’ll turn our attention to the configuration and management of Secure Snapshots.