AWS Access Control Overview
With the exception of “root accounts” (beyond the scope of this article), all access to AWS resources is controlled by AWS Identity and Access Management, usually referred to by its initials IAM (pronounced “I am”). People accessing AWS resources in the normal course of duty, in any of the configurations recommended and supported by Cloud Posse, exclusively access AWS resources by “assuming” IAM Roles.
Whether or not you are using the aws CLI or other tools that work with AWS, credentials are handled relatively consistently via the AWS SDK (published as a library in several programming languages). Once you configure the AWS CLI correctly, all the other tools should work, too.
The $AWS_CONFIG_FILE (by default, $HOME/.aws/config) contains profiles that specify (among other things) what AWS IAM Role to assume when using that profile and where to get the credentials that allow you to use that profile. These profiles can be categorized into "Primary" and "Derived" profiles. (I don't think AWS has terminology for this, so we invented our own. If they do and someone would inform us about them, then we will use theirs if it is not too confusing.)
- Primary Profile
A Primary profile has credentials provided directly. When you log in via Leapp, Leapp provides the credentials for the profile you specify in the Leapp session.
aws-vaultdoes the same kind of thing. AWS SSO does, too, although a bit differently. The main thing is that a Primary profile does not have asource_profileentry.- Derived Profile
A Derived profile does have a
source_profileentry. It does not get credentials on its own, but instead, it gets credentials from the source profile it references. To use a derived profile, the source profile has to have valid credentials, and it has to be allowed to assume the role specified in the Derived profile. Note that it is not a requirement that the source profile is a Primary profile. The source profile can be another Derived profile; all that matters is that the chain of source profiles end at a role with valid credentials and that at every step in the chain, the source profile is allowed to assume the role specified in the Derived profile that references it.
You should only use Leapp (or aws sso login) to log into Primary profiles. Once logged into a Primary profile, any tool should be able to use that profile or any Derived profile simply by specifying which profile to use (usually by setting the AWS_PROFILE environment variable via export AWS_PROFILE=profile-name or via a command-line flag, configuration string, or configuration file, such as in the case of kubectl where it is specified via the users.user.exec.env section of the $KUBECONFIG file).
The AWS documentation and examples are confusing. In this scenario, it is important that you do not include mfa_serial in the Derived profile configuration. The use case for having mfa_serial in the Derived profile is if you did not use MFA to authenticate to your Primary profile. In that (rare) case, the Derived profile really turns into a sort of Primary profile, because it is responsible for providing a credential (the MFA token) that the source profile does not have. That is when you need mfa_serial in the Derived profile and when you should put it in Leapp instead of just the $AWS_CONFIG_FILE.
If you put mfa_serial in your Derived profile, you will repeatedly and needlessly be prompted for an MFA token every time you assume the role, which, because it is a chained role, will be at least once an hour, and that prompt may not be visible because it is coming from the AWS SDK. With your Primary profile, you only get prompted when your session expires, which can be as long as 12 hours.