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.
We've talked about APIs previously. Review that content again if your memory is failing you.
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
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:
- This we can see this is the correct user (ARN)
- And this is the tab we're not interested in
Click the the tab highlighted by
Security credentials, and we'll get programmatic access setup in no time. This is what you'll see:
- Here we can see the console login link
- This section makes it clear this is how we access AWS programmatically, which is what we're interested in
- 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:
- You can see a warning here: read it and take it seriously!
- And this is true: AWS will only present this information to you once
- Here we have the access key
- And here we have the secret access key
I'm going to save a copy of my access key locally for demonstration purposes, then delete it. You should do the same thing for security.
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:
And you'll be presented as such:
1 2 3 4 5
You might note see
[****************4HOG] in your output. That's because I've configured the AWS CLI previously, and AWS is, essentially, suggesting I override existing values. You'll either see something similar to this or just
AWS Access Key ID: - either or is fine.
<hidden> in my input to the command. That's because I will delete these credentials later and it's simply best practice to never reveal them to the public, even in a training setting (what if I forget to delete them?)
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.
List the current IAM users we have in our account:
1 2 3 4 5 6 7 8 9 10 11 12 13
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
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.
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:
- Simply click this arrow and follow the prompts
You'll be presented with a warning and some information, like this:
- You can see when the key was last used, which can be useful information
- Confirm you're deleting a key for the right user
- Your AWS account idea, for additional sanity checking
- Now click this "Deactivate" button to disable the key (before deleting it)
- 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.