I have the following statement in my IAM policy:
{
"Sid" : "AllowDetachingAWSManagedPolicies",
"Effect" : "Allow",
"Action" : [
"organizations:DetachPolicy"
],
"Resource" : "*",
"Condition" : {
"StringEquals" : {
"organizations:PolicyType" : "SERVICE_CONTROL_POLICY"
}
}
}
However, when I try to detach the FullAWSAccess policy from an AWS Organizations account, I get AccessDenied, as if my IAM policy wasn't sufficient. I have made sure that there is another SCP in addition to FullAWSAccess, so the issue is not that there would remain no SCPs attached to the account.
What is going wrong?
Strangely enough, the AWS-managed FullAWSAccess policy does not count as a SERVICE_CONTROL_POLICY even though it is listed as such on the AWS Organizations Policies page.
When I removed the condition, I no longer got AccessDenied errors:
{
"Sid" : "AllowDetachingAWSManagedPolicies",
"Effect" : "Allow",
"Action" : [
"organizations:DetachPolicy"
],
"Resource" : "*"
}
Another thing I tried to do was to specify a resource that matched FullAWSAccess:
"Resource": "arn:aws:organizations::aws:policy/service_control_policy/p-*"
But that similarly resulted in an AccessDenied error. So I left it as:
"Resource": "*"
Related
I want all roles of my AWS account having a specific pattern to be able to access a Secrets Manager secret. I know I can use Condition block and wildcard matching for that.
However, the Principal field is required in a resource policy.
Will the following policy restrict access to just the roles matching the pattern?
{
"Statement": [
{
"Action": [
"secretsmanager:UpdateSecret",
"secretsmanager:GetSecretValue"
],
"Condition": {
"StringLike": {
"aws:PrincipalArn": "arn:aws:iam::12345678910:role/my_role_*"
}
},
"Principal": { "AWS": "arn:aws:iam::12345678910:root" },
"Effect": "Allow",
"Resource": "arn:aws:secretsmanager:us-east-1:12345678910:secret:some-secret-1234",
"Sid": "rp1"
}
],
"Version": "2012-10-17"
}
Use the wildcard "All Principal": {"AWS": "*"}. The combination of a same-account Account Principal + wildcard condition works in role *trust* policies1 but apparently not in *resource* policies2.
The IAM docs say:
You can specify the role principal as the principal in a resource-based policy or create a broad-permission policy [with a wildcard Principal] that uses the aws:PrincipalArn condition key.
Because the condition contains the account number, the All Principal is no more permissive than the Account Principal would be. Also, because the policy is always tied to a specific secret resource, the wildcard "*" Resoure is no more permissive than the secret name. Finally, while an ArnLike condition is not always equivalent to StringLike, it is identical in this case.
{
"Version" : "2012-10-17",
"Statement" : [ {
"Effect" : "Allow",
"Principal" : { "AWS" : "*" },
"Action" : [ "secretsmanager:DescribeSecret", "secretsmanager:GetSecretValue" ],
"Resource" : "arn:aws:secretsmanager:us-east-1:12345678910:secret:some-secret-1234",
"Condition" : {
"ArnLike" : {
"aws:PrincipalArn" : "arn:aws:iam::12345678910:role/my_role_*"
}
}
} ]
}
See the wildcard permissions section of the AWS blog post How to use trust policies with IAM roles for a trust policy example.
Error using a Lambda role + secrets manager resource policy with a same-account Account Principal: ...no identity-based policy allows the secretsmanager:GetSecretValue action.
I created a secret in AWS Secrets Manager. I want one IAM user and a federated user to be able to list, describe and retrieve the secret. I defined the following policy:
{
"Version" : "2012-10-17",
"Statement" : [ {
"Effect" : "Allow",
"Principal" : {
"AWS" : [
"arn:aws:iam::123456789:user/IAMUser1",
"arn:aws:iam::123456789:role/UAT-Developer/dev_user1#mycompany.com"
]
},
"Action" : [ "secretsmanager:GetSecretValue", "secretsmanager:DescribeSecret", "secretsmanager:ListSecretVersionIds", "secretsmanager:ListSecrets" ],
"Resource" : "*"
} ]
}
but it is throwing This resource policy contains an unsupported principal.
I also tried the below syntax for Principal but did not work.
"Principal" : {
"AWS" : "arn:aws:iam::123456789:user/IAMUser1",
"AWS" : "arn:aws:iam::123456789:role/UAT-Developer/dev_user1#mycompany.com"
}
Please help me get this correct.
I got it. We have to put assumed-role instead of just role.
arn:aws:iam::123456789:assumed-role/UAT-Developer/dev_user1#mycompany.com
I want to make my IAM policy conditional, to allow it to work with an EC2 instance that has definite assumed role. The following syntax works great if I know the id of that instance, sasying it's i-1111111111111111:
{
"Version" : "2012-10-17",
"Statement" : [ {
"Effect" : "Allow",
"Principal" : {
"AWS": "arn:aws:sts::111122223333:assumed-role/MyRole/i-1111111111111111"
},
"Action" : "secretsmanager:GetSecretValue",
"Resource" : "*"
} ]
}
However I want to allow this access for any future EC2 instance with the same role. As wildcards do not work in Principal field, I try to specify a wildcarded condition:
"Principal" : "*",
"Condition": {
"StringLike": {
"aws:PrincipalArn": "arn:aws:sts::111122223333:assumed-role/MyRole/*"
}
},
but this does not grant access.
What the correct syntax should be for wildcarded principal?
Note: I have reviewed other questions and believe this is unique because it specifically pertains to cross-account secrets access using a glue job.
I am having an issue where a glue job, assuming a service role in one account, is unable to access a secret stored in another account, despite my policies which I believe should allow it to do so.
Error I'm seeing (with redacted values): An error occurred (AccessDeniedException) when calling the GetSecretValue operation: Access to KMS is not allowed. This version of secret is not encrypted with the current KMS key.
Question
What about the below setup is causing the permission failure?
Diagram of Current Situation
My Understanding of What Needs to be Done
Based on the AWS docs and a 2018 blog post, I think what we have to do is:
Add a Policy on the secret to allow access to service role
Add a Policy on the CMK to allow service role to decrypt
Add a Policy on Service role to allow access to secret
Add a Policy on Service role to allow CMK decryption
Current Policies
Policy on Secret
{
"Version" : "2012-10-17",
"Statement" : [ {
"Effect" : "Allow",
"Principal" : {
"AWS" : "arn:aws:iam::GLUE_ACCOUNT:role/GLUE_SERVICE_ROLE"
},
"Action" : "secretsmanager:GetSecretValue",
"Resource" : "*",
"Condition" : {
"ForAnyValue:StringEquals" : {
"secretsmanager:VersionStage" : "AWSCURRENT"
}
}
} ]
}
Policy on CMK
Note that the redacted SECRET_NAME below contains the few characters that AWS appends in the ARN, which it seems we need to include.
{
"Sid": "AllowUseOfTheKey",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::GLUE_ACCOUNT:role/GLUE_SERVICE_ROLE"
},
"Action": ["kms:Decrypt","kms:DescribeKey"],
"Resource": "*",
"Condition": {
"StringEquals": {
"kms:ViaService": "secretsmanager.us-east-1.amazonaws.com"
},
"StringLike": {
"kms:EncryptionContext:SecretARN": "arn:aws:secretsmanager:us-east-1:SECRET_ACCOUNT:secret:SECRET_NAME"
}
}
}
Policy Statements Attached to Glue Service Role in Glue Account
{
"Sid": "AllowGetSecretValue",
"Effect": "Allow",
"Action": [
"secretsmanager:GetSecretValue"
],
"Resource": [
"arn:aws:secretsmanager:us-east-1:SECRET_ACCOUNT:secret:SECRET_NAME"
]
},
{
"Sid": "AllowKMSDecrypt",
"Effect": "Allow",
"Action": [
"kms:Decrypt"
],
"Resource": [
"arn:aws:kms:us-east-1:SECRET_ACCOUNT:key/CMK_KEY_ID"
]
},
Trust policy on the service role
Just to confirm that the glue job does indeed seem to have the authority to assume the service role:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "glue.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
Possible Next Steps
As thought experiments, I'm considering doing the below just to see if it works:
Removing the condition in the secret policy
Removing the conditions in the CMK policy
Adding kms:DescribeKey to the Service Account policy as well, though I don't think that's going to resolve things.
As sometimes happens with these involved questions, the piece of information to answer the question was found outside of the information I'd provided, despite my best efforts.
The solution was two-fold:
The authorization error that was part of the original question wasn't due to authentication access at all. It was because the code that used boto3 specified the name of the secret instead of the full ARN. Of course secrets manager wouldn't magically know that secret was in a different account.
A surprising thing in this case is that AWS threw an unauthorized exception, and not a not found exception, which would have been infinitely more useful to our efforts.
Once that was fixed, we saw the error that is currently in the ticket, around encrypting the CMK. Apparently when we changed the CMK, we did not select to automatically create a new version of the secret with that CMK. A simple edit and save of the secret by an authorized user was enough to re-encrypt it with the chosen CMK and resolve the issue.
I need to create a policy that grants full access on some services (ex: lambda, s3, apigateway) based on their tags. The way I think of it is: Only give full access to this resource if it has certain tags (ex: projectName= SpaceX). On the other hand, if a resource doesn't have the desired tags, deny any requests.
See https://docs.aws.amazon.com/IAM/latest/UserGuide/access_tags.html
{
"Version" : "2012-10-17",
"Statement" : [
{
"Effect" : "Allow",
"Action" : "s3:*",
"Resource" : "*",
"Condition" : {
"StringEquals" : {
"aws:ResourceTag/env" : "prod"
}
}
}
]
}
This will allow any operation on S3 tagged as env: prod