The in-built "Auto-prompt" feature provided by AWS CLI (v2) can be easily used to minimise the number of times we refer the CLI documentation.

Note: The AWS CLI (v1) does not support this feature. We can easily check the current version of our AWS CLI using the following command:

aws --version

Auto-prompt in action 🧑‍💻

Just type the partial command that you know, and then click "Enter" to kick-in this feature 👇

Modes of Auto-prompt

Before configuring this, lets talk about the two modes of auto-prompt feature that are provided by AWS CLI:

• Full mode: This mode uses the auto-prompt feature each time user runs an AWS command which can be either a complete command or an incomplete command. This can be done manually using the --cli-auto-prompt parameter or can be enabled permanently using the configuration file.
• Partial mode: This mode uses the auto-prompt feature if a command is incomplete or cannot be run due to a client-side validation error. This mode is useful in scenarios where you only want to be auto-prompted for commands you are unfamiliar with rather than prompted on every command.

Recommendation

Based on my experience, the "Partial mode" for this feature is better than the "Full mode". This helps to avoid any unnecessary prompts if the AWS CLI command you are running is already correct.

Configuration

The "auto-prompt" feature can be enabled using the following command:

⭐️ Full mode

aws configure set cli_auto_prompt on

⭐️ Partial mode

aws configure set cli_auto_prompt on-partial

After using the above commands, this feature is only enabled for the AWS CLI default profile.

⭐️ Enabling it for a specific AWS CLI profile

We can enable this for a specific AWS CLI profile using the --profile parameter i.e.

aws configure set cli_auto_prompt on-partial --profile <profile-name>

And thats it. We are done learning another less known but an useful feature while working with AWS.

Now you can enjoy this feature and reduce the amount of time you spend referring to the AWS CLI documentation.

Reference

Having the AWS CLI prompt you for commands

👋 Enjoyed the article? Reach out to me anytime in the comments below or on Twitter for any further discussion or feedback.

AWS Management Console - requires user name and password

Programmatic access (CLI/SDK/API) - requires access keys

What are Access Keys?

Access keys are a type of AWS credential which are used to sign programmatic requests. These requests can be generated using any of the following methods:

• AWS CLI

• AWS API

• AWS SDK

Access Keys General Structure:

The Access keys generally consist of two parts:

• Access Key ID

• Secret Access Key

However, there can be a third part called "Session Token". We will discuss more about this in our post.

Access Keys Classification:

Access keys can be classified into two types depending upon the time for which they are valid i.e.

1. Long Term Access Keys

2. Temporary Access Keys

Long Term Access Keys 👇

As the name suggests, the long term access keys are programmatic credentials which are valid forever, until they are explicitly deleted from our AWS account. This type of key is a long term customer-managed credential which is associated with an IAM user or AWS account root user.

A sample long term access key is as follows:

• Access Key ID (for example, AKIAIOSFODNN7EXAMPLE)

• Secret Access Key (for example, wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY).

We can assign up to two access keys per user (root user or IAM user). This allows the user to easily rotate the keys and meet their security standards.

Refer the AWS documentation "Managing access keys for IAM users" to create long term access keys for your user using Console/CLI/API.

However, using long term credentials is not always the ideal approach, in cases where you want to give someone limited period access to your AWS resources. This brings us to the other type of access key i.e. temporary access key.

Temporary Access Keys 👇

As you might have already guessed by the name, these keys are valid for a short period of time. So, once these keys are expired, they can no longer be used to access any AWS resources. These keys are generated using the AWS Security Token Service (STS).

A sample temporary access key is as follows

• Access Key ID (for example, ASIAJEXAMPLEXEG2JICEA)

• Secret Access Key (for example, 9drTJvcXLB89EXAMPLELB8923FB892xMFI).

• Session Token (for example, AQoXdzELDDY//////////wEaoAK1wvxJY12r2IrDFT2IvAzTCn3zHoZ7YNtpiQLF0MqZye/qwjzP2iEXAMPLEbw/m3hsj8VBTkPORGvr9jM5sgP+w9IZWZnU+LWhmg+a5fDi2oTGUYcdg9uexQ4mtCHIHfi4citgqZTgco40Yqr4lIlo4V2b2Dyauk0eYFNebHtYlFVgAUj+7Indz3LU0aTWk1WKIjHmmMCIoTkyYp/k7kUG7moeEYKSitwQIi6Gjn+nyzM+PtoA3685ixzv0R7i5rjQi0YE0lf1oeie3bDiNHncmzosRM6SFiPzSvp6h/32xQuZsjcypmwsPSDtTPYcs0+YN/8BRi2/IcrxSpnWEXAMPLEXSDFTAQAM6Dl9zR0tXoybnlrZIwMLlMi1Kcgo5OytwU=)

The "Session Token" plays the most important role in the temporary access keys. So, when we make a call using a temporary access key, the call must include the session token. AWS uses the session token to validate the temporary security credentials and confirm if these credentials are expired or not.

These keys are generally used in following scenarios:

• Temporary AWS access in less secure environments

• Providing external identity temporary access to AWS resources

• Cross account access to AWS resources.

For more details around the common scenarios for using temporary credentials, please refer the AWS documentation here.

Also, refer the "Requesting temporary security credentials" AWS documentation to get details around all the possible ways to generate temporary credentials in AWS.

⚡️Interesting Observation⚡️

Now let's assume the following scenario:

I am using temporary access keys to interact with my AWS resources via CLI. However, instead of configuring all the three parts of the access key, I excluded the "SessionToken" from the CLI configuration. So...

Q. How will now AWS know if I am using temporary credentials?
Q. Will this make my credentials long term instead of temporary?

Give it a thought. The answer to this is in the blog's title 🤔

Lets discuss that now 👇

Access Key ID - AKIA vs ASIA

If you have not already noticed, the first four characters of the Access Key ID helps us to determine the type of access key:

• Long Term Access Key → Access KeyID begin with "AKIA".

• Temporary Access Key → Access Key ID begin with "ASIA".

So, this allows AWS to determines the type of access key when the requests comes in to access any AWS resource.

In case you are using temporary access key i.e. a key starting with "ASIA", AWS would except the session token to be the third parameter in the credentials. In case the session token is missing, you would get an error for not using valid credentials.

👋 Enjoyed the article? Reach out to me anytime in the comments below or on Twitter for any further discussion or feedback.

A quick recap for AWS CLI, the following IAM policy can be attached to the IAM users, which will enforce users to use MFA to access any AWS service:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "BlockMostAccessUnlessSignedInWithMFA",
            "Effect": "Deny",
            "NotAction": [
                "iam:CreateVirtualMFADevice",
                "iam:DeleteVirtualMFADevice",
                "iam:ListVirtualMFADevices",
                "iam:EnableMFADevice",
                "iam:ResyncMFADevice",
                "iam:ListAccountAliases",
                "iam:ListUsers",
                "iam:ListSSHPublicKeys",
                "iam:ListAccessKeys",
                "iam:ListServiceSpecificCredentials",
                "iam:ListMFADevices",
                "iam:GetAccountSummary",
                "sts:GetSessionToken"
            ],
            "Resource": "*",
            "Condition": {
                "BoolIfExists": {
                    "aws:MultiFactorAuthPresent": "false"
                }
            }
        }
    ]
}

In this article, we are going to discuss the steps to generate those MFA authenticated temporary credentials. These will allow the user to pass the MFA check that we applied using the above mentioned IAM policy and will grant access to our AWS resources using AWS CLI.

To accomplish this we need to:

• Configure the AWS CLI with long-term credentials
• Generate the MFA authenticated temporary credentials
• Configure an AWS CLI profile to use the MFA authenticated credentials
• Bonus: Create a script to automate MFA credentials generation and setup

Configure the AWS CLI with long-term credentials

The long term credentials belongs to an IAM user and are called "Access Keys". These are used to sign programmatic requests to the AWS CLI. Access keys consist of two parts:

• Access Key ID (for example, AKIAIOSFODNN7EXAMPLE)
• Secret Access Key (for example, wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY).

Just a heads up, the above mentioned access key is not valid 😉

The access key is prompted to be saved when we create a new IAM user with programmatic access. In case you don't have an access key for your user, we can create a new access key from the user's summary page in IAM console as shown below:

Once you have the access key, now we can configure that in AWS CLI using the following command:

$ aws configure
AWS Access Key ID: AKIAIOSFODNN7EXAMPLE
AWS Secret Access Key: wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY
Default region name: us-east-1
Default output format: json

⚡️Interesting observation⚡️

After the above AWS CLI configuration, try running a CLI command such as to list all the S3 buckets in your AWS account and observe the output:

$ aws s3 ls

An error occurred (AccessDenied) when calling the ListBuckets operation: Access Denied

Getting an "AccessDenied" error is an expected behaviour as we are still using long-term credentials to access S3, which are not MFA authenticated. Hence, not passing the MFA check defined using the IAM policy.

Generate the MFA authenticated temporary credentials

Now we will use the above configured long term credentials to generate temporary credentials which are MFA authenticated, by running the "get-session-token" CLI command:

$ aws sts get-session-token --serial-number "YourMFADeviceSerialNumber" --token-code 123456

{
    "Credentials": {
        "AccessKeyId": "ASIAIOSFODNN7EXAMPLE",
        "SecretAccessKey": "wJalrXUtnFEMI/K7MDENG/bPxRfiCYzEXAMPLEKEY",
        "SessionToken": "AQoEXAMPLEH4aoAH0gNCAPyJxz4BlCFFxWNE1OPTgk5TthT+FvwqnKwRcOIfrRh3c/LTo6UDdyJwOOvEVPvLXCrrrUtdnniCEXAMPLE/IvU1dYUg2RVAJBanLiHb4IgRmpRV3zrkuWJOgQs8IZZaIv2BXIa2R4OlgkBN9bkUDNCJiBeb/AXlzBBko7b15fjrBs2+cTQtpZ3CYWFXG8C5zqx37wnOE49mRl/+OtkIKGO7fAE",
        "Expiration": "2020-05-19T18:06:10+00:00"
    }
}

The serial number here is an identification number of the MFA device that is associated with the IAM user. The value for this can either be the serial number for a hardware device (such as GAHT12345678 ) or an Amazon Resource Name (ARN) for a virtual MFA device (such as arn:aws:iam::123456789012:mfa/MFA-User), which we can find on the IAM console:

Configure an AWS CLI profile to use the credentials

Next up we need to create a user profile for AWS CLI to store the temporary credentials generated in the previous section, so that they can be used to access the MFA protected AWS resources.

$ aws configure --profile mfa
AWS Access Key ID: ASIAIOSFODNN7EXAMPLE
AWS Secret Access Key: wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY
Default region name: us-east-1
Default output format: json

# Do add "--profile mfa" at the end of the command
$ aws configure set aws_session_token AQoEXAMPLEH4aoAH0gNCAPyJxz4BlCFFxWNE1OPTgk5TthT+FvwqnKwRcOIfrRh3c/LTo6UDdyJwOOvEVPvLXCrrrUtdnniCEXAMPLE/IvU1dYUg2RVAJBanLiHb4IgRmpRV3zrkuWJOgQs8IZZaIv2BXIa2R4OlgkBN9bkUDNCJiBeb/AXlzBBko7b15fjrBs2+cTQtpZ3CYWFXG8C5zqx37wnOE49mRl/+OtkIKGO7fAE --profile mfa

Bonus: Create a script to automate MFA credentials generation and setup

The following script first calls the "get-session-token" command to generate the temporary credentials and then automatically configure an AWS CLI profile named "mfa" to store these credentials.

#!/bin/bash
# Usage
#
# ./setup-mfa-cred.sh $PROFILE $MFA_DEVICE_ARN $TOKEN
# ./setup-mfa-cred.sh mfa arn:aws:iam::123456789012:mfa/MFA-User 123456
#
# aws s3 ls --profile mfa

PROFILE=$1
MFA_DEVICE_ARN=$2
TOKEN=$3

echo "Getting MFA credentials"
sts=$(aws sts get-session-token \
  --serial-number $MFA_DEVICE_ARN \
  --token-code $TOKEN \
  --query 'Credentials.[AccessKeyId,SecretAccessKey,SessionToken]' \
  --output text)
sts=($sts)
echo "AWS_ACCESS_KEY_ID is ${sts[0]}"
aws configure set aws_access_key_id ${sts[0]} --profile $PROFILE
aws configure set aws_secret_access_key ${sts[1]} --profile $PROFILE
aws configure set aws_session_token ${sts[2]} --profile $PROFILE
echo "MFA Credentials stored in the AWS CLI profile: $PROFILE"

The above script requires us to pass 3 arguments i.e.

• AWS CLI profile name (i.e. mfa)
• MFA Device Serial Number (i.e. GAHT12345678 or arn:aws:iam::123456789012:mfa/MFA-User)
• MFA Token (i.e. 123456)

./setup-mfa-cred.sh mfa arn:aws:iam::123456789012:mfa/MFA-User 123456

Once the AWS CLI profile is created, then we can access our MFA protected AWS resources using the CLI command, such as:

aws s3 ls --profile mfa

Note: As the credentials generated above are temporary, so they will expire after 12 hours, which is the default value for session duration. So, we can re-run the above script with a new MFA token to configure new credentials automatically within the same AWS CLI profile.

👋 Enjoyed the article? Reach out to me anytime in the comments below or on Twitter for any further discussion or feedback.

Now coming to AWS, resources are usually accessed using the AWS Console or they are accessed programmatically (which includes CLI/SDK/API). So, in this guide we'll learn about how can we secure our AWS infrastructure using MFA when used via AWS Console or CLI (where a similar approach can be applied for API/SDK).

MFA for AWS Console

The access to AWS Console is generally provided by creating an IAM user. The IAM user when created without any MFA configuration can access the AWS console just using a username and password.

Configuring MFA for an IAM user enforce the user to provide a MFA code during signing-in into the AWS console.

As an example, let's create an IAM user in AWS and configure a MFA device for that user:

1) Login to the AWS Management Console and visit the IAM Console

2) Choose Users in the navigation pane and click "Add users" to create a new IAM user.

3) Enter the user details and click "Next: Permissions".

4) Select the permissions that you want to assign to your IAM user. For example, I have attached the "ReadOnlyAccess" AWS Managed policy which provides read-only access to all the AWS services. Now, choose "Next: Tags".

5) (Optional) Add metadata to the user by attaching tags as key-value pairs. Then, click "Next: Review". Now, review the user details and click "Create User".

Once the user is created, go back to the Users section and select the "MFA-User" to view the user's summary. Now we're going to configure the MFA device for this user.

a) Click "Manage" to assign a MFA device to this user.

b) In the Manage MFA Device wizard, choose Virtual MFA device, and then choose Continue.

The Virtual MFA device option allows to configure a MFA device using apps (such as, Google Authenticator or Authy) in our mobile devices.

In case you want to configure a different type of MFA device, you can refer to the AWS documentation here

c) Open the virtual MFA app on your mobile. For a list of apps that we can use for hosting virtual MFA devices, click here.

Now scan the QR code as shown above. MFA app will now start generating the MFA codes. If the QR code is not supported, you can type the secret key in the MFA app as an alternative.

d) Input the two consecutive MFA codes generated by the app and click "Assign MFA".

Finally, the MFA device is now configured for the IAM user. The user will now be prompted to input a MFA code on each login.

⚡️Interesting Observation⚡️

Try using the AWS CLI to access any AWS service using the credentials of the "MFA-User" and you will observe that the resources can be accessed without MFA. Weird, huh !!

Let's understand that, a key named "MultiFactorAuthPresent" with a boolean value is included when a request is made to an AWS service and tells if MFA is used or not. This key is included in the request context only when the principal uses temporary credentials to make the request. The key is not present in AWS CLI, AWS API, or AWS SDK requests that are made using long-term credentials (i.e. AccessKey & SecretAccessKey). So, this is the reason we are able to access the AWS services without MFA in AWS CLI.

Note: IAM users in the AWS Console unknowingly use temporary credentials i.e. after signing in using the username, password (which are long-term credentials) and MFA code, the console generates temporary credentials on behalf of the user in the background with the key "MultiFactorAuthPresent" set to "true". These temporary credentials are then used to make all the requests to AWS while you are using the console.

We can verify the above information using a simple fact that we are logged out of the console automatically after 12 hours. This is because it was using temporary credentials which got expired.

The question now comes up is that if the key "MultiFactorAuthPresent" is not present in the requests made using AWS CLI (which is using long term credentials), then how can we enforce MFA for CLI. Any thoughts on that? Let's discuss that next...

MFA for AWS CLI (or SDK or API)

As the "MultiFactorAuthPresent" key is not present, AWS cannot perform any check for this key. Hence, the control is now shifted to our hands. But how can we control access to our AWS resources. Any guesses???

Yes, that's right our own IAM policies. These can be used to enforce MFA for the requests coming from AWS CLI. Instead of checking the value of the key "MultiFactorAuthPresent", we will check if this key is actually present in the request or not. If not, that means the user is using long term credentials which are not MFA authenticated. Based on that evaluation we can then allow or deny access to the AWS services.

The following example IAM policy can be attached to your IAM users, which will enforce users to use MFA to access any AWS services:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "BlockMostAccessUnlessSignedInWithMFA",
            "Effect": "Deny",
            "NotAction": [
                "iam:CreateVirtualMFADevice",
                "iam:DeleteVirtualMFADevice",
                "iam:ListVirtualMFADevices",
                "iam:EnableMFADevice",
                "iam:ResyncMFADevice",
                "iam:ListAccountAliases",
                "iam:ListUsers",
                "iam:ListSSHPublicKeys",
                "iam:ListAccessKeys",
                "iam:ListServiceSpecificCredentials",
                "iam:ListMFADevices",
                "iam:GetAccountSummary",
                "sts:GetSessionToken"
            ],
            "Resource": "*",
            "Condition": {
                "BoolIfExists": {
                    "aws:MultiFactorAuthPresent": "false"
                }
            }
        }
    ]
}

The "BoolIfExists" condition operator in the above policy plays the main role here. It checks if the "MultiFactorAuthPresent" key is present in the request.

• If the "MultiFactorAuthPresent" key is not present, IfExists evaluates the condition element as true. So, based on the policy every action except the one's mentioned in the "NotAction" element is denied. The allowed actions above provide the user with minimum permission to configure a MFA device for itself and to get temporary credentials which are MFA authenticated.
• If the "MultiFactorAuthPresent" key is present, the condition is further evaluated to check if it's value is true or false. In case the value is "true", the permissions are granted to access the AWS resources based on other attached IAM policies. If "false", the user then only has minimum permissions to configure a MFA device for itself and to get temporary credentials which are MFA authenticated.

Hence, applying the above policy to our "MFA-User" has now added the additional layer of security for programmatic access too i.e. while using CLI/SDK/API you must now use MFA authenticated temporary credentials to access any AWS resource.

What's next 🤔

The only detail now left is that how can we make our requests coming from AWS CLI/SDK/API MFA authenticated. We will discuss that in the next post i.e. how can we use our long term credentials to generate MFA authenticated temporary credentials to access resources using CLI. We will also take a look at a script to automate this task, as getting MFA credentials manually after they get expire can be a bit tiring.

👋 Enjoyed the article? Reach out to me anytime in the comments below or on Twitter for any further discussion or feedback.