AWS Glue Native Authentication

Every call Qualytics makes for an AWS Glue Native datastore carries one AWS identity: the Glue calls that read table definitions, and the Amazon S3 requests that read the data files. The Type selector in the connection form decides where that identity comes from. There are two options, Access Key and Assumed Role.

One identity for the catalog and the data

The same identity reads the Glue Data Catalog and the S3 objects behind it. There is no separate field for storage credentials, and no second role for the data. This means the identity needs both kinds of access: a role that can read table definitions in Glue but not the S3 objects passes the connection test and lists every table, then fails as soon as Qualytics needs to read the files. See AWS Glue Native Permissions for the full list.

Access Key

With Access Key authentication, you create an IAM user in your AWS account and give Qualytics its Access Key ID and Secret Access Key. Every Glue and S3 call uses those credentials.

This is the simplest setup. It works well when:

• You are trying the connector out, or connecting a development account.
• Your security policy allows storing static AWS credentials.

The trade-off is that the credentials are static. When you change them in AWS, update the connection in Qualytics as well.

Assumed Role

With Assumed Role authentication, you do not share any static credentials with Qualytics. You create an IAM role in your AWS account and let Qualytics assume it. Qualytics asks AWS STS for temporary credentials for that role and uses them for both Glue and S3, requesting fresh credentials automatically before the current ones expire, so a long-running scan is not interrupted.

This is the recommended option for production. It works well when:

• Your security policy disallows storing static AWS credentials.
• Your data lives in a different AWS account from Qualytics.
• You want every session to be auditable in AWS CloudTrail.

How the assume-role flow works

1. Qualytics's AWS identity (the AWS identity used by your Qualytics deployment) calls sts:AssumeRole on the Role ARN you entered in the connection form.
2. AWS checks the role's trust policy to confirm that the calling identity is allowed to assume the role. If you supplied an External ID, AWS also checks that it matches the one in the trust policy.
3. If the checks pass, AWS returns temporary credentials for the role.
4. Qualytics uses those credentials to call Glue and read from Amazon S3, with the permissions attached to the role.

The base role (the AWS identity used by Qualytics that calls sts:AssumeRole) and the target role (the role you enter in the connection form) are described in detail in IAM Role Authentication, including who provisions each one for managed and self-hosted deployments.

About the External ID

The External ID is an extra check on top of the trust policy. When your role's trust policy requires an External ID, only AssumeRole calls that pass the matching value succeed. In Qualytics it is optional: supply it only if your trust policy requires one. AWS recommends an External ID whenever a third party is allowed to assume a role in your account.

What each field does

How the credentials are stored

The Access Key ID and Secret Access Key are stored encrypted. The Secret Key is never displayed back to you.

• To change the Secret Key, enter the new value.
• To keep the stored Secret Key while editing anything else on the connection, leave the field empty and save.
• Switching an existing connection from Access Key to Assumed Role discards the stored key pair, so the role is the only identity the connection uses from then on.

See Also