- Mais recentes
- Mais votos
- Mais comentários
I have to point out there is nothing wrong with your original policy.
The reason why you need both 1 and 2 is that if you are missing either, the effect of the policy might be to explicitly deny access to either the role or the assumed user role.
You can find more details in the NotPrincipal documentation.
ah, that makes sense. it was working but the fact #2 does not accept wildcard makes it not really useful as arn of EC2 will change over time. It was given in the doc that NotPrincipal is not accepting wildcards. That is why I was looking for another solution.
Take a look at the aws:PrincipalArn or aws:userId condition keys.
Your policy with PrincipalArn would look something like this:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Action": "secretsmanager:GetSecretValue",
"Principal": {
"AWS": "*"
},
"Resource": "*",
"Condition": {
"ArnNotEquals": {
"aws:PrincipalArn": "arn:aws:iam::123456789:role/example-role"
}
}
}
]
}
With aws:userId, you would have something like this:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Action": "secretsmanager:GetSecretValue",
"Principal": {
"AWS": "*"
},
"Resource": "*",
"Condition": {
"StringNotLike": {
"aws:userId": "AROAABCDEFGHIJ:*" # this would be the role's unique ID
}
}
}
]
}
Both of these policies avoid having to specify the assumed role principal. The difference is that aws:PrincipalArn ties the policy to the name of the role and aws:userid ties the policy to the unique identifier of the role. This means that if you were to delete and recreate the role, the PrincipalArn policy would continue to work as desired. The aws:userid policy would stop working if a role was recreated with the same name, but had a different unique ID.
The tradeoff is that if you delete the role and do not recreate it, someone else in the account could create a role with the same name and the aws:PrincipalArn policy would not deny that role.
See this post on aws:userid for more information about getting the unique ID for a role.
Question 1: I suspect the EC2 is accessing the secret in two different ways. Normally you would only need one but I guess the application on EC2 uses two ways of authenticating.
The first way is direct. The EC2 has a default role associated. This would use #1
If a different default role is associated with the EC2 the application needs to use an API call to STS to assume the role (instead of its default one). Thats where #2 is needed.
Question 2: Instead of a Deny you can change the policy to use Allow instead:
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "secretsmanager:GetSecretValue", "Principal": { "AWS": [ "arn:aws:iam::123456789:root", "arn:aws:iam::123456789:role/example-role", "arn:aws:sts::123456789:assumed-role/example-role/*" ] }, "Resource": "*" } ] }
It can't be changed to
Allow
because we want to have explicit deny on the resource policy level. With this, you can achieve explicit deny for everybody except mentioned roles but to use this Parameter, you still need to Allow it in your policy, so it is not magically assigned by resource policy.
thanks, that in deed did the job. I tried with StringNotEquals rather than ArnNotEquals what somehow did nor work out for me...but now I am good :-)
Conteúdo relevante
- AWS OFICIALAtualizada há 3 meses
- AWS OFICIALAtualizada há 2 anos
- AWS OFICIALAtualizada há 2 meses
Are you trying to implement access to a secret in ONE account from an EC2 instance in ANOTHER account?