Potential breaking change: exec subcommand

[chrnorm]

Hi everyone! We’ve had an issue raised on improving the --exec command: #216. The current implementation of --exec has limitations as described in the issue.

The specific option that we’re considering is making exec a subcommand:

assume exec -- my command to run 'now supporting quotes'

This is a breaking change to the assume CLI which isn’t something we treat lightly - I’d love to hear your feedback on this.

The specific breaking change in behaviour is that if you happen to have an AWS profile called exec, running assume exec will no longer assume that profile, and you’d have to rename that profile. Additionally, I'd want to phase out the --exec argument in future in favor of the assume exec subcommand (see below).

What I’d love to hear from you is:

• Do you currently use assume --exec? What use cases do you use it for?
• Are you for or against making exec a subcommand? Why?
• If we proceeded with this change, how much effort would it take you to change to the assume exec subcommand approach?

Note that for backwards compatibility, we’d also leave the existing --exec functionality as-is. So we’d have assume exec (new) and assume --exec (deprecated). If we proceed with this we’d intend on removing --exec in v1.0.0 and give plenty of heads up around this. We don’t have a concrete timeline on the v1.0.0 release - but I’d estimate 12 months.

[nicgrayson]

I support changing to a subcommand so it works like other tools, namely, kubectl and aws-vault.

[sosheskaz]

I'm pretty heavily in favor of changing to use subcommands. I see these benefits:

• New functionality can be added by adding more subcommands.
• Subcommands could now have their own flags, allowing greater flexibility of implementation. For example, a console or c subcommand could accept a --browser flag, or an exec subcommand could accept a --shell flag.
• Positional args are now freely available in their proper indices for each subcommand, which also makes the implementation more flexible.
• Modifying assume to use subcommands would also support other functionality which needs to be aware of the assume implementation.

For example, if we wanted to write kubeconfigs compliant with the EKS recipe, it would probably be best to build it directly into granted, i.e. assume <profile> update-kubeconfig .... This can't be done simply via wrapping aws eks update-kubeconfig exec alone, because it needs to modify the result before it gets merged into the kubeconfig. This would also need the ability to have contextual arguments, for the EKS cluster name, role ARN, and kubeconfig (at least). I do not think this would be possible without a subcommand structure, or at least any implementation would likely have to make big compromises.

[1oglop1]

@chrnorm Are there any chances this gets implemented?
I'd like to run assume profile -- aws sts get-caller-identity, this flow is baked in my muscle memory from aws-vault, which has become unmaintained.