Re-creating this issue since #9855 don't show up in the list of issues after the account that posted it was deleted.
It's great to see that the CDK CLI now supports MFA since #6510 was merged! However, the MFA credentials are not cached, which means that for every deploy/synth/diff it requires you to enter your MFA credentials again.
As a user I would like to not have to enter my MFA credentials for every CLI command.
Cache the credentials in some way for some amount of time so that users don't have to enter their MFA credentials every time they call a CLI command.
This is a 馃殌 Feature Request
@shivlaks not sure if this was correct or you'd rather update the reporter on the previous issue #9855
I understand that this is a usability pain point, but the point of a TOTP is really that it can't be cached because it's time-dependent, and its lifetime window is on the order of 30-60 seconds.
What other tools might do is cache the AssumeRole credentials somewhere on your disk. Personally, that's very scary to me and I don't want to be writing a tool that stores user credentials somewhere on disk.
Can't you use a dedicated tool that stores the temporary credentials in your ~/.aws/config or environment instead? Maybe using credential_process ?
It used to be that I could use the third-party tool aws-mfa, but since the aws-cdk now supports MFA it stopped working and I'm always prompted to enter my MFA code.
The aws-cli has this caching already, it doesn't prompt you for your MFA code every time, but stores it for something like an hour or so (unsure of the exact duration).
I assumed that since the aws-cli did it, that it would be possible to do in the aws-cdk as well. I'm confused as to the difference between aws-cdk caching it and aws-cli caching it, and why it would be a risk here compared to the aws-cli, could you elaborate on that?
There is a risk because it's a different code base. We might make mistakes; effectively your credentials might get stolen because of us. We're going to need to come up with a design and have that security reviewed. I'm not saying it can't be done, and we'll leave this ticket open as a feature request, but it's not a small change and we're unlikely to do it anytime soon.
Also, deferring to a tool that's explicitly designed to perform this task (for example, one that can store the credentials in your OS' keychain) rather than reimplementing the same features over and over again seems like a better design strategy in general.
I think the ask here was to re-use the mechanism already in use by aws-cli, storing tokens in ~/.aws/cli/cache, but from a bit of digging that comes from botocore not aws-cli itself, but the implementation & considerations made when adopting that may be of help? https://github.com/boto/botocore/blob/e216df29b07cb1a04a12dc7ffd68734d9105c0ae/botocore/credentials.py#L809
I concur with the above, i.e. AWS tools should really have a more unified experience when handling credentials. From Developer Experience point of view, as a developer used to AWS CLI, CDK should behave similarly.
Maybe CDK could even depend on AWS botocore to manage the credential process? It wouldn't be unreasonable to have it as dependency to provide secure, but usable credential process.
The current MFA process is painful, especially when one is trying things out / developing something new and has to deploy often from one's own computer.
Most helpful comment
I concur with the above, i.e. AWS tools should really have a more unified experience when handling credentials. From Developer Experience point of view, as a developer used to AWS CLI, CDK should behave similarly.
Maybe CDK could even depend on AWS botocore to manage the credential process? It wouldn't be unreasonable to have it as dependency to provide secure, but usable credential process.
The current MFA process is painful, especially when one is trying things out / developing something new and has to deploy often from one's own computer.