Skip to main content

Configure tenant accounts and connections

Contributors netapp-perveilerk netapp-madkat netapp-lhalbert ssantho3

Configuring StorageGRID to accept connections from client applications requires creating one or more tenant accounts and setting up the connections.

Create and configure Swift tenant accounts

A Swift tenant account is required before Swift API clients can store and retrieve objects on StorageGRID. Each tenant account has its own account ID, groups and users, and containers and objects.

Swift tenant accounts are created by a StorageGRID grid administrator using the Grid Manager or the Grid Management API.

When creating a Swift tenant account, the grid administrator specifies the following information:

  • Display name for the tenant (the tenant's account ID is assigned automatically and can't be changed)

  • Optionally, a storage quota for the tenant account — the maximum number of gigabytes, terabytes, or petabytes available for the tenant's objects. A tenant's storage quota represents a logical amount (object size), not a physical amount (size on disk).

  • If single sign-on (SSO) is not in use for the StorageGRID system, whether the tenant account will use its own identity source or share the grid's identity source, and the initial password for the tenant's local root user.

  • If SSO is enabled, which federated group has Root access permission to configure the tenant account.

After a Swift tenant account is created, users with the Root access permission can access the Tenant Manager to perform tasks such as the following:

  • Setting up identity federation (unless the identity source is shared with the grid), and creating local groups and users

  • Monitoring storage usage

Important Swift users must have the Root access permission to access the Tenant Manager. However, the Root access permission does not allow users to authenticate into the Swift REST API to create containers and ingest objects. Users must have the Swift Administrator permission to authenticate into the Swift REST API.

How client connections can be configured

A grid administrator makes configuration choices that affect how Swift clients connect to StorageGRID to store and retrieve data. The specific information you need to make a connection depends upon the configuration that was chosen.

Client applications can store or retrieve objects by connecting to the Load Balancer service on Admin Nodes or Gateway Nodes, or optionally, the virtual IP address of a high availability (HA) group of Admin Nodes or Gateway Nodes.

Note All applications that depend on StorageGRID to provide load balancing should connect using the Load Balancer service.
  • Storage Nodes, with or without an external load balancer

When configuring StorageGRID, a grid administrator can use the Grid Manager or the Grid Management API to perform the following steps, all of which are optional:

  1. Configure endpoints for the Load Balancer service.

    You must configure endpoints to use the Load Balancer service. The Load Balancer service on Admin Nodes or Gateway Nodes distributes incoming network connections from client applications to Storage Nodes. When creating a load balancer endpoint, the StorageGRID administrator specifies a port number, whether the endpoint accepts HTTP or HTTPS connections, the type of client (S3 or Swift) that will use the endpoint, and the certificate to be used for HTTPS connections (if applicable). Swift supports these endpoint types.

  2. Configure Untrusted Client Networks.

    If a StorageGRID administrator configures a node's Client Network to be untrusted, the node only accepts inbound connections on the Client Network on ports that are explicitly configured as load balancer endpoints.

  3. Configure high availability groups.

    If an administrator creates an HA group, the network interfaces of multiple Admin Nodes or Gateway Nodes are placed into an active-backup configuration. Client connections are made using the virtual IP address of the HA group.

See Configuration options for HA groups for more information.

Summary: IP addresses and ports for client connections

Client applications connect to StorageGRID using the IP address of a grid node and the port number of a service on that node. If high availability (HA) groups are configured, client applications can connect using the virtual IP address of the HA group.

Information required to make client connections

The table summarizes the different ways that clients can connect to StorageGRID and the IP addresses and ports that are used for each type of connection. See IP addresses and ports for client connections or contact your StorageGRID administrator for more information.

Where connection is made Service that client connects to IP address Port

HA group

Load Balancer

Virtual IP address of an HA group

  • Load balancer endpoint port

Admin Node

Load Balancer

IP address of the Admin Node

  • Load balancer endpoint port

Gateway Node

Load Balancer

IP address of the Gateway Node

  • Load balancer endpoint port

Storage Node


IP address of Storage Node

Default Swift ports:

  • HTTPS: 18083

  • HTTP: 18085


To connect a Swift client to the Load Balancer endpoint of an HA group of Gateway Nodes, use a URL structured as shown below:

  • https://VIP-of-HA-group:LB-endpoint-port

For example, if the virtual IP address of the HA group is and the port number of a Swift Load Balancer endpoint is 10444, then a Swift client could use the following URL to connect to StorageGRID:


It is possible to configure a DNS name for the IP address that clients use to connect to StorageGRID. Contact your local network administrator.

Decide to use HTTPS or HTTP connections

When client connections are made using a Load Balancer endpoint, connections must be made using the protocol (HTTP or HTTPS) that was specified for that endpoint. To use HTTP for client connections to Storage Nodes, you must enable its use.

By default, when client applications connect to Storage Nodes, they must use encrypted HTTPS for all connections. Optionally, you can enable less-secure HTTP connections by selecting the Enable HTTP for Storage Node connections option in Grid Manager. For example, a client application might use HTTP when testing the connection to a Storage Node in a non-production environment.

Important Be careful when enabling HTTP for a production grid because requests and responses will be sent unencrypted.

If the Enable HTTP for Storage Node connections option is selected, clients must use different ports for HTTP than they use for HTTPS.

Test your connection in Swift API configuration

You can use the Swift CLI to test your connection to the StorageGRID system and to verify that you can read and write objects to the system.

Before you begin
  • You must have downloaded and installed python-swiftclient, the Swift command-line client.

  • You must have a Swift tenant account in the StorageGRID system.

About this task

If you have not configured security, you must add the --insecure flag to each of these commands.

  1. Query the info URL for your StorageGRID Swift deployment:

    -U <Tenant_Account_ID:Account_User_Name>
    -K <User_Password>
    -A https://<FQDN | IP>:<Port>/info

    This is sufficient to test that your Swift deployment is functional. To further test account configuration by storing an object, continue with the additional steps.

  2. Put an object in the container:

    touch test_object
    -U <Tenant_Account_ID:Account_User_Name>
    -K <User_Password>
    -A https://<FQDN | IP>:<Port>/auth/v1.0
    upload test_container test_object
    --object-name test_object
  3. Get the container to verify the object:

    -U <Tenant_Account_ID:Account_User_Name>
    -K <User_Password>
    -A https://<FQDN | IP>:<Port>/auth/v1.0
    list test_container
  4. Delete the object:

    -U <Tenant_Account_ID:Account_User_Name>
    -K <User_Password>
    -A https://<FQDN | IP>:<Port>/auth/v1.0
    delete test_container test_object
  5. Delete the container:

    -U `<_Tenant_Account_ID:Account_User_Name_>`
    -K `<_User_Password_>`
    -A `\https://<_FQDN_ | _IP_>:<_Port_>/auth/v1.0'
    delete test_container