Configuring S3 Gateway

Describes how to configure the S3 gateway.

NOTICE The S3 gateway is included in EEP 6.0.0 - EEP 8.0.0 repositories.

To configure the S3 Gateway, add S3 gateway tenants (users) and credentials to the tenants.json file and change the deployment mode in the minio.json file. After you update and save the files, restart the objectstore service.

IMPORTANT If a bucket does not have custom policies applied and mixed deployment mode is set, you must remove the policy file for the bucket and restart the objectstore service to avoid permissions issues any time you:
  • change the owner of the bucket
  • add new tenants that are also bucket owners
The bucket policy file is located in FS_PATH/.minio.sys/buckets/BUCKET_NAME/policy.json. To restart the objectstore service, see Restarting the S3 Gateway Service.

Distributed Mode

S3 gateway 2.1.0 and later supports distributed mode. S3 gateway 2.0.x does not support distributed mode.

Note the following points related to S3 gateway 2.1.0 and later in distributed mode:
  • In distributed mode, instances of S3 gateway share user and policy information only, as well as locks between nodes.
  • Distributed mode does not include proxy or load balancing in front of instances. You must configure and install proxy and load balancing manually.
  • Distributed mode only works for S3 mode.
  • Three or more nodes is recommended for S3 gateway in distributed mode. If only one node is active, the node will be in read-only mode.
To enable distributed mode for S3 gateway 2.1.0 and later:
  1. Configure S3 gateway 2.1.0 or later on three or more nodes.
  2. Disable caching in Fuse clients.
  3. On each S3 gateway node, update the /opt/mapr/objectstore-client/objectstore-client-<version>/conf/minio.json file with the accessKey, secretKey, and ldap. The value for each of these properties must be identical across all the minio.json files.
  4. On all S3 gateway 2.1.0 or later nodes, verify that the distributedHosts property contains the list of nodes with mount paths, for example:
    "distributedHosts": "http(s)://HOST1:PORT1/MOUNT_PATH1 http(s)://HOST2:PORT2/MOUNT_PATH2" 
    Note that the mount path on all nodes should target the same folder in the file system.
  5. If the cluster is secure with self-signed certificates, copy the public certificates for each host to the /opt/mapr/objectstore-client/objectstore-client-<version>/conf/certs/CAs directory. To ignore validation of the certificates, set "insecureSkipVerify": true.

About Credentials

In the S3 world, credentials represent the application and not the identity of the end user. The application layer is responsible for end-user verification. The S3 administrator must assign S3 credentials for the application or set of applications and optionally, map those S3 credentials to a data-fabric identity.

As defined in the Amazon S3 documentation, the S3 REST API uses a “key” and “secret” (in a REST-like manner) as credentials to authenticate to the underlying object storage and authorize access to data.

S3 gateway supports a multi-tenant scenario in which the S3 administrator can configure one or more credentials with the appropriate data-fabric credential mapping. The S3 administrator can assign credentials to a user and, optionally, map them to a data-fabric identity.

For an overview of tenants and multi-tenancy, see Multitenancy on File System.

Add Tenants and Credentials in the tenants.json File

The tenants.json file describes the tenants configuration. This file consists of a JSON object with two keys: credentials and tenants. The credentials key relates more to S3 gateway authorization, whereas the tenants key relates to the users in the system.

The credentials key contains an array of objects with the following fields:
  • accessKey - S3 format access key
  • secretKey - S3 format secret key
  • Tenant - Internal tenant name, used to link an access key to an operating system user
The tenants key contains an array of objects with the following fields:
  • uid - Operating system user ID for file impersonation
  • gid - Operating system group ID for file impersonation
  • name - Internal tenant name, used to link an access key to an operating systems user

You add or update tenants (object storage users) and credentials in the /opt/mapr/objectstore-client/objectstore-client-<version>/conf/tenants.json file. The /opt/mapr/objectstore-client/objectstore-client-<version>/conf directory also contains a tenants-sample.json file that you can use for reference.

Example of a tenants.json configuration:
{
    "tenants": [
        {
            "name": "tenant1",
            "uid": 5001,
            "gid": 5001
        }
	],
 
    "credentials": [
        {
            "accessKey": "accessKey1",
            "secretKey": "secretKey1",
            "tenant": "tenant1"
        }
	]
}

Set the Deployment Mode (Authorization Type) in the minio.json File

The deployment mode sets the type of authorization being used. The default deployment mode is mixed. You can edit the deploymentMode parameter in the /opt/mapr/objectstore-client/objectstore-client-<version>/conf/minio.json file to change the deployment mode setting.

The S3 gateway supports the following deployment modes:
Option Deployment Mode Description
1 fs_only Enforced by MapR File System file permissions only. The S3 bucket policy is disabled. Access is granted based on the bucket owner UID and GID, not read/write/execute permissions.
  • Configuration maps the application key or secret to a MapR ID.
  • S3 policy is not used and the policy check is skipped.
  • MapR file security validates inbound mapped UID and GID to authorize read or write file permissions.
2 mixed The default setting. Uses a mix of the MapR File System and S3 bucket policy security enforcement.
  • Configuration maps the application key or secret to a MapR ID.
  • S3 bucket policy and MapR file security are enforced. Specifically, the two authorization models.
  • The access key is ignored and the filesystem permissions determine access.
3 s3_only Enforced by s3 bucket policy only.
  • No configuration to map the application key or secret to a MapR ID.
  • All the files in the filesystem are owned by the user that runs the S3 gateway processes (typically the mapr user).
  • Access is controlled by the secret access key and the key ID.

Secure the Data

To prevent unauthorized access to data, secure the data based on the configured deployment mode:

  • For mixed mode, set folder permissions and upload the S3 policies.
  • For fs_only mode, set folder permissions to allow authorized users access to folders.
  • For s3_only mode, upload the S3 policies.

Set the Path to Mount the Filesystem

If you are using fs_only or mixed mode, set the path to mount the filesystem.

  • Server node - In the minio.json file, set the fsPath parameter to the filesystem mount path. By default, the path is set to /mapr/<clustername>/apps/s3/<nodename>. If you want to share existing folders with users, set the fsPath parameter to point to the directory with the folders that you want to share. All the folders in the directory (to which fsPath points) are accessible as buckets.
  • Edge node - If you completed the Edge Node Installation steps, you may have already set the path to mount the filesystem when you ran the objectstore configure.sh script with the --path parameter. No action is required.

For more information about deployment modes, see S3 Gateway.

Restarting the S3 Gateway Service

Start, restart, or stop the S3 gateway by using the command appropriate for the node:

Server Node
/opt/mapr/bin/maprcli node services -name objectstore -nodes <node_name> -action [ start |
          restart | stop ]

Edge Node

sudo /opt/mapr/objectstore-client/objectstore-client-<version>/bin/objectstore.sh [ start |
        stop ]