IAM policies reference

Aurora PostgreSQL requires IAM permissions to access your Iceberg and Parquet data in Amazon S3 and, optionally, AWS Glue Data Catalog or Amazon S3 Tables. The specific permissions depend on your data format and how the data is registered. This section presents examples of typical IAM policies for Aurora PostgreSQL.

Summary of required permissions

The following table summarizes the permissions that Aurora PostgreSQL requires for each access path. Grant only the row that matches your configuration.

Three points affect how much you need to grant:

Example policies

These example policies use amzn-s3-demo-bucket as the bucket name, amzn-s3-demo-table-bucket as the Amazon S3 Tables table bucket name, and 123456789012 as the AWS account ID. To use these policies, replace the user input placeholders with your own information, and scope each Resource element to only the data that your foreign tables reference.

Example: Parquet files in Amazon S3

The following example policy grants permission to read Parquet files directly from an Amazon S3 bucket. AWS Glue Data Catalog isn't required for Parquet.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "S3ListBucket",
            "Effect": "Allow",
            "Action": "s3:ListBucket",
            "Resource": "arn:aws:s3:::amzn-s3-demo-bucket",
            "Condition": {
                "StringLike": {
                    "s3:prefix": [
                        "data/orders",
                        "data/orders/*",
                        "data/customers",
                        "data/customers/*"
                    ]
                }
            }
        },
        {
            "Sid": "S3ReadObjects",
            "Effect": "Allow",
            "Action": "s3:GetObject",
            "Resource": [
                "arn:aws:s3:::amzn-s3-demo-bucket/data/orders/*",
                "arn:aws:s3:::amzn-s3-demo-bucket/data/customers/*"
            ]
        }
    ]
}

This policy consists of two Allow statements:

Example: Iceberg tables through AWS Glue Data Catalog and Amazon S3

The following example policy grants permission to query Iceberg tables that are registered in AWS Glue Data Catalog.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "GlueCatalogAccess",
            "Effect": "Allow",
            "Action": "glue:GetTable",
            "Resource": [
                "arn:aws:glue:us-east-1:123456789012:catalog",
                "arn:aws:glue:us-east-1:123456789012:database/analytics_db",
                "arn:aws:glue:us-east-1:123456789012:table/analytics_db/orders",
                "arn:aws:glue:us-east-1:123456789012:table/analytics_db/customers"
            ]
        },
        {
            "Sid": "S3ReadObjects",
            "Effect": "Allow",
            "Action": "s3:GetObject",
            "Resource": [
                "arn:aws:s3:::amzn-s3-demo-bucket/data/iceberg/orders/*",
                "arn:aws:s3:::amzn-s3-demo-bucket/data/iceberg/customers/*"
            ]
        }
    ]
}

This policy consists of two Allow statements:

This policy doesn't grant s3:ListBucket, which Iceberg tables don't require. If the AWS Glue table is a crawler-registered Parquet table rather than an Iceberg table, add the S3ListBucket statement that is shown in the preceding Parquet example.

Example: Iceberg tables in Amazon S3 Tables

Amazon S3 Tables supports two access paths, and each requires a different set of permissions. Use the example that matches your foreign table definition.

Access through AWS Glue Data Catalog

The following example policy grants permission to query an Amazon S3 Tables table through an AWS Glue ARN under the s3tablescatalog federated catalog, such as arn:aws:glue:us-east-1:123456789012:table/s3tablescatalog/amzn-s3-demo-table-bucket/my_namespace/orders.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "GlueCatalogAccess",
            "Effect": "Allow",
            "Action": "glue:GetTable",
            "Resource": [
                "arn:aws:glue:us-east-1:123456789012:catalog/s3tablescatalog/amzn-s3-demo-table-bucket",
                "arn:aws:glue:us-east-1:123456789012:database/s3tablescatalog/amzn-s3-demo-table-bucket/my_namespace",
                "arn:aws:glue:us-east-1:123456789012:table/s3tablescatalog/amzn-s3-demo-table-bucket/my_namespace/orders"
            ]
        },
        {
            "Sid": "S3TablesAccess",
            "Effect": "Allow",
            "Action": [
                "s3tables:GetTable",
                "s3tables:GetTableBucket",
                "s3tables:GetTableData",
                "s3tables:GetNamespace"
            ],
            "Resource": [
                "arn:aws:s3tables:us-east-1:123456789012:bucket/amzn-s3-demo-table-bucket",
                "arn:aws:s3tables:us-east-1:123456789012:bucket/amzn-s3-demo-table-bucket/table/*"
            ]
        }
    ]
}

Access by table ARN

The following example policy grants permission to query an Amazon S3 Tables table by its table ARN, such as arn:aws:s3tables:us-east-1:123456789012:bucket/amzn-s3-demo-table-bucket/table/1234abcd-12ab-34cd-56ef-1234567890ab. This access path doesn't involve AWS Glue, and no AWS Glue permissions are required.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "S3TablesAccess",
            "Effect": "Allow",
            "Action": [
                "s3tables:GetTable",
                "s3tables:GetTableBucket",
                "s3tables:GetTableData",
                "s3tables:GetNamespace"
            ],
            "Resource": [
                "arn:aws:s3tables:us-east-1:123456789012:bucket/amzn-s3-demo-table-bucket",
                "arn:aws:s3tables:us-east-1:123456789012:bucket/amzn-s3-demo-table-bucket/table/*"
            ]
        }
    ]
}

The statements in the preceding examples grant the following permissions:

When you access the table through AWS Glue Data Catalog, AWS Glue resolves the table bucket and the namespace on your behalf as part of resolving the federated catalog.

Standard Amazon S3 permissions such as s3:GetObject and s3:ListBucket aren't required for either access path.

For cross-account access, you can grant s3tables:GetTableBucket and s3tables:GetNamespace in the table bucket policy in the data owner's account instead of in your IAM policy. In that configuration, your IAM policy requires only s3tables:GetTable and s3tables:GetTableData.

Server-side encryption with AWS KMS

If your data is encrypted with server-side encryption using AWS KMS keys (SSE-KMS), add a statement like the following to the policy for your access path. Data that is encrypted with SSE-S3 doesn't require additional permissions.

{
    "Sid": "KMSDecrypt",
    "Effect": "Allow",
    "Action": "kms:Decrypt",
    "Resource": "arn:aws:kms:us-east-1:123456789012:key/1234abcd-12ab-34cd-56ef-1234567890ab"
}

For a KMS key that is owned by another account, the key policy in the owning account must grant kms:Decrypt to your role and your role's IAM policy must allow kms:Decrypt on that key. Neither policy alone is sufficient.

Cross-account access

When another account owns your data, both accounts must allow the action. In the following examples, a cluster role in account 123456789012 reads Parquet files from a bucket that is owned by account 111122223333.

The following example bucket policy, in the data owner's account, grants the cluster role permission to read objects from the bucket.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "AllowAuroraAnalyticsRole",
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::123456789012:role/amzn-analytics-demo-role"
            },
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3:::amzn-s3-demo-bucket/data/orders/*"
        }
    ]
}

The following example identity-based policy, attached to the cluster role in your account, grants the same permission on the same resource.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "S3ReadCrossAccount",
            "Effect": "Allow",
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3:::amzn-s3-demo-bucket/data/orders/*"
        }
    ]
}

If either policy omits the action, the request is denied. Cross-account denials from Amazon S3 don't identify which side is missing the permission, so check both policies.

The same requirement applies to AWS Glue resources and AWS KMS keys that are owned by another account. If your foreign table location names a folder rather than an exact object key, add s3:ListBucket on the bucket ARN to both policies.

IAM role trust policy

Whichever permissions policy you use, attach it to an IAM role whose trust policy allows Amazon RDS to assume the role on behalf of your Aurora DB cluster, as in the following example. The aws:SourceAccount and aws:SourceArn condition keys restrict the role so that it can be assumed only on behalf of your own cluster.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "Service": "rds.amazonaws.com"
            },
            "Action": "sts:AssumeRole",
            "Condition": {
                "StringEquals": {
                    "aws:SourceAccount": "123456789012"
                },
                "ArnLike": {
                    "aws:SourceArn": "arn:aws:rds:us-east-1:123456789012:cluster:amzn-rds-demo-cluster"
                }
            }
        }
    ]
}

Best practices for IAM policies

When you create these IAM policies, follow these best practices: