Poor usability with MFA
juhani-hietikko opened this issue · 6 comments
We've been using awslogs for a long time in our team, but recently a change in the way we use AWS accounts made it much less usable.
We took into use a separate federation account where our IAM users live, and access our other AWS accounts (where we have among other things CloudWatch logs) by assuming a role on the target account from the federation account. The federation account users always have multi-factor authentication (MFA). The AWS profile config for accessing a target account looks something like this:
~/.aws/credentials:
[federation-account]
aws_access_key_id = xxxx
aws_secret_access_key = yyyyy
~/.aws/config:
[profile assume-role-via-federation-account]
source_profile = federation-account
mfa_serial = arn:aws:iam::federation-account-id:mfa/iam-user-name
role_arn = arn:aws:iam::target-account-id/AssumedRole
It appears that boto3 actually supports this kind of AWS profile out of the box: when awslogs is called with --profile assume-role-via-federation-account in this example, boto3 automatically asks the user to enter a MFA code. But, even though this basically works, a major usability issue is that the MFA code is prompted every time an awslogs command is executed. The user also needs to wait for the MFA device to produce a new code if the current one was already used, making it impossible to execute several awslogs commands in rapid succession.
A good solution would be to configure the boto3 client to use credential cache in the same way as e.g. AWS CLI does. We have a proof of concept for this approach here in a fork (the two latest commits):
https://github.com/Opetushallitus/awslogs
This modification seems to solve the problem we have, and doesn't seem to produce any regression when using a profile that doesn't need credential caching. I suppose we'll be using the forked version for the time being, but just wanted to suggest that maybe something like this could be useful in the main project too.
Any possibility in getting the functionality in https://github.com/Opetushallitus/awslogs (or something equivalent) to mainstream?
This looks sensible to me, I suppose some handling will be required for when no session is available. @juhani-hietikko if somebody puts together a PR, I will love to merge it.
I started looking into producing a high quality PR based on the fork that we've been happily using since June. At least the mocking of boto3.client needs to be fixed, a lot of tests are currently failing in the fork.
It starts to feel that fixing the mocking is actually quite a big blocker for me. I wonder if someone with some experience with the python mocking library would fix the tests in a matter of minutes? I just can't seem to figure this out...
Ok, I think I found a good enough approach to fix the tests! I'll polish this to a PR tomorrow-ish.
Released as part of 0.11.0