Skip to main content

Manage the permitted tenants for StorageGRID grid federation

Contributors netapp-lhalbert netapp-pcarriga netapp-perveilerk
PDFs

You can allow S3 tenant accounts to use one or more grid federation connections among multiple StorageGRID systems. When tenants are allowed to use a connection, special steps are required to edit tenant details or to permanently remove a tenant's permission to use the connection.

Before you begin

Create a permitted tenant

If you want to allow a new or existing tenant account to use a grid federation connection for account sync and cross-grid replication, follow the general instructions to create a new S3 tenant or edit a tenant account and note the following:

  • You can create the tenant from either grid in the connection. The grid where a tenant is created is the tenant's source grid.

  • The status of the connection must be Connected.

  • When the tenant is created or edited to enable the Use grid federation connection permission and then saved on the first grid, an identical tenant is automatically replicated to the other grid. The grid where the tenant is replicated is the tenant's destination grid.

  • The tenants on both grids will have the same 20-digit account ID, name, description, quota, and permissions. Optionally, you can use the Description field to help identify which is the source tenant and which is the destination tenant. For example, this description for a tenant created on Grid 1 will also appear for the tenant replicated to Grid 2: "This tenant was created on Grid 1."

  • For security reasons, the password for a local root user is not copied to the destination grid.

    Tip Before a local root user can sign in to the replicated tenant on the destination grid, a grid administrator for that grid must change the password for the local root user.

  • After the new or edited tenant is available on both grids, tenant users can perform these operations:

    • From any connected grid, create groups and local users, which are automatically synced to all other connected grids. See Sync tenant groups and users.

    • Create new S3 access keys for local users, which are automatically synced to other connected grids when access key sync is enabled for the tenant.

      Note S3 access keys for federated users are cloned one time from source to target when they're created. If these S3 access keys are deleted, these changes aren't synced to other grids. You must manually delete the S3 access keys on the other grids.

    • Create identical buckets on both grids in the connection and enable cross-grid replication in one direction or in both directions. See Manage cross-grid replication.

View a permitted tenant

You can see details for a tenant that is permitted to use a grid federation connection.

Steps

  1. Select Tenants.

  2. From the Tenants page, select the tenant name to view the tenant details page.

  3. Optionally select the Grid federation tab to monitor the grid federation connections.

Edit a permitted tenant

If you need to edit a tenant that has the Use grid federation connection permission, follow the general instructions for editing a tenant account and note the following:

  • If a tenant has the Use grid federation connection permission:

  • You can edit tenant details from any grid in the connection. Changes to tenant-level settings (such as name, description, or quota) as well as groups, local users, and S3 access keys owned by local users are automatically synced to all connected grids.

  • You can change Allowed grid federation connections only on the source grid.

  • You can add a new grid federation connection.

    Note You can't unselect any existing connections. To remove a connection, go to the details page for the tenant, select the Grid federation tab, and remove the permission.

  • If you add a new connection while editing a tenant, this tenant will be replicated to the remote grid specified by that new connection.

Delete a permitted tenant

Caution If you remove either the original tenant from the source grid or the synced tenant from the destination grid, the tenant is removed from all the grids, so the account can no longer be used.

If you need to remove a tenant that has the Use grid federation connection permission, follow the general instructions for deleting a tenant account and note the following:

  • Before you can remove the tenant on the source grid, you must remove all buckets for the account on the source grid.

  • Before you can remove the synced tenant on the destination grid, you must remove all buckets for the account on the destination grid.

  • If you remove either the original or the synced tenant, the account can no longer be used for cross-grid replication.

  • If you are removing the original tenant on the source or any destination grid, tenant groups, users, and keys that were synced to the destination grids are also removed.

Remove Use grid federation connection permission

To prevent a tenant from using a grid federation connection, you must remove the Use grid federation connection permission.

steps to remove grid federation connection

Before removing a tenant's permission to use a grid federation connection, note the following:

  • You can't remove the Use grid federation connection permission if any of the tenant's buckets have cross-grid replication enabled. The tenant account must disable cross-grid replication for all of their buckets first.

  • Removing the Use grid federation connection permission does not delete any items that have already been replicated between grids. For example, any tenant users, groups, and objects that exist on both grids aren't deleted from either grid when the tenant's permission is removed. If you want to delete these items, you must manually delete them from both grids.

  • If you want to re-enable this permission with the same grid federation connection, delete this tenant on the destination grid first; otherwise, re-enabling this permission will result in an error.

Note Re-enabling the Use grid federation connection permission makes the local grid the source grid and triggers syncing to the remote grid specified by the selected grid federation connection. If the tenant account already exists on the remote grid, syncing will result in a conflict error.
Before you begin

Disable replication for tenant buckets

As a first step, disable cross-grid replication for all tenant buckets.

Steps

  1. Starting from either grid, sign in to the Grid Manager from the primary Admin Node.

  2. Select Configuration > System > Grid federation.

  3. Select the connection name to display its details.

  4. On the Permitted tenants tab, determine if the tenant is using the connection.

  5. If the tenant is listed, instruct them to disable cross-grid replication for all of their buckets on both grids in the connection.

    Tip You can't remove the Use grid federation connection permission if any tenant buckets have cross-grid replication enabled. The tenant must disable cross-grid replication for their buckets on both grids.

Remove permission for tenant

After cross-grid replication is disabled for tenant buckets, you can remove the tenant's permission to use the grid federation connection.

Steps

  1. Sign in to the Grid Manager from the primary Admin Node.

  2. Remove the permission from the Grid federation page or the Tenants page.

    Grid federation page

    1. Select Configuration > System > Grid federation.

    2. Select the connection name to display its details page.

    3. On the Permitted tenants tab, select radio button for the tenant.

    4. Select Remove permission.

    Tenants page

    1. Select Tenants.

    2. Select the tenant's name to display the details page.

    3. On the Grid federation tab, select radio button for the connection.

    4. Select Remove permission.

  3. Review the warnings in the confirmation dialog box, and select Remove.

    • If the permission can be removed, you are returned to the details page and a success message is shown. This tenant can no longer use the grid federation connection.

    • If one or more tenant buckets still have cross-grid replication enabled, an error is displayed.

      error message shown if tenant has cgr enabled for a bucket

      You can do either of the following:

      • (Recommended.) Sign in to the Tenant Manager and disable replication for each of the tenant's buckets. See Manage cross-grid replication. Then, repeat the steps to remove the Use grid connection permission.

      • Remove the permission by force. See the next section.

  4. Go to the other grid and repeat these steps to remove the permission for the same tenant on the other grid.

Remove the permission by force

If necessary, you can force the removal of a tenant's permission to use a grid federation connection even if tenant buckets have cross-grid replication enabled.

Before removing a tenant's permission by force, note the general considerations for removing the permission as well as these additional considerations:

  • If you remove the Use grid federation connection permission by force, any objects that are pending replication to the other grid (ingested but not yet replicated) will continue to be replicated. To prevent these in-process objects from reaching the destination bucket, you must remove the tenant's permission on the other grid as well.

  • Any objects ingested into the source bucket after you remove the Use grid federation connection permission will never be replicated to the destination bucket.

Steps

  1. Sign in to the Grid Manager from the primary Admin Node.

  2. Select Configuration > System > Grid federation.

  3. Select the connection name to display its details page.

  4. On the Permitted tenants tab, select radio button for the tenant.

  5. Select Remove permission.

  6. Review the warnings in the confirmation dialog box, and select Force remove.

    A success message appears. This tenant can no longer use the grid federation connection.

  7. As required, go to the other grid and repeat these steps to force-remove the permission for the same tenant account on the other grid. For example, you should repeat these steps on the other grid to prevent in-process objects from reaching the destination bucket.