Controlling Access to AIStor Tables

AIStor Tables uses standard MinIO AIStor policy-based access control (PBAC) to define authorized actions on warehouses, namespaces, tables, and views. For more information about PBAC in MinIO AIStor, see Access Control with Policy Management

AIStor Tables policies use the s3tables: action namespace and the arn:aws:s3tables::: ARN scheme. Because MinIO AIStor uses Warehouse terminology where AWS S3 Tables uses TableBucket, the warehouse-level action names support both spellings as equivalent aliases. For example, s3tables:CreateWarehouse and s3tables:CreateTableBucket are interchangeable.

AIStor Tables uses ARN patterns to identify resources in policies:

In a table or view ARN, the final segment is the resource’s stable UUID, not its name. Use * in place of the UUID to match all tables or all views in the warehouse, or supply a specific UUID to scope a policy to one resource. See Find a table’s UUID for how to look up a UUID.

arn:aws:s3tables:::bucket/{warehouse}
arn:aws:s3tables:::bucket/{warehouse}/table/*
arn:aws:s3tables:::bucket/{warehouse}/view/*

Condition keys provide additional context for policy evaluation:

You can use standard condition operators such as StringEquals, StringLike, or StringNotEquals.

Each action accepts only a specific set of condition keys. MinIO AIStor rejects a policy that uses a condition key an action in the same statement does not accept, with an unsupported condition keys error. Put actions that take different condition keys in separate statements.

The s3tables:WarehouseTag/<key> and s3tables:TableTag/<key> keys use the AWS variable-suffix form: the tag key is part of the condition key name. See Tag-based access control for details.

There are two ways to restrict a policy to a specific table or view:

• By name, using condition keys. Use a wildcard resource ARN (.../table/* or .../view/*) and filter with the s3tables:namespace, s3tables:tableName, or s3tables:viewName condition keys. This approach is easy to read because it uses human-readable names, but the policy follows the name: if you rename the table, the policy no longer applies.

• By UUID, in the resource ARN. Put the resource UUID directly in the ARN (.../table/{uuid}). This requires no condition evaluation and is the most precise option. Because the UUID is assigned at creation time and never changes, a UUID-based policy continues to apply across renames. The table or view must already exist before you can write a UUID-based policy. See Find a table’s UUID.

Actions control access to specific API operations.

Warehouse actions:

Namespace actions:

Table actions:

Maintenance configuration actions:

These actions control the table maintenance configuration. Warehouse-level and table-level configuration are separate actions.

Tag actions:

Encryption actions:

View actions

Catalog actions

Wildcard action

The wildcard action allows specifying all actions without listing each individually.

These examples demonstrate common access control patterns for AIStor Tables.

Grants read-only access to every namespace, table, and view in a warehouse, allowing users to query metadata, schemas, and data without making modifications. Because the resource list includes both .../table/* and .../view/*, this policy covers tables and views.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "ReadOnlyWarehouseAccess",
      "Effect": "Allow",
      "Action": [
        "s3tables:GetWarehouse",
        "s3tables:ListNamespaces",
        "s3tables:GetNamespace",
        "s3tables:ListTables",
        "s3tables:GetTable",
        "s3tables:GetTableData",
        "s3tables:GetTableMetadataLocation",
        "s3tables:ListViews",
        "s3tables:GetView"
      ],
      "Resource": [
        "arn:aws:s3tables:::bucket/analytics",
        "arn:aws:s3tables:::bucket/analytics/table/*",
        "arn:aws:s3tables:::bucket/analytics/view/*"
      ]
    }
  ]
}

Permissions granted:

• View warehouse metadata.
• List and view namespaces.
• List and view table and view schemas.
• Read table metadata, snapshots, and data.

Grants full read-write access to a warehouse, allowing users to create, modify, and delete namespaces, tables, and views. The .../view/* resource and the view actions ensure that statements such as CREATE OR REPLACE TABLE succeed.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "ReadWriteWarehouseAccess",
      "Effect": "Allow",
      "Action": [
        "s3tables:GetWarehouse",
        "s3tables:ListNamespaces",
        "s3tables:CreateNamespace",
        "s3tables:GetNamespace",
        "s3tables:DeleteNamespace",
        "s3tables:ListTables",
        "s3tables:CreateTable",
        "s3tables:GetTable",
        "s3tables:GetTableData",
        "s3tables:PutTableData",
        "s3tables:UpdateTable",
        "s3tables:UpdateTableMetadataLocation",
        "s3tables:DeleteTable",
        "s3tables:RenameTable",
        "s3tables:ListViews",
        "s3tables:CreateView",
        "s3tables:GetView",
        "s3tables:UpdateView",
        "s3tables:DeleteView"
      ],
      "Resource": [
        "arn:aws:s3tables:::bucket/analytics",
        "arn:aws:s3tables:::bucket/analytics/table/*",
        "arn:aws:s3tables:::bucket/analytics/view/*"
      ]
    }
  ]
}

Permissions granted:

• All read-only permissions.
• Create, update, and delete namespaces.
• Create, update, delete, and rename tables and views.
• Commit data changes to tables.

Restrict access to a single namespace within a warehouse, enabling multi-tenant scenarios where different teams share a warehouse. The s3tables:namespace condition key scopes the wildcard resources to the sales namespace only.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "FullNamespaceAccess",
      "Effect": "Allow",
      "Action": [
        "s3tables:*"
      ],
      "Resource": [
        "arn:aws:s3tables:::bucket/analytics",
        "arn:aws:s3tables:::bucket/analytics/table/*",
        "arn:aws:s3tables:::bucket/analytics/view/*"
      ],
      "Condition": {
        "StringEquals": {
          "s3tables:namespace": "sales"
        }
      }
    }
  ]
}

Permissions granted:

• Full access to only the sales namespace.
• Create, read, update, and delete tables and views in the sales namespace.

Grant access to a single table identified by namespace and table name. This policy uses the s3tables:namespace and s3tables:tableName condition keys against the .../table/* resource, so it always targets the events table in the analytics namespace. If the table is renamed, this policy stops applying.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "TableAccessByName",
      "Effect": "Allow",
      "Action": [
        "s3tables:GetTable",
        "s3tables:GetTableData",
        "s3tables:PutTableData",
        "s3tables:UpdateTable"
      ],
      "Resource": "arn:aws:s3tables:::bucket/analytics/table/*",
      "Condition": {
        "StringEquals": {
          "s3tables:namespace": "analytics",
          "s3tables:tableName": "events"
        }
      }
    }
  ]
}

Grant access to a single table identified by its UUID. Because the UUID never changes, this policy keeps applying even if the table is renamed. Replace the example UUID with the value from mc table show ... --json.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "TableAccessByUUID",
      "Effect": "Allow",
      "Action": [
        "s3tables:GetTable",
        "s3tables:GetTableData",
        "s3tables:PutTableData",
        "s3tables:UpdateTable"
      ],
      "Resource": "arn:aws:s3tables:::bucket/analytics/table/a1b2c3d4-e5f6-7890-abcd-ef1234567890"
    }
  ]
}

Grant full administrative control over a warehouse and all of its tables and views with the s3tables:* wildcard action.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "WarehouseAdminAccess",
      "Effect": "Allow",
      "Action": "s3tables:*",
      "Resource": [
        "arn:aws:s3tables:::bucket/analytics",
        "arn:aws:s3tables:::bucket/analytics/table/*",
        "arn:aws:s3tables:::bucket/analytics/view/*"
      ]
    }
  ]
}

Deny any change to a warehouse or table encryption configuration that does not use SSE-S3 (AES256).

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "RequireSSES3",
      "Effect": "Deny",
      "Action": [
        "s3tables:PutWarehouseEncryption",
        "s3tables:PutTableEncryption"
      ],
      "Resource": "*",
      "Condition": {
        "StringNotEquals": {
          "s3tables:SSEAlgorithm": "AES256"
        }
      }
    }
  ]
}

This deny statement overrides any allow statement, so users can only set encryption when they specify AES256 as the algorithm.

This statement covers only the two encryption actions. A warehouse or table can also be given an encryption configuration when it is created, and s3tables:CreateWarehouse and s3tables:CreateTable accept the s3tables:SSEAlgorithm condition key as well.

Adding those two create actions to the deny closes that gap, but it also blocks creating a warehouse or table with no encryption configuration at all. MinIO AIStor sets the s3tables:SSEAlgorithm condition key only when the request specifies an algorithm, and StringNotEquals matches when the key is absent, so the deny fires on a plain create. Add the create actions only if every warehouse and table in the deployment is expected to declare AES256 explicitly at creation time.

You can tag warehouses and tables and then write policies that grant or deny access based on those tags. Tag-based access control lets you manage permissions by attribute (for example, environment or team) instead of by naming individual resources.

Manage tags with the mc table tag and mc table warehouse tag commands.

Reference tags in a policy Condition block using the variable-suffix condition keys:

• s3tables:WarehouseTag/<key> matches the value of a warehouse tag. It applies to most warehouse-level and table-level actions, because every table belongs to a warehouse.
• s3tables:TableTag/<key> matches the value of a table tag. It applies to table-level actions only.

Two actions do not accept s3tables:WarehouseTag/<key>, because neither one targets an existing warehouse whose tags could be read: s3tables:CreateWarehouse and s3tables:ListWarehouses. Including either action in a statement that carries a warehouse-tag condition causes MinIO AIStor to reject the policy. Grant those two actions in their own statement.

Replace <key> with the tag key you want to match, and provide the expected value with a standard string operator such as StringEquals or StringLike.

The following rules apply to warehouse and table tags:

• A resource can have at most 10 tags.
• A tag key must be between 1 and 128 characters.
• A tag value can be between 0 and 256 characters.
• Keys and values can contain letters, numbers, spaces, and the characters _ . : / = + @ -.
• Tag keys cannot start with the reserved prefixes aws:, minio:, or aistor:.

Grant read access to tables only in warehouses tagged env=production. Because s3tables:WarehouseTag/env applies to table actions, this restricts data access to production warehouses.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowProductionWarehouses",
      "Effect": "Allow",
      "Action": [
        "s3tables:GetTable",
        "s3tables:GetTableData",
        "s3tables:ListTables"
      ],
      "Resource": [
        "arn:aws:s3tables:::bucket/*",
        "arn:aws:s3tables:::bucket/*/table/*"
      ],
      "Condition": {
        "StringEquals": {
          "s3tables:WarehouseTag/env": "production"
        }
      }
    }
  ]
}

Grant read-write access to tables tagged team=analytics, regardless of which warehouse or namespace they belong to.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowAnalyticsTeamTables",
      "Effect": "Allow",
      "Action": [
        "s3tables:GetTable",
        "s3tables:GetTableData",
        "s3tables:PutTableData",
        "s3tables:UpdateTable"
      ],
      "Resource": "arn:aws:s3tables:::bucket/*/table/*",
      "Condition": {
        "StringEquals": {
          "s3tables:TableTag/team": "analytics"
        }
      }
    }
  ]
}

AIStor Tables data actions implicitly grant the corresponding S3 actions needed to read and write the underlying Iceberg data and metadata files. You do not need to grant these S3 actions manually for normal table data access.

These implicit grants apply only to paths within the table’s data directory. Standard S3 bucket permissions are still required to access objects outside of table data paths.

The grant also depends on the statement’s Resource list. MinIO AIStor evaluates an implicitly granted S3 action against the table’s ARN, so the statement must include a table-scoped ARN such as arn:aws:s3tables:::bucket/{warehouse}/table/*. A statement whose only resource is the bare warehouse ARN grants none of these S3 actions. See ARN patterns for the full set of ARNs a warehouse-wide policy needs.

The following sections show how to grant S3 API access for objects that fall outside table data paths. Because the data actions in the preceding table already cover normal table read, write, and delete, you only need these explicit s3: permissions when applications access objects outside the table’s data directory.

Grant S3 API access to objects in warehouse storage that are not covered by the implicit grants, such as objects outside table data paths. AIStor Tables stores both catalog metadata and table data in S3-compatible storage.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:PutObject",
        "s3:DeleteObject",
        "s3:ListBucket"
      ],
      "Resource": [
        "arn:aws:s3:::analytics/*",
        "arn:aws:s3:::analytics"
      ]
    }
  ]
}

Permissions granted:

• Read objects (data files, metadata files).
• Write new objects (data files, manifests).
• Delete objects (for table maintenance).
• List bucket contents.

Important considerations:

• This policy is distinct from AIStor Tables catalog permissions.
• Normal table read, write, and delete do not require these explicit s3: permissions, because the s3tables: data actions grant them implicitly within the table’s data directory. Grant these s3: permissions only for objects outside table data paths.
• The bucket name in the S3 ARN should match the warehouse name.
• Data file paths follow the pattern: s3://{warehouse}/{namespace}/{table}/data/.
• Metadata file paths follow: s3://{warehouse}/.aistor-tables/{namespace}/{table}/metadata/.

Applications that also need direct S3 access to objects outside table data paths can combine catalog permissions with explicit s3: permissions in a single policy. For normal table data access, the catalog s3tables: data actions already grant the required S3 actions implicitly, so a separate s3: statement is not needed.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "CatalogOperations",
      "Effect": "Allow",
      "Action": [
        "s3tables:GetWarehouse",
        "s3tables:ListNamespaces",
        "s3tables:GetNamespace",
        "s3tables:ListTables",
        "s3tables:GetTable",
        "s3tables:UpdateTable"
      ],
      "Resource": [
        "arn:aws:s3tables:::bucket/analytics",
        "arn:aws:s3tables:::bucket/analytics/table/*"
      ]
    },
    {
      "Sid": "DataPlaneAccess",
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:PutObject",
        "s3:ListBucket"
      ],
      "Resource": [
        "arn:aws:s3:::analytics/*",
        "arn:aws:s3:::analytics"
      ]
    }
  ]
}

This combined policy allows the following actions:

• Read table metadata and schemas from the catalog.
• Commit new snapshots after writes.
• Read and write data files in S3 storage.

Administering AIStor Table Sharing (Delta Sharing) uses the admin:DeltaSharing* admin actions to create and manage shares and tokens. These admin actions are separate from the s3tables: catalog actions and from the data-plane s3: actions that recipients need to read the underlying objects.

The following policy grants full AIStor Table Sharing administration and read access to every 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": [
        "arn:aws:s3:::*"
      ]
    },
    {
      "Sid": "DeltaSharingDataAccess",
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:ListBucket"
      ],
      "Resource": [
        "arn:aws:s3:::*"
      ]
    }
  ]
}

To restrict which buckets can be shared, narrow the Resource list on the s3: statement. The admin:DeltaSharing* actions are not bucket-scoped: MinIO AIStor ignores the Resource field on the admin statement, so narrowing it there restricts nothing. What limits the shareable buckets is the administrator’s read access to the underlying objects.

{
  "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": [
        "arn:aws:s3:::*"
      ]
    },
    {
      "Sid": "DeltaSharingDataAccess",
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:ListBucket"
      ],
      "Resource": [
        "arn:aws:s3:::hr-data",
        "arn:aws:s3:::hr-data/*"
      ]
    }
  ]
}

For more information about configuring sharing, see Controlling access to shared tables.

UUID-based table and view ARNs (arn:aws:s3tables:::bucket/{warehouse}/table/{uuid}) require the table’s UUID. The UUID is assigned when the table is created and remains stable across renames, which is what makes UUID-based ARNs durable.

There is no mc table info command for this; info is an alias of mc table show. Run mc table show with the --json global flag and read the table_uuid field from the output:

mc table show myaistor analytics prod sales_data --json

The JSON output includes a table_uuid field with the value you need:

{
  "status": "success",
  "table": "sales_data",
  "namespace": "prod",
  "warehouse": "analytics",
  "location": "s3://analytics/...",
  "format_version": 2,
  "table_uuid": "a1b2c3d4-e5f6-7890-abcd-ef1234567890"
}

In the default (non-JSON) output, the same value appears on the Table UUID: line.

Plug the value into a /table/{uuid} ARN to scope a policy to that specific table:

arn:aws:s3tables:::bucket/analytics/table/a1b2c3d4-e5f6-7890-abcd-ef1234567890

For a view, use the corresponding /view/{uuid} ARN.