AWS IAM:如何使用条件上下文键"aws:RequestTag"工作? [英] AWS IAM: How does the condition context key "aws:RequestTag" work?
问题描述
我有一个附加了角色的EC2实例.我的目标是提供对AWS服务(例如Lambda)的完全访问权限,但仅对某些资源(基于标签)提供访问权限.我发现 aws:RequestTag
是做到这一点的方法.
I have an EC2 instance with a role attached to it. My goal is to provide full access to AWS service (Lambda for example) but only on certain resources (Tag based). I found that aws:RequestTag
was the way to do it.
以下是该角色附带的IAM策略.
Below is the IAM policy attached to the role.
"Version": "2012-10-17",
"Statement": [
{
"Sid": "Stmt1614664562621",
"Action": "lambda:*",
"Effect": "Allow",
"Resource": "*",
"Condition": {
"StringLike": {
"aws:ResourceTag/app": "prod"
}
}
}
]
}
我在必需的lambda函数上添加了标签 app:prod
,但是当我尝试列出该lambda时,出现了 AccessDeniedException
错误.下面是错误消息
I added the tags app:prod
on the required lambda functions but however when I try to list the lambda I get an AccessDeniedException
error. Below is the error message
调用时发生错误(AccessDeniedException)ListFunctions操作:用户:arn:aws:sts :: 123456789:assumed-role/iam-role-name/i-01abcd456abcd是未经授权执行:资源上的lambda:ListFunctions:*
An error occurred (AccessDeniedException) when calling the ListFunctions operation: User: arn:aws:sts::123456789:assumed-role/iam-role-name/i-01abcd456abcd is not authorized to perform: lambda:ListFunctions on resource: *
如何使 aws:RequestTag
工作?我要去哪里错了?
How to make the aws:RequestTag
work? Where am I going wrong?
以下类似问题:(该解决方案对我不起作用) s3存储桶上的aws:RequestTag不起作用(扮演角色)
Similar question below: (That solution didn't work for me) aws:RequestTag on s3 bucket is not working (while assuming a role)
推荐答案
您可能希望根据情况使用 aws:ResourceTag
并标记此策略应允许的资源(即Lambda函数)访问.
You probably want to use aws:ResourceTag
instead in your condition and tag the resources (i.e. Lambda functions) that this policy should permit access to.
aws:RequestTag
用于控制AWS API调用中可以包含哪些 标签,例如用于在资源上添加/编辑/删除资源标签或添加会话上的会话标签(通过 sts:TagSession
调用).它们并不是要保护对具有 特定标签的资源的访问.
aws:RequestTag
is used to control which tags can be carried in an AWS API call such as for adding/editing/removing a resource tag on a resource or adding session tags on a session (via an sts:TagSession
call). They are not meant to protect access to resources having a specific tag.
此外,在您的角色上添加标签并不意味着任何呼叫者身份(即假定的会话角色)都将具有此标签作为请求/会话标签.因此,它将不会控制具有该标签的资源的任何授权/访问.您简单标记的IAM角色是另一个 AWS资源,现在已对其应用资源标签.
Also, adding the tag on your role does not mean that any caller identity (i.e. assumed session role) will then have this tag as a request/session tag. And consequently, it will not control any authorization/access to resources with that tag. The IAM role that you tagged simply is another AWS resource with a resource tag applied to it now.
此外,当EC2在EC2实例中扮演角色时,您甚至无法控制会话标签,因此您无法控制EC2实例的会话/请求标签.
Additionally, you couldn't even control session tags when EC2 assumes your role in the EC2 instance, so you cannot control session/request tags for your EC2 instance.
在您的带有 lambda:ListFunctions
的特定示例中,虽然这不是特定于资源的操作,但是您不能通过具有以下功能的Lambda函数来控制/过滤列表:API调用者的策略允许的特定资源标签.
In your particular example with lambda:ListFunctions
, though, which is not a resource-specific action, you cannot control/filter the list by Lambda functions having a specific resource tag allowed by the policy of the API caller.
使用多个环境/阶段时,实际上最好是拥有多个AWS帐户(每个环境/阶段一个).如果您尚未使用多个AWS帐户,则甚至可以使用 AWS Organizations 进行合并计费,等等.
When working with multiple environments/stages, having multiple AWS accounts (one per environment/stage) is actually best practice. You can then even use AWS Organizations for consolidated billing, etc. if you don't already use multiple AWS accounts.
这篇关于AWS IAM:如何使用条件上下文键"aws:RequestTag"工作?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!