AWS IAM:如何使用条件上下文键"aws:RequestTag"工作? [英] AWS IAM: How does the condition context key "aws:RequestTag" work?

查看:109
本文介绍了AWS IAM:如何使用条件上下文键"aws:RequestTag"工作?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我有一个附加了角色的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屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆