AWS Glue Native Permissions

Two separate things have to be granted before someone can put an AWS Glue Native datastore to work, and they are granted in different places:

• In your AWS account, the identity Qualytics connects with needs read access to the Glue Data Catalog and to the S3 objects behind each table. Without it the connection cannot read your data at all.
• In Qualytics, the person doing the work needs a user role and a team permission. Without them the datastore exists but they cannot create, change, or run operations on it.

The rest of this page covers both, in that order.

Access on your AWS Account

Because AWS Glue Native reads the data files themselves, it needs more than access to the catalog. Glue access alone is enough to list databases and tables, so a datastore set up that way passes the connection test and then fails as soon as Qualytics needs to read the files. Grant the S3 access below before the first operation, not after.

Qualytics never writes to Glue or to Amazon S3 through this connector, so read access is all it asks for.

Which identity needs the permissions

Glue permissions

Glue checks each call against the resource and every level above it, so a table read needs the catalog, the database, and the table to be allowed. To scope the policy, grant the catalog ARN, the database ARN, and the tables in that database, for example arn:aws:glue:us-east-1:123456789012:catalog, arn:aws:glue:us-east-1:123456789012:database/sales, and arn:aws:glue:us-east-1:123456789012:table/sales/*.

Amazon S3 permissions

Grant them on every bucket and prefix your tables point to. Table locations in one database can span several buckets, and a partition can be registered at a location outside its table's own path. Qualytics reads both, so both need to be covered.

Example IAM policy

Replace the region, account ID, database, and bucket placeholders with your own values. The policy covers one database: repeat the two database lines for each additional database you monitor. Only the databases the policy covers appear in the Database dropdown.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "GlueCatalogReadOnly",
      "Effect": "Allow",
      "Action": [
        "glue:GetDatabases",
        "glue:GetDatabase",
        "glue:GetTables",
        "glue:GetTable",
        "glue:GetPartitions"
      ],
      "Resource": [
        "arn:aws:glue:<region>:<account-id>:catalog",
        "arn:aws:glue:<region>:<account-id>:database/<database>",
        "arn:aws:glue:<region>:<account-id>:table/<database>/*"
      ]
    },
    {
      "Sid": "S3ListTableLocations",
      "Effect": "Allow",
      "Action": "s3:ListBucket",
      "Resource": "arn:aws:s3:::<YOUR_BUCKET>"
    },
    {
      "Sid": "S3ReadTableFiles",
      "Effect": "Allow",
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::<YOUR_BUCKET>/*"
    }
  ]
}

Cross-account catalogs

When Catalog ID names another AWS account, both accounts take part:

• The account that owns the catalog grants your identity access through the Glue Data Catalog resource policy, and grants read access to its S3 buckets through their bucket policies.
• Your account grants the same Glue and S3 actions in the identity's IAM policy, using the owning account's ID in the Glue ARNs.

A call succeeds only when both sides allow it.

Lake Formation

Qualytics reads with the identity's own IAM permissions. It does not request temporary credentials from AWS Lake Formation, and it does not apply Lake Formation row, column, or cell filters.

• Catalogs that use IAM access control only (the default for Glue, where Lake Formation grants the IAMAllowedPrincipals group access) work with the permissions above and nothing more.
• Tables governed by Lake Formation permissions also need Lake Formation to let the identity see them in the catalog, and the identity still needs the direct S3 permissions above, because Qualytics reads the files with its own credentials.

Permissions in Qualytics

Qualytics checks two layers, and an action is allowed only when both pass.

• User roles are workspace-wide: Member, Manager, and Admin.
• Team permissions are granted per datastore through the teams a user belongs to: Reporter, Viewer, Drafter, Author, and Editor.

For the full reference, see User Roles and the Team Permissions Overview.

User Roles

Team Permissions

Checked on the datastore itself, in addition to the user role above.

How the two layers meet

To create an AWS Glue Native datastore, a user needs the Manager role. Team permissions are not consulted, because the datastore does not exist yet.

To edit it, run an operation on it, or link an enrichment destination, a user needs the Member role or higher and the Editor team permission on that datastore, through at least one of the teams the datastore belongs to.

To delete it, or to unlink its enrichment destination, a user needs the Admin role. No team permission is consulted.

See Also