- Now let's take a look at a demo of creating access keys.
From the Identity and Access Management console,
let's go ahead and click on Users.
And here, because I'm logged in as an admin,
you can see my Richard user is a part of the admin group
and that's who I'm logged in as.
As an admin, I would have permissions
to manage the access keys for other people, right?
So, I could go to the Amy Fowler's user,
and I could go to the Security credentials tab,
scroll down and see that she currently has no access keys.
And again, access keys are a way of configuring things
like your command line interface tools,
the SDKs, third-party tools, and most often,
I would say that we end up doing that locally
so that we can develop against or manage AWS resources
from our local machines.
And we can see that Amy does not have any yet,
and I could create them for her, right?
So, if I clicked on this button
and created those access keys,
then I would have to find a secure way
of transferring those credentials to her.
And in my opinion, I don't really think
that there is such a thing, unless you want to do some kind
of SSH thing and use a FIFO on SSH.
That might be secure,
but I don't think that email is secure,
and because it could leave those credentials exposed
to being used in ways that they weren't intended
or being used maliciously.
And the same is true for just about any messaging app.
If you send that message,
then those credentials are there to be found by someone.
I prefer to allow, or enable, empower, my users,
in this case Amy, to go to AWS
and manage her own access keys herself.
So I'm not going to do it for her.
I'm going to go ahead and log out,
and I'm going to sign in as that user.
I'm going to go here to the Management Console.
I'm going to log in as a.fowler,
and we're going to use the auto-generated password
that we got earlier when we created that user.
I'm going to paste that password.
Now that we've logged in, you can here see it says
"You must change your password to continue"
and that way Amy--
by forcing our users to do that, in this case,
only Amy would know what that password is.
I'm going to go ahead and paste that old one again
and create a new one.
Go ahead and confirm that one.
Now we are, you can see, logged in as Amy.
Of course she has, she should have, being a member
of the everyone group, she would have access to IAM.
Or at least, read-access to IAM.
A lot of these resources here,
Users, Roles, Policies, Groups, this particular user
has the ability to view those things,
but they don't have the ability to modify those
except for their own password and their own access keys.
We could either go here and click on the Amy Fowler user,
or you could go to My Security Credentials.
Either way, Amy could get to those things
in either of those two ways.
The password is fresh, we don't need to worry about that.
Let's go down here to the access keys.
We will go ahead and Create access key,
and that's all we have to do.
Just like that, we've created an access key.
What I do want to point out is this note right here.
"This is the only time that the secret access key
can be viewed or downloaded."
This is sort of like a public private key pair.
The way that these access keys work is that
when the Amazon SDKs or the CLI tools or third party tools
access the API, the meta-data about that particular request
along with the Access key ID and the Secret,
we can go ahead and show the Secret here,
both of these values are used to create a signature,
but only the access key is delivered in the request.
The Secret is kept secret because it's kept locally.
AWS has a copy of the secret, so we create a signature
based on a combination of the access meta-data,
the Access key, and the Secret access key.
We pass along the access key in that request,
and then on Amazon's side,
they essentially replay that signature.
They recreate it from the secret key
they have stored on their side.
If the signature matches, then it's authenticated.
Again, the secret key never actually is delivered anywhere.
It's meant to remain local, and it's meant to remain secret.
Only the access key.
That's why, we could download the CSV file,
or I could copy and paste all of this.
I'm going to go ahead and copy that
and paste that into my text editor.
Then I can close this, and you can see
that now we've created that access key
and we have no ability to see the secret again.
Amazon will not reveal that, even though they have it
and they can use it to verify the signature
and validate the request or authenticate and authorize,
they won't reveal it.
The access key is essentially the public part,
and it's meant to be included in those requests.
It's also not really a big deal that Amazon
is displaying that access key in plain text
because you need both.
You need both the access and the secret.
We keep the secret local and we keep it hidden.
I can use these two keys, now, to configure the CLI tools,
the local SDKS so that when I'm using those tools,
or third-party tools that I might have installed locally,
I can use those to gain access to AWS resources.
We have this one key, and ideally,
you can see here hasn't been used yet,
and ideally, we rotate these keys at least every 90 days.
You can actually see, if we go back to Users,
you can see that this particular key
has not been used but mine is 40 days old.
It's still considered to be a secure key.
After 90 days, you'll start to get a warning.
This check mark will go to an exclamation point,
and then after 365 days, once the key is a year old,
you'll get a red warning.
Let's just go back there to My security credentials,
and if you need to rotate those keys,
then, of course, we have the ability,
we could create two keys.
We could create a second one, copy all of that information,
and then you can see that one was created earlier.
If we wanted to rotate those keys,
then we could start to use the new one
and then come back and delete the old one.
We could either make it inactive,
which means it still exists but it's not able
to be used to authenticate against the API,
or we could just delete it.
I could go ahead and delete the old one.
Here at the console one it wants us to confirm
that yes we do intend to do that.
You'll see that the console does this kind of thing a lot
as a way to help prevent accidental deletion of resources.
We'll go ahead and delete that.
Just like that, we've actually rotated the key.
You've seen that we've created two access keys,
we've deleted one, which is essentially
the process of rotating keys.
That's how we would go about managing access keys.