Programmatic Access#

So far we've done a lot of work in the console via a web browser. That's a very convenient way of interacting with AWS' services, but there is another way (and it's actually how the console is talking to AWS for us, too.)

AWS offers an Application Programming Interface (API). This is sort of like a console, but it's designed for communication between computers instead of humans. The API that AWS provides allows us to do anything we want inside of the AWS provided we have permissions to it.

What we're going to talk about here is enabling access to the AWS API from an IAM perspective.

A thought experiment#

Let's try something first. A little thought experiment.

We've got IAM users that we've created previously - how would you connect to the AWS API? We've connected to the Console via the browser, but how do you connect to the API? I'll give you a hint: you can't use the same credentials you use to access the console, and you can't use the console whatsoever.

The API is a different "endpoint". The AWS console is accessed via console.aws.amazon.com but the API is accessed differently, depending on the AWS service you want to access and where. For example, EC2 in Sydney, Australia is accessed via ec2.ap-southeast-2.amazonaws.com.

So right now, you cannot access the API because we don't have the credentials to do so.

Updating our user#

So we have our user, iam-admin, and we want to access the AWS API via that user. What do we do? Let's login to the AWS console and access this user's IAM details. You should see this:

1. This we can see this is the correct user (ARN)
2. And this is the tab we're not interested in

Click the the tab highlighted by 2, Security credentials, and we'll get programmatic access setup in no time. This is what you'll see:

1. Here we can see the console login link
2. This section makes it clear this is how we access AWS programmatically, which is what we're interested in
3. And this is where we create a new "access key" (it's actually a pair of keys)

Let's go ahead and create an access key (pair) and then we'll use the AWS commandline tools to make calls to the API.

Create an access key (pair)#

Click the button "Create access key" and in an instant, you'll get a popup window:

1. You can see a warning here: read it and take it seriously!
2. And this is true: AWS will only present this information to you once
3. Here we have the access key
4. And here we have the secret access key

Click "Close" (after saving the details) and let's now access the AWS API.

We're going to be using the AWS CLI to access the API. It's doing all of the HTTPS and JSON heavy lifting for us, so all we need to do now is configure the AWS CLI to use the new acess key we just created.

Open a terminal or console and type this:

1

aws configure

And you'll be presented as such:

1
2
3
4
5

$ aws configure
AWS Access Key ID [****************4HOG]: AKIA5LGB5KPYO<hidden>
AWS Secret Access Key [****************ku4H]: XGyjIVrQqVI15k<hidden>
Default region name [ap-southeast-2]:
Default output format [None]:

When prompted, I've provided the information as requested. We got these two peices of information from the IAM UI earlier: the access key and the secret key.

I've also provided the default region as ap-southeast-2 which means when you're running commands via the CLI, all the services you access will, by default, be in that region. So if I create an EC2 instance, and I don't specify the region, it will default to ap-southeast-2 (Sydney). You can set the region, overriding the default, on a per-command basis.

Now let's check out a few commands.

IAM Users#

List the current IAM users we have in our account:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

$ aws iam list-users
{
    "Users": [
        {
            "Path": "/",
            "UserName": "iam-admin",
            "UserId": "<hidden>",
            "Arn": "arn:aws:iam::<hidden>:user/iam-admin",
            "CreateDate": "2022-07-26T01:03:06+00:00",
            "PasswordLastUsed": "2022-08-07T08:17:59+00:00"
        }
    ]
}

And just like that, we made a "programmatic" request (sort of) to the AWS API using the access key we just created. In return, we got some JSON back from the API. This document describes the IAM users that are present in our access.

Let's try something else. Why don't we see how many EC2 instances you have running?

1
2
3

$ aws ec2 describe-instances

An error occurred (UnauthorizedOperation) when calling the DescribeInstances operation: You are not authorized to perform this operation.

Well look at that: access denied. Remember when we only gave iam-admin permission to manage IAM for us, so that user does not have permission to access the EC2 service - via the web console or the API.

I wanted you to see that IAM permissions are global and universal, regardless of how you access AWS.

Clean up#

Now delete that access key! If you keep it around and it's somehow leaked, then it can be used to create a new IAM user that has more privileges than iam-admin, which means bad news for you.

Head over to the IAM users page, select iam-admin, then select the "Security credentials" tab, and finally delete the access key:

1. Simply click this arrow and follow the prompts

You'll be presented with a warning and some information, like this:

1. You can see when the key was last used, which can be useful information
2. Confirm you're deleting a key for the right user
3. Your AWS account idea, for additional sanity checking
4. Now click this "Deactivate" button to disable the key (before deleting it)
5. Finally, type the access key here to confirm you understand what you're doing

Then click "Delete". Now that access key has been deleted and can no longer be used.

Now you know how to setup programmatic access to an IAM user. Future sections of this course as well as project work will expand on the idea more.