Setting AWS_PROFILE env var to role based profile with mfa creates general CLI error

[mikeapted]

Current Behaviour

Setting AWS_PROFILE env var to access key/secret key causes no issue but changing to a profile based on role assumption with MFA causes:

$ ecs
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x48 pc=0x18a24e8]

goroutine 1 [running]:
github.com/aws/amazon-ecs-cli-v2/internal/pkg/cli.BuildInitCmd(0x1af3220)
	/aws-amazon-ecs-cli-v2/internal/pkg/cli/init.go:254 +0x1d8
main.buildRootCmd(0x0)
	/aws-amazon-ecs-cli-v2/cmd/ecs-preview/main.go:51 +0x104
main.main()
	/aws-amazon-ecs-cli-v2/cmd/ecs-preview/main.go:24 +0x22

Expected behaviour

$ ecs
Launch and manage applications on Amazon ECS and AWS Fargate.

Commands 
  Getting Started ✨
    init        Create a new ECS application.
 
...

[kohidave]

Thanks for the heads up, we’ll dive into this.

[dennis-menge]

This still seems to be an issue, a profile based role assumption can not be used:

✘ AssumeRoleTokenProviderNotSetError: assume role with MFA enabled, but AssumeRoleTokenProvider session option not set.

One workaround is to export the AWS_SESSION_TOKEN to the env, however, this is a bit cumbersome. Additionally, this imposes quite some restrictions as documented here. Probably it would be great to add a profile switch to the CLI. Or did I miss something here?

[tomkerswill]

I'm really keen to be able to use co-pilot with cross-account roles. We are a consultancy provider with a large number of clients, and so we work on clients' accounts using cross-account roles with MFA. At the moment, it looks like copilot only works for non-MFA accounts, which is not great! Would love to hear if there's an update, 3 years on.

[tomkerswill]

Any update from AWS on this? It seems like a bit of an issue to not support MFA... The workarounds are cumbersome, as others have noted!

[efekarakus]

Hi @tomkerswill! Apologies on the late response 🙇

OK I've gone through the blog post here: https://aws.amazon.com/blogs/developer/assume-aws-iam-roles-with-mfa-using-the-aws-sdk-for-go/

Here is the proposed programming model to ensure Copilot works with MFA:

Programming Model

It looks like we can add AssumeRoleTokenProvider: stscreds.StdinTokenProvider to the following block and it should do the trick:

copilot-cli/internal/pkg/aws/sessions/sessions.go

Lines 102 to 107 in 851f553

	func (p *Provider) FromProfile(name string) (*session.Session, error) {
	sess, err := session.NewSessionWithOptions(session.Options{
	Config: *newConfig(),
	SharedConfigState: session.SharedConfigEnable,
	Profile: name,
	})

However,

If a shared configuration profile specifies a role to assume, and the mfa_serial field is provided, the SDK requires that the AssumeRoleTokenProvider session option is also set. There’s no harm in always setting the AssumeRoleTokenProvider session for applications that will always be run by a person. The field is only used if the shared configuration’s profile has a role to assume, and then sets the mfa_serial field. Otherwise, the option is ignored.

Hypothesis to validate: If your profile doesn't contain mfa_serial and we enable AssumeRoleTokenProvider does it halt the program?

[profile assume_role_profile]
role_arn = arn:aws:iam::<account_number>:role/<role_name>
source_profile = other_profile

If not then, we're all good.
If it does, then we need to know if the profile has the mfa_serial field provided so that we only set AssumeRoleTokenProvider then.

Update: I believe it won't halt because the SDK only sets the TokenProvider if there is a MFASerial key: https://github.com/aws/aws-sdk-go/blob/92b5621bf8338d68f64c79cd094969d289428723/aws/session/credentials.go#L260-L264

[efekarakus]

A fix is out in #3331!

[efekarakus]

Hi folks! The fix is now released https://github.com/aws/copilot-cli/releases/tag/v1.16.0 🥳

See announcement: https://aws.github.io/copilot-cli/blogs/release-v116/