Hello @FlorianSW. Could you explain why having sts:SetSourceIdentity and sts:TagSession would help when you use temp cred to run Copilot commands? Is there any docs that I can refer to to make sure this is secure?

FWIW for temporary credential SSO works for Copilot right now: #4359

Hi @iamhopaul123,

sure, sorry for not providing any more details from the get go :)

We're not using AWS SSO for our accounts in our organisation. Instead, we have a custom built company portal, where our users can obtain temporary AWS credentials for an account they have access to. Technically these credentials are created using the AWS STS AssumeRole API, which returns the well-known AWS Access Key ID, Secret Access Key and Session Token.

As one of our auditing principles, when a user obtains such credentials, we set the SourceIdentity parameter of the AssumeRole API call to their username in our central IdP. This allows us to correlate specific actions in CloudTrail to specific users in our corporate directory.

The benefit (or negative, when it comes to roles) is, that the SourceIdentity property of a role session cannot be changed and persists through subsequent role changes (role chaining). That means, if one of our users obtains credentials for their AWS account, they get a role session with a SourceIdentity attached to it. They have an IAM policy, that allows them to assume another role in their account (as long as the Assume role policy of that role allows that as well). However, this operation would only succeed, if the role to be assumed, has the permission sts:SetSourceIdentity in their assume role policy.

For any other use case, where a role session without a source identity is used, the added permission should not have any effect at all. Technically, someone, when assuming the role, could (with that) add a source identity when assuming the role, while their role session does not have one already, though.

The sts:TagSession permission is slightly different, but mostly the same for our use case. While we set the SourceIdentity parameter in the initial AssumeRole API call, we also add certain session tags, such as other identifiers from our corporate directory. As these tags should, for auditing reasons as well, persist through role chaining, some of these tags are marked as transitive. They will, just like the SourceIdentity, be passed to other roles someone assumes with these credentials. Doing this, however, requires the sts:TagSession permission on the assume role policy. You can find more information about that in the docs.

Hello @FlorianSW. After talking to AWS app security engineers, their recommendation would be asking you to use env override for the env manager role before we have native support for this feature (optionally enabled instead of always adding new permissions by default). The reason is because we want to follow principle of least privilege, so only allow the role the minimal amount of privileges it needs to compete its job. Please let me know if you have any concern!

Hi,

I can totally understand that :) I'm actually doing that already, however, it seems that env overrides are not taken into account when the env manager role is first created (I tried it with copilot init, and I'm pretty sure I tried a copilot env deploy as well, but that I'm not sure out of my head). That means, that the role is currently (if I didn't do anything wrong) always deployed without the necessary permissions, hence my feature request :) all subsequent deploy of the environment always tries to use the env manager role, which cannot be assumed with a source identity or transitive tags associated.

OK that totally makes sense to me then since there's no easy workaround. Let's continue our discussion in the open PR!