Skip to main content
A newer release of this product is available.

Manage the permitted tenants for grid federation

Contributors netapp-lhalbert netapp-madkat
PDFs

You can allow S3 tenant accounts to use a grid federation connection between two 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 clone 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 the tenant's source grid, create groups and local users, which are automatically cloned to the tenant's destination grid. See Clone tenant groups and users.

    • Create new S3 access keys, which can be optionally cloned to the tenant's destination grid. See Clone S3 access keys using the API.

    • 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.

    If this is the source grid for the tenant (that is, if the tenant was created on this grid), a banner appears to remind you that the tenant was cloned to another grid. If you edit or delete this tenant, your changes will not be synced to the other grid.

    Grid federation tab from Tenant details page

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

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 either grid in the connection. However, any changes you make will not be copied to the other grid. If you want to keep the tenant details synchronized between grids, you must make the same edits on both grids.

  • You can't clear the Use grid federation connection permission when you are editing a tenant.

  • You can't select a different grid federation connection when you are editing a tenant.

Delete a permitted tenant

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 original tenant on the source grid, you must remove all buckets for the account on the source grid.

  • Before you can remove the cloned 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 cloned tenant, the account can no longer be used for cross-grid replication.

  • If you are removing the original tenant on the source grid, any tenant groups, users, or keys that were cloned to the destination grid will be unaffected. You can either delete the cloned tenant or allow it to manage its own groups, users, access keys, and buckets.

  • If you are removing the cloned tenant on the destination grid, clone errors will occur if new groups or users are added to the original tenant.

    To avoid these errors, remove the tenant's permission to use the grid federation connection before deleting the tenant from this grid.

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 cloning to the remote grid specified by the selected grid federation connection. If the tenant account already exists on the remote grid, cloning 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.