We’re running compliance analytics queries in Athena against our Glue Data Catalog, but suddenly all queries are failing with AccessDeniedException. The error specifically mentions ‘User is not authorized to perform glue:GetTable on resource’. Our IAM policy was working fine until we added new compliance tables last week.
The Athena-Glue integration was set up months ago for our compliance reporting automation, and we haven’t changed the IAM policies. The queries are part of our automated monthly compliance reports that pull data from multiple sources. We’re blocked from generating critical reports due tomorrow.
Error snippet:
AccessDeniedException: User: arn:aws:iam::123456:user/athena-service
is not authorized to perform: glue:GetTable
on resource: arn:aws:glue:us-east-1:123456:table/compliance_db/*
Has anyone dealt with Athena queries failing after adding new Glue tables? The existing tables still work, but new ones throw access denied errors.
I’ve seen this exact scenario multiple times with compliance analytics setups. Let me break down the complete solution addressing all three focus areas:
1. Athena-Glue Integration Issue:
Your IAM policy needs both Glue Data Catalog and KMS permissions. The AccessDeniedException occurs because Athena can’t decrypt the Glue table metadata when tables use KMS encryption.
2. IAM Policy Configuration Fix:
Update your IAM policy to include:
{
"Effect": "Allow",
"Action": ["glue:GetTable", "glue:GetPartitions"],
"Resource": "arn:aws:glue:us-east-1:123456:*"
},
{
"Effect": "Allow",
"Action": "kms:Decrypt",
"Resource": "arn:aws:kms:us-east-1:123456:key/*"
}
3. Compliance Reporting Automation:
For your automated compliance reports, ensure the Athena workgroup IAM role (not just the user) has these permissions. Also add glue:GetDatabase for database-level metadata access. If you’re using Lake Formation, verify that your tables are registered and the IAM principal has Lake Formation permissions as well - this is often overlooked in compliance setups.
Additional Recommendations:
- Use resource-based policies on your KMS keys to explicitly allow the Athena service role
- Enable CloudTrail logging for Glue and KMS API calls to track future permission issues
- Consider using AWS Lake Formation for centralized access control across your compliance data catalog
- Test your IAM changes in a non-production environment first
The root cause is that your new compliance tables use KMS encryption (SSE-KMS) while your IAM policy only covered basic Glue operations. The combination of encrypted table metadata and missing KMS decrypt permissions triggers the AccessDeniedException. After adding KMS permissions, your automated compliance reporting should work for all tables - both old SSE-S3 and new SSE-KMS encrypted ones.
Let me know if you need help with the Lake Formation setup or if you’re still seeing issues after updating the IAM policy.
Check if your new compliance tables have different resource ARNs or naming patterns. The IAM policy might be using specific table names instead of wildcards. Also verify the Glue Data Catalog permissions - sometimes table-level policies override database-level access.
The naming convention shouldn’t matter if you’re using database-level wildcards. However, I’ve seen this exact issue when Glue table metadata includes resource tags that trigger condition-based IAM policies. Check if your compliance tables have specific tags that require additional permissions. Also, verify that the Athena workgroup’s IAM role has the necessary Glue permissions, not just the user running the query. Sometimes the workgroup configuration overrides user permissions in compliance setups.
We had a similar problem with our compliance reporting automation. The issue was that our new tables were created with encryption settings that required additional KMS permissions. Even though the IAM policy had glue:GetTable, it didn’t have kms:Decrypt for the keys used by the new tables. Check if your new compliance tables use different encryption keys than the old ones.
Interesting - I just checked and the new tables do have SSE-KMS encryption enabled while the old ones use SSE-S3. That might explain why the existing tables work but new ones fail. So I need to add KMS decrypt permissions to the IAM policy?
Good point about the ARNs. I checked and the new tables are in the same database (compliance_db), but they have a different naming convention - we added a ‘v2_’ prefix. Could that be causing the wildcard match to fail? The IAM policy does use compliance_db/* so it should match everything in that database.