Restrict Athena access via Specific IPs or CIDR range
Athena currently does not support IP based white-listing, as internally Athena might use different (Internal Athena service) IP address other than your source machine IP from which the API(StartQueryExecution) is submitted.
I had tried By using aws:SourceIp global condition key in the condition element of an IAM policy to restrict API calls from specific IP addresses conditional block. Although I had the required permission IAM (Athena, Glue, etc) and resource (S3, KMS, etc) based permissions but still kept getting the Permisison Denied Error.
Upon checking cloud trail logs for the StartQueryExecution API, it does indicate that the API originated from an IP which is in the allowed IP range and wonder why they still run into the issue.
This is because internally Athena might use different IP address other than the source machine IP from which the API(StartQueryExecution) is submitted and Athena hence it does not support IP based white-listing.
Work Around Solution:
The workaround i sto create a role that has the old permission without the Condition key. Now we will assume this role and in assume role we can provide the SourceIp Condition key to limit the user/roles that shall be able to assume the role based on their IP.
Please see below for detailed steps.
- Create a role say, “athena_ip_role” and attach policies having the appropriate permissions to query Athena [1]. For example, you can use the same policies as that your IAM user initially configured “original_IAMuser” but remove IP based condition statements in the policies.
- Edit the Trust relationship in the role and modify the Principal to allow the IAM user to assume this role [2]. Please note that here you need to “Allow" instead on “Deny" and use “IpAddress” instead of “NotIpAddress”.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::865xxxxx0544:user/original_IAMuser"
},
"Action": "sts:AssumeRole",
"Condition": {
"IpAddress": {
"aws:SourceIp": "X.X.X.X/yy"
}
}
}
] }- Create a new policy that needs to be used by the user to assume a role. For example, create “assume_role_policy_athena” and allow access to “sts:AssumeRole” for the role’s ARN.
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "VisualEditor0",
"Effect": "Allow",
"Action": "sts:AssumeRole",
"Resource": "arn:aws:iam::865xxxxx0544:role/athena_ip_role "
}
] }- Attach this “assume_role_policy_athena” to the desired user, for example “original_IAMuser”. You may now remove any other policies/permissions attached to this user
Then switch to the given role while logged in as the user [3].
Run the query as the new role
You may also create an IAM group instead of IAM User and manage multiple user permissions via the IAM group.
Related links: