Configuring tenant accounts and connections
Suggest changes
PDFs
Configuring StorageGRID to accept connections from client applications requires creating one or more tenant accounts and setting up the connections.
Creating and configuring 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 cannot 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
|
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 any of the following:
-
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
-
The CLB service on Gateway Nodes, or optionally, the virtual IP address of a high availability group of Gateway Nodes
The CLB service is deprecated. Clients configured before the StorageGRID 11.3 release can continue to use the CLB service on Gateway Nodes. All other client 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:
-
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).
-
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.
-
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.
For more information about each option, see the instructions for administering StorageGRID.
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. Contact your StorageGRID administrator for more information, or see the instructions for administering StorageGRID for a description of how to find this information in the Grid Manager.
| Where connection is made | Service that client connects to | IP address | Port |
|---|---|---|---|
HA group |
Load Balancer |
Virtual IP address of an HA group |
|
HA group |
CLB Note: The CLB service is deprecated. |
Virtual IP address of an HA group |
Default Swift ports:
|
Admin Node |
Load Balancer |
IP address of the Admin Node |
|
Gateway Node |
Load Balancer |
IP address of the Gateway Node |
|
Gateway Node |
CLB Note: The CLB service is deprecated. |
IP address of the Gateway Node Note: By default, HTTP ports for CLB and LDR are not enabled. |
Default Swift ports:
|
Storage Node |
LDR |
IP address of Storage Node |
Default Swift ports:
|
Example
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 192.0.2.6 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:
-
https://192.0.2.6:10444
It is possible to configure a DNS name for the IP address that clients use to connect to StorageGRID. Contact your local network administrator.
Deciding 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 or to the CLB service on Gateway Nodes, you must enable its use.
By default, when client applications connect to Storage Nodes or the CLB service on Gateway Nodes, they must use encrypted HTTPS for all connections. Optionally, you can enable less-secure HTTP connections by selecting the Enable HTTP Connection grid option in the Grid Manager. For example, a client application might use HTTP when testing the connection to a Storage Node in a non-production environment.
|
|
Be careful when enabling HTTP for a production grid since requests will be sent unencrypted. |
|
|
The CLB service is deprecated. |
If the Enable HTTP Connection option is selected, clients must use different ports for HTTP than they use for HTTPS. See the instructions for administering StorageGRID.
Testing your connection in the 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.
-
You must have downloaded and installed python-swiftclient, the Swift command-line client.
-
You must have a Swift tenant account in the StorageGRID system.
If you have not configured security, you must add the --insecure flag to each of these commands.
-
Query the info URL for your StorageGRID Swift deployment:
swift -U <Tenant_Account_ID:Account_User_Name> -K <User_Password> -A https://<FQDN | IP>:<Port>/info capabilities
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.
-
Put an object in the container:
touch test_object swift -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
-
Get the container to verify the object:
swift -U <Tenant_Account_ID:Account_User_Name> -K <User_Password> -A https://<FQDN | IP>:<Port>/auth/v1.0 list test_container
-
Delete the object:
swift -U <Tenant_Account_ID:Account_User_Name> -K <User_Password> -A https://<FQDN | IP>:<Port>/auth/v1.0 delete test_container test_object
-
Delete the container:
swift -U `<_Tenant_Account_ID:Account_User_Name_>` -K `<_User_Password_>` -A `\https://<_FQDN_ | _IP_>:<_Port_>/auth/v1.0' delete test_container