获取联合用户的AWS主标签值
我们将AWS SSO与外部身份提供商一起使用,并启用了ABAC(访问控制属性)。我们正在传递一些会话标签,例如 ssmsessionrunas
。假设当前在外壳中配置的用户是联合用户,我们可以通过AWS CLI获得会话/主标签的值吗?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
尽管您是通过AWS SSO(IAM身份中心)传递会话标签,但总体上的问题是是否有可能获得AWS会话标签的值。
似乎无法通过API调用或在控制台中获得完整的AWS会话标签集。相反,只能通过两种方式对当前AWS会话标签进行部分可见性:
检查CloudTrail日志。这仅显示您的新标签是明确应用于新创建的会话以及传入的及时会话标签。
。
编写IAM策略以允许/拒绝使用
条件
条款$ {principaltag/tag_name}
。1。CloudTraillogs CloudTrail
Logs在进行以下API调用时显示了会话标签的子集:
asherole
,asherolewithSaml
,apherolewithwebidentity
和getFeDerationToken
(参考:)在相应的CloudTrail事件中,您会看到:
asherolewithSAML
和asherolewithwebidentity
,在没有现有会话的情况下调用。)但是,这些Cloudtrail Event - 传输会话标签,这些标签未由新会话继承。 (如果有一种看待它们的方法,我想知道...)
示例
此处是一个摘录
request> requestParameters
从cloudtrail事件中显示apherole
call:IT显示以下内容:
tagkey1:tagvalue1
及时会话标签的会话进行的。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
:那么,可以测试当前会话标签的确切值> sessionTag 通过尝试列出对象:
或者,要测试
sessiontag
的存在,无论其值如何,上述策略中的条件
element可以是调整以使用null
条件操作员: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:
Examine CloudTrail logs. This only shows you new tags being explicitly applied to newly created sessions, as well as incoming transitive session tags.
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
, andGetFederationToken
(ref: Passing session tags in AWS STS)In the corresponding CloudTrail events, you see:
AssumeRoleWithSAML
andAssumeRoleWithWebIdentity
, 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 anAssumeRole
call:It reveals the following:
TagKey1: TagValue1
transitive session tag.TagKey4: TagValue4
;TagKey5: TagValue5
TagKey4: TagValue4
is transitive.However, the event entry does not show the following:
TagKey2: TagValue2
;TagKey3: TagValue3
TagKey2
was explicitly passed via a previousAssumeRole*
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 tagSessionTag
:Then, it is possible to test for an exact value of a current session tag
SessionTag
by attempting to list objects:Alternatively, to test for the presence of
SessionTag
, regardless of its value, theCondition
element in the above policy can be adjusted to use theNull
condition operator: