Controlling access to table shares

AIStor uses the built-in access management where a user’s attached policies determines the operations and data paths to which they have access.

The mc table share commands require the following permissions:

• admin:DeltaSharingCreateShare
• admin:DeltaSharingGetShare
• admin:DeltaSharingListShares
• admin:DeltaSharingUpdateShare
• admin:DeltaSharingDeleteShare

The user must also have s3:GetObject and s3:ListBucket permissions on all buckets and paths in which they must manage table shares.

The mc table share token commands require the following permissions:

• admin:DeltaSharingGetShare
• admin:DeltaSharingListShares
• admin:DeltaSharingCreateToken
• admin:DeltaSharingListTokens
• admin:DeltaSharingDeleteToken

Use the generated token to create a profile.share JSON document as the profile for use with your preferred client application.

To restrict share management to only specific buckets, ensure the user has a policy which restricts bucket read access to only the required paths. For example, the following policy would support a user with administrative privileges to perform all table sharing related operations within only the analytics/ bucket.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DeltaSharingAdmin",
      "Effect": "Allow",
      "Action": [
        "admin:DeltaSharingCreateShare",
        "admin:DeltaSharingUpdateShare",
        "admin:DeltaSharingGetShare",
        "admin:DeltaSharingListShares",
        "admin:DeltaSharingDeleteShare",
        "admin:DeltaSharingCreateToken",
        "admin:DeltaSharingListTokens",
        "admin:DeltaSharingDeleteToken"
      ],
      "Resource": "*"
    },
    {
      "Sid": "ReadAnalyticsBucket",
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:ListBucket"
      ],
      "Resource": [
        "arn:aws:s3:::analytics",
        "arn:aws:s3:::analytics/*"
      ]
    }
  ]
}

Delta Sharing uses a token system for authenticating to the share source. AIStor Table Sharing supports both the Bearer and OAuth 2.0 methods of token generation. Token generation through OAuth involves machine-to-machine processing within AIStor and has no relation nor integration with OIDC Identity Management. You can configure either method depending on your organizations security and access policies.

To enable OAuth 2.0 token generation, you must set the MINIO_DELTA_SHARING_OAUTH_ENABLED environment variable to on. You can additionally set the MINIO_DELTA_SHARING_OAUTH_TOKEN_EXPIRY flag to set a static expiration for all generated tokens regardless of parameters sent through the CLI command.

Once enabled, tokens generated with mc table share token include OAuth-specific information. The following examples contain example output for Bearer vs OAuth token profiles. The exact output of tokens in a live environment may vary:

{
  "shareCredentialsVersion": 1,
  "endpoint": "https://aistor-lb.example.net:9000/_delta-sharing/v1",
  "bearerToken": "dapi..."
}

{
  "shareCredentialsVersion": 2,
  "type": "oauth_client_credentials",
  "endpoint": "https://aistor-lb.example.net:9000/_delta-sharing/v1",
  "tokenEndpoint": "https://aistor-lb.example.net:9000/_delta-sharing/v1/oauth/token",
  "clientId": "tok-12345",
  "clientSecret": "dapi..."
}

Bearer and OAuth tokens have different default expiration periods. When a token expires, AIStor returns an HTTP 401 error with code TOKEN_EXPIRED. Client applications should handle this error and take appropriate action based on the token type:

To create a bearer token without expiration, omit the --expires flag when running mc table share token create.