Skip to main content

Run stack with user credential from AWS IAM Identity Center

Feature Requests

We use AWS IAM Identity Center for authenticating users to the AWS environment. When a user runs a stack in Spacelift, we want the run to use their own identity for the AWS credentials. Technically, both Spacelift and AWS IdC are using the same external IdP (Azure AD), so it feels like Spacelift could connect the two in some way and authenticate to AWS with the user's identity and retrieve a credential for an account/role that the user is authorized.

Certainly, runs triggered by events would retrieve credentials differently, since there would be no user interaction. This is just intended for when a user triggers a run directly themselves.

Workaround
None
Status: ⌛ Waiting for User2 comments

Log in to comment and vote

Comments2

  • Olive Gizmo

    •

    Sep 18

    Hi, thanks for picking this up. I am one of the upvoters and would like to add our use case. For us it is more than audit: with Identity Center in place, the AWS integration itself feels clunky.

    Today it is a static IAM role per account, trusted by Spacelift's own AWS account with an external id, and in our setup attached to every stack in that account. It has to exist before Spacelift can manage resources in that account, it carries broad standing permissions because it must be able to apply anything any stack might change, and anyone allowed to trigger a run borrows it whole, regardless of their own AWS permissions. Attribution is possible, but it means matching the confirmer in Spacelift against CloudTrail entries of a shared role by timestamp, across two systems, and it gets ambiguous when runs overlap.

    What we want for manually triggered runs (I believe the original poster is asking for roughly the same): the run authenticates to AWS as the person who triggered it, through Identity Center, since both Spacelift and Identity Center already trust the same Entra tenant. The run can then do only what that person is allowed to do, CloudTrail shows the human identity directly, the shared role shrinks to what unattended runs need, and a new account is usable from Spacelift as soon as the user has access to it, with nothing to pre-provision.


    Unattended runs (VCS pushes, drift detection, schedules) would keep a machine identity.

    Ideally Spacelift itself would be an identity in Identity Center; since Identity Center has no machine identities today, the per-run OIDC token is the right fit there, with roles scoped by space, stack and run type (drift detection runs are proposed, so read-only). An intermediate step that would get us most of the way: include the triggering user's identity (email, Entra object id, groups) as claims in the run's OIDC token. We could then condition AWS trust policies on them ourselves. As far as we can tell, the token today identifies the stack, space and run type, but not the person.

  • Ovidiu Moise

    Team•

    Jul 8

    @Loren Gordon and Upvoters, can you explain a bit more how you would use that linking between AWS IaM and Azure AD? You’d just want to store the AWS credentials in run audits, or is it more than that? What’s the final outcome for you?