获取联合用户的AWS主标签值

发布于 2025-02-08 15:01:43 字数 137 浏览 0 评论 0 原文

我们将AWS SSO与外部身份提供商一起使用,并启用了ABAC(访问控制属性)。我们正在传递一些会话标签,例如 ssmsessionrunas 。假设当前在外壳中配置的用户是联合用户,我们可以通过AWS CLI获得会话/主标签的值吗?

We are using AWS SSO with an External Identity Provider and have enabled ABAC (Attributes for Access Control). We are passing some session tags like SSMSessionRunAs. Can we get the value of the session/principal tag being passed via AWS CLI assuming that the user currently configured in the shell is the Federated user?

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

扫码二维码加入Web技术交流群

发布评论

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

评论(1

嘿咻 2025-02-15 15:01:43

尽管您是通过AWS SSO(IAM身份中心)传递会话标签,但总体上的问题是是否有可能获得AWS会话标签的值。

似乎无法通过API调用或在控制台中获得完整的AWS会话标签集。相反,只能通过两种方式对当前AWS会话标签进行部分可见性:

  1. 检查CloudTrail日志。这仅显示您的新标签是明确应用于新创建的会话以及传入的及时会话标签。


  2. 编写IAM策略以允许/拒绝使用条件条款 $ {principaltag/tag_name}

1。CloudTraillogs CloudTrail

Logs在进行以下API调用时显示了会话标签的子集: asherole asherolewithSaml apherolewithwebidentity getFeDerationToken (参考:

在相应的CloudTrail事件中,您会看到:

  • Tags 在API调用中传递的标签适用于新会话;和
  • 传入的及时会话标签,将传播到新会话。 (不适用于 asherolewithSAML asherolewithwebidentity ,在没有现有会话的情况下调用。)

但是,这些Cloudtrail Event - 传输会话标签,这些标签未由新会话继承。 (如果有一种看待它们的方法,我想知道...)

示例

此处是一个摘录 request> requestParameters 从cloudtrail事件中显示 apherole call:

"requestParameters": {
    "incomingTransitiveTags": {
        "TagKey1": "TagValue1"
    },
    "roleArn": "arn:aws:iam::XXXXXXXXXXXX:role/TestTagRole1",
    "roleSessionName": "some-role-session-name",
    "tags": [
        {
            "key": "TagKey4",
            "value": "TagValue4"
        },
        {
            "key": "TagKey5",
            "value": "TagValue5"
        }
    ]
    "transitiveTagKeys": [
        "TagKey4"
    ]
}

IT显示以下内容:

  • 调用是由具有 tagkey1:tagvalue1 及时会话标签的会话进行的。
  • 呼叫明确将标签应用于 new session: tagkey4:tagvalue4 ; tagkey5:tagvalue5
  • 新的会话标签 tagkey4:tagvalue4 是传递的。

但是,事件条目执行不是显示以下内容:

  • 调用是由一个会话进行的,该会话还具有两个非传递性会话标签: tagkey2:tagvalue2 ; tagkey3:tagvalue3
  • tagkey2 明确通过以前的 asherole*调用,因此出现在较早的CloudTrail事件中。
  • tagkey3 是通过IAM用户/角色标签隐式应用的 ,因此不会出现在任何可见的会话记录上(据我所知)。

顺便说一句:

也可以通过API < /a>,在活动历史上出现事件有几分钟的延迟,这似乎使实时测试会话标签是不可行的。

2。iam策略,

您可以使用IAM策略,该策略允许或拒绝基于 $ {principalTag/tag_name} 。例如,如果S3前缀匹配会话标签的值 sessigntag

{
    "Version": "2012-10-17",
    "Statement": {
        "Effect": "Allow",
        "Principal": {
            "AWS": "*"
        },
        "Action": "*",
        "Resource": "arn:aws:s3:::session-tags-test",
        "Condition": {
            "StringEquals": {
                "s3:prefix": "${aws:PrincipalTag/SessionTag}"
            }
        }
    }
}

那么,可以测试当前会话标签的确切值> sessionTag 通过尝试列出对象:

$ aws s3api list-objects --bucket session-tags-test --prefix SessionTagValue

$ aws s3api list-objects --bucket session-tags-test --prefix IncorrectValue
An error occurred (AccessDenied) when calling the ListObjects operation: Access Denied

或者,要测试 sessiontag 的存在,无论其值如何,上述策略中的条件 element可以是调整以使用 null 条件操作员:

"Condition": {
    "Null": {
        "aws:PrincipalTag/SessionTag": "false"
    }
}

Though you're passing session tags via AWS SSO (IAM Identity Center), the general question is whether it is possible to get the value of an AWS session tag.

There seems to be no way to get the full set of AWS session tags, neither via an API call nor in the console. Rather, it is only possible to get partial visibility into the current AWS session tags in two ways:

  1. Examine CloudTrail logs. This only shows you new tags being explicitly applied to newly created sessions, as well as incoming transitive session tags.

  2. Write IAM policies to allow/deny access using a Condition clause with ${principalTag/TAG_NAME}.

1. CloudTrail Logs

CloudTrail logs show a subset of session tags when the following API calls are made: AssumeRole, AssumeRoleWithSAML, AssumeRoleWithWebIdentity, and GetFederationToken (ref: Passing session tags in AWS STS)

In the corresponding CloudTrail events, you see:

  • Tags explicitly passed in the API call which apply to the new session; and
  • Incoming transitive session tags, which propagate to the new session. (Does not apply to AssumeRoleWithSAML and AssumeRoleWithWebIdentity, which are called without an existing session.)

However, these CloudTrail events do not include current, non-transitive session tags, which are not inherited by the new session. (If there is a way to see them, I would like to know...)

Example

Here is an excerpt showing requestParameters from a CloudTrail event for an AssumeRole call:

"requestParameters": {
    "incomingTransitiveTags": {
        "TagKey1": "TagValue1"
    },
    "roleArn": "arn:aws:iam::XXXXXXXXXXXX:role/TestTagRole1",
    "roleSessionName": "some-role-session-name",
    "tags": [
        {
            "key": "TagKey4",
            "value": "TagValue4"
        },
        {
            "key": "TagKey5",
            "value": "TagValue5"
        }
    ]
    "transitiveTagKeys": [
        "TagKey4"
    ]
}

It reveals the following:

  • The call is made from a session which has the TagKey1: TagValue1 transitive session tag.
  • The call explicitly applies tags to the new session: TagKey4: TagValue4; TagKey5: TagValue5
  • The new session tag TagKey4: TagValue4 is transitive.

However, the event entry does not show the following:

  • The call is made from a session which also has two non-transitive session tags: TagKey2: TagValue2; TagKey3: TagValue3
  • TagKey2 was explicitly passed via a previous AssumeRole* call, and thus appears in an earlier CloudTrail event.
  • TagKey3 was implicitly applied via an IAM user/role tag and as such does not appear on any visible session record (to my knowledge).

Aside: Programmatic access to CloudTrail

While CloudTrail can also be accessed via an API, there is a delay of several minutes for an event to appear in its event history, which seems to make it infeasible to test for session tags programmatically in real-time.

2. IAM policies

You could make use of IAM policies which allow or deny based on ${principalTag/TAG_NAME}. For instance, the below policy will allow the listing of S3 objects if the S3 prefix matches the value of session tag SessionTag:

{
    "Version": "2012-10-17",
    "Statement": {
        "Effect": "Allow",
        "Principal": {
            "AWS": "*"
        },
        "Action": "*",
        "Resource": "arn:aws:s3:::session-tags-test",
        "Condition": {
            "StringEquals": {
                "s3:prefix": "${aws:PrincipalTag/SessionTag}"
            }
        }
    }
}

Then, it is possible to test for an exact value of a current session tag SessionTag by attempting to list objects:

$ aws s3api list-objects --bucket session-tags-test --prefix SessionTagValue

$ aws s3api list-objects --bucket session-tags-test --prefix IncorrectValue
An error occurred (AccessDenied) when calling the ListObjects operation: Access Denied

Alternatively, to test for the presence of SessionTag, regardless of its value, the Condition element in the above policy can be adjusted to use the Null condition operator:

"Condition": {
    "Null": {
        "aws:PrincipalTag/SessionTag": "false"
    }
}
~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文