How to use sso key instead of access key and secret key in aws?

[aadi308]

Initially, I passed the AWS access key and secret key as environment variables to the space lift, and this approach worked well. However, I now want to use AWS SSO instead of access and secret keys. I'm wondering how I can configure SSO as the provider for AWS.

[lorengordon]

I am also very interested in this. I created a feature request in the feedback portal, https://portal.feedback.us.pendo.io/app/#/case/388887

[jubranNassar]

Hey @aadi308 and @lorengordon - I apologize for the delayed response.

Initially, I passed the AWS access key and secret key as environment variables to the space lift, and this approach worked well. However, I now want to use AWS SSO instead of access and secret keys. I'm wondering how I can configure SSO as the provider for AWS.

We typically don't recommend authenticating with AWS via access keys and secret keys. In spacelift, the native way would be through the AWS cloud integration, please see here: https://docs.spacelift.io/integrations/cloud-providers/aws

With that being said, if you still would like to use AWS SSO at runtime, the only way I can think of is to mount an .aws/config file, and then run aws sso login --profile <profile_name> as a pre_init hook. Please let me know if you have any additional questions regarding this

[lorengordon]

With that being said, if you still would like to use AWS SSO at runtime, the only way I can think of is to mount an .aws/config file, and then run aws sso login --profile <profile_name> as a pre_init hook. Please let me know if you have any additional questions regarding this

I don't think that really works, since aws sso login would require some interaction on the the part of the user?

I think what I had in mind is a Spacelift feature, that uses the user's Spacelift identity to authenticate to AWS, when a run is triggered from the Spacelift console. This could be Spacelift as an OIDC provider (similar to Github Actions, or Gitlab-CI), or possibly rely on the user environment having AWS Identity Center and Spacelift both using the same external IdP. Effectively, the goal is improving audit capability of who did what (in CloudTrail), and more granular permissions management such that if a user does not have a given permission in AWS then the associated API actions would fail.

[jubranNassar]

I don't think that really works, since aws sso login would require some interaction on the the part of the user?

you are correct, so this wouldn't really be possible in this case.

This could be Spacelift as an OIDC provider

I guess you're referring to this?

[lorengordon]

I guess you're referring to this?

Oh! When did that happen? Yes, that's the idea. But, with a new claim that identifies the actual Spacelift user, when the stack/task is triggered by a user. We'd need some way to match the user identity in Spacelift to their permissions in AWS (and other cloud providers). Which, in AWS, would mean somehow adjust the role Spacelift assumes on some property of the request, scoped to the roles available to the user.