当前位置：文江博客话题详情

AWS IAM在租户隔离的会话标签中承担相同的角色

发布于 2025-01-23 11:52:02 字数 1412 浏览 0 评论 0 原文

我正在制作由API Gateway和AWS Lambda提供支持的无服务器应用程序。每个Lambda都有一个单独的角色，以供至少特权访问。对于租户隔离，我正在研究 abac和iam

可以为对象访问＆lt; tenantid＆gt; 作为前缀的s3 bucket的示例。角色名称： test-lole

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "s3:GetObject",
            ],
            "Resource": "arn:aws:s3:::test-bucket/${aws:PrincipalTag/TenantID}/*"
        },
        {
            "Effect": "Allow",
            "Action": [
                "sts:AssumeRole",
            ],
            // Same role ARN: Ability to assume itself
            "Resource": "arn:aws:iam::<aws-account-d>:role/test-role"
        }
    ]
}

我假设在lambda中扮演相同的角色，但是

const credentials = await sts.assumeRole({
    RoleSessionName: 'hello-world',
    Tags: [{
        Key: 'TenantID',
        Value: 'tenant-1',
    }],

    RoleArn: 'arn:aws:iam::<aws-account-d>:role/test-role'
}).promise();

我试图用一个角色而不是两个角色来实现ABAC（仅具有一个职位许可，另一个角色，另一个角色）实际S3许可的角色），以便更容易管理角色，并且也不会达到5000的硬限制。这样做是一个好习惯，还是这种方法具有安全性漏洞？

原文

I am working on a serverless app powered by API gateway and AWS lambda. Each lambda has a separate role for least privilege access. For tenant isolation, I am working on ABAC and IAM

Example of the role that provides get object access to s3 bucket having <TenantID> as the prefix.
Role Name: test-role

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "s3:GetObject",
            ],
            "Resource": "arn:aws:s3:::test-bucket/${aws:PrincipalTag/TenantID}/*"
        },
        {
            "Effect": "Allow",
            "Action": [
                "sts:AssumeRole",
            ],
            // Same role ARN: Ability to assume itself
            "Resource": "arn:aws:iam::<aws-account-d>:role/test-role"
        }
    ]
}

I am assuming the same role in lambda but the the session tag as

const credentials = await sts.assumeRole({
    RoleSessionName: 'hello-world',
    Tags: [{
        Key: 'TenantID',
        Value: 'tenant-1',
    }],

    RoleArn: 'arn:aws:iam::<aws-account-d>:role/test-role'
}).promise();

I am trying to achieve ABAC with a single role instead of two(one role with just assuming role permission, another role with actual s3 permission) so that it would be easier to manage the roles and also won't reach the hard limit of 5000.
Is it a good practice to do so, or does this approach has security vulnerability?

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

花开浅夏 2025-01-30 11:52:02

它应该起作用，但是重新使用这样的角色感到有些奇怪。对我来说，扮演Lambda函数的角色对我来说更有意义，而Lambda函数使用的S3访问作用（总共有两个角色）。

另外，请确保您不依赖代码中的 tenantid 值的用户输入，因为可以滥用它以访问另一个房客的对象。

回复收藏 0 原文

╄→承喏 2025-01-30 11:52:02

TLDR：我不建议您这样做。

能够假设自己

我认为这里有些混乱。 JSON文档是A 策略，而不是角色。 AWS中的政策是一个安全声明，即谁可以访问什么条件。角色只是“谁”的抽象。

据我了解，您不需要两个角色来做您需要做的事情。但是您可能需要两个策略。

AWS中有两种类型的策略，这个问题感兴趣：：

基于身份的策略是基于身份的策略的，这可能是一个角色。
基于资源的政策附在资源上 - 这也可能是一个角色！

角色的常见用例＆amp;策略适用于许可授权授权。在这种情况下，我们有：

其他校长可以假设的角色，也许是暂时的
信托政策，它可以控制谁可以在哪个条件下承担角色，以及他们在假设中可以采取什么行动。信托政策是资源策略的特殊情况，其中资源是角色本身。
许可政策，授予任何担任该角色的人。这是身份政策的特殊情况，这是根据角色的假设授予的。

关键点：两种政策都与相同的角色相关。现在有一个角色，两个政策。

现在，让我们看一下您的政策。显然，它试图立即成为两件事：有关该角色的权限政策和信任政策。

它的这一部分试图成为信任政策：

    {
        "Effect": "Allow",
        "Action": [
            "sts:AssumeRole",
        ],
        // Same role ARN: Ability to assume itself
        "Resource": "arn:aws:iam::<aws-account-d>:role/test-role"
    }

由于缺少“ principal” 部分，因此看起来允许任何人担任此角色。对我来说，这看起来有些狡猾，尤其是因为您既定的目标是“最少的特权访问”。

这部分试图成为权限策略：

    {
        "Effect": "Allow",
        "Action": [
            "s3:GetObject",
        ],
        "Resource": "arn:aws:s3:::test-bucket/${aws:PrincipalTag/TenantID}/*"
    },

这不需要“ principal” 部分，因为这是一个身份策略。

据推测，您将策略作为信托政策和给定角色的权限政策。似乎您想避免击中策略（不是角色）最大配额限制5000定义在这里：

AWS帐户中的客户托管政策

即使以某种方式奏效，这也没有意义，我也不会这样做。例如，考虑信任政策。信托策略应该是基于资源的策略。角色是资源。因此，在策略中指定“资源”是没有意义的：

        "Resource": "arn:aws:s3:::test-bucket/${aws:PrincipalTag/TenantID}/*"
    },

更糟糕的是，将其包含在信托政策中：

    {
        "Effect": "Allow",
        "Action": [
            "s3:GetObject",
        ],
        "Resource": "arn:aws:s3:::test-bucket/${aws:PrincipalTag/TenantID}/*"
    },

这是什么意思？

也许我误解了这个问题，但是据我了解，我的建议是：

保持一个角色 - 可以
制定两个单独的政策：信任政策＆amp;权限策略
考虑将“ principal” 元素添加到信托策略
附加信托＆amp;角色的权限政策适当地
探索其他途径，以避免超过5000政策限制

TLDR: I would not advise you to do this.

Ability to assume itself

I think there is some confusion here. The JSON document is a policy, not a role. A policy in AWS is a security statement of who has access to what under what conditions. A role is just an abstraction of a "who".

As far as I understand the question, you don't need two roles to do what you need to do. But you will likely need two policies.

There are two types of policies in AWS, of interest to this question: Identity based policies and Resource Based policies:

Identity-based policies are attached to some principal, which could be a role.
Resource-based policies are attached to a resource - which also could be a role!

A common use case of roles & policies is for permission delegation. In this case, we have:

A Role, that other principals can assume, maybe temporarily
A trust policy, which controls who can assume the role, under what conditions, and what actions they can take in assuming it. The trust policy is a special case of a resource policy, where the resource is the role itself.
A permissions policy, which is granted to anyone who assumes the role. This is a special case of an identity policy, which is granted based on the assumption of a role.

Key point: both policies are associated to the same role. There is one role, two policies.

Now, let's take a look at your policy. Clearly, it's trying to be two things at once: both a permissions policy and a trust policy for the role in question.

This part of it is trying to be the trust policy:

    {
        "Effect": "Allow",
        "Action": [
            "sts:AssumeRole",
        ],
        // Same role ARN: Ability to assume itself
        "Resource": "arn:aws:iam::<aws-account-d>:role/test-role"
    }

Since the "Principal" section is missing, looks like it's allowing anyone to assume this role. Which looks a bit dodgy to me, especially since one of your stated goals was "least privilege access".

This part is trying to be the permissions policy:

    {
        "Effect": "Allow",
        "Action": [
            "s3:GetObject",
        ],
        "Resource": "arn:aws:s3:::test-bucket/${aws:PrincipalTag/TenantID}/*"
    },

This doesn't need a "Principal" section, because it's an identity policy.

Presumably you're resuing that policy as both the trust policy and the permissions policy for the given role. Seems like you want to avoid hitting the policy (not role) maximum quota limit of 5000 defined here:

Customer managed policies in an AWS account

Even if somehow it worked, it doesn't make sense and I wouldn't do it. For example, think about the trust policy. The trust policy is supposed to be a resource-based policy attached to the role. The role is the resource. So specifying a "Resource" in the policy doesn't make sense, like so:

        "Resource": "arn:aws:s3:::test-bucket/${aws:PrincipalTag/TenantID}/*"
    },

Even worse is the inclusion of this in the trust policy:

    {
        "Effect": "Allow",
        "Action": [
            "s3:GetObject",
        ],
        "Resource": "arn:aws:s3:::test-bucket/${aws:PrincipalTag/TenantID}/*"
    },

What does that even mean?

Perhaps I'm misunderstanding the question, but from what I understand my advice would be: