Sometimes, if a user wants to access AWS resources, they don't have to log into the AWS management console first. Instead, access can be gained from a programmatic perspective for a user who may be using the AWS command-line interface, the CLI, AWS API tools, tools for Windows PowerShell, or Software Development Kits, SDKs. When using any of these methods to access AWS resources, access is not granted via the AWS management console using your username and password. Instead, you're accessing the resources programmatically and so you must authenticate differently. This is also typical of any application that calls upon functions of other services. When an identity is making programmatic calls to your AWS resources, their identity is not prompted to log into the environment first via the console. So, how do you authenticate to AWS resources?

But as we know, this has to happen before being authorized to perform any actions. What credentials are used and how is this authentication achieved? Identities, human or system, requiring this type of programmatic access to the AWS environment use access keys to authenticate. These access keys are composed of two elements: an Access Key ID and a Secret Access Key. The Access Key ID is made up of 20 random uppercase alphanumeric characters such as the one displayed on screen. The Secret Access Key is made up of 40 random upper and lowercase alphanumeric and non-alphanumeric characters as displayed. 

These access keys can be created for any IAM user who requires programmatic authentication. When the keys are created, you are prompted to download and save the details as the Secret Access Key will only be displayed once. And if you lose it, then you'll have to delete the associated Access Key ID and recreate new keys for the user. It's worth noting that it's not possible to retrieve lost access keys as AWS does not retain copies of these for security reasons to prevent them from being compromised. The access keys must then be applied and associated with your system or application that you require for the relevant access. 

For example, if you're using the AWS CLI to access AWS resources, you would first have to instruct the AWS CLI to use these access keys to authenticate and provide authorization for any programmatic API calls. The method of performing this association varies based on the application and system that you're using. However, once this association has taken place, it ensures that all API requests made to AWS are signed with this digital signature. Before we move on, I want to give a quick demo on how we apply access keys to the AWS command-line interface using specific user's credentials. To do this, you need to create a new access key from the security credentials tab of your IAM user and copy the access key ID and secret access key values. 

In the following demonstration, Danny Jessee, our AWS certification specialist will now demonstrate how to use these keys to configure the AWS CLI. Once the CLI is installed, it adds a command called AWS to the system path, which I can then run from a Command Prompt along with various arguments corresponding to different AWS services, such as S3 or EC2. But before I can run any of these commands, I need to perform a one-time action to configure the credentials and default preferences I would like to use with the CLI. And to do that, I'm going to type aws configure, and first it's going to ask me for an AWS access key ID. And so I'm going to use an access key ID from an IAM user who has already been assigned programmatic access credentials. And don't worry, by the time you see this video, I'll have long since deleted these credentials so they won't be valid. 

So, I'll paste the access key ID here and then the secret access key. And now it's asking me for a default region. So, you can add a -- region parameter to your CLI commands to specify the exact region where you want to execute that command. But if you don't supply this parameter, the region you specify here as your default will be used instead. So, I'll enter us-east-1, and finally, it's going to ask me for a default output format. And your choice here will depend on whether you prefer to see output in some sort of more friendly human-readable text format. So, my options are JSON, yaml, yaml-stream, text, or table. But for the purposes of this demo, I'll choose text. And now that I've completed this initial configuration, I can begin to enter CLI commands, and these commands will execute using the credentials I just specified. 

So, to interact with S3, I can run the command aws s3. And to list the buckets of my account, I can type ls. And here you see I have two demo buckets, but let's say I want to add a third. So, now I can enter the command aws s3 then mb for make bucket. And the name of my new bucket will be s3://cloudacademydemobucket3. And since my IAM user has permission to create an S3 bucket, this command will succeed. So, if I run aws s3 ls again, we see my newly created bucket now appears on this list. So, you see how I was able to create an S3 bucket by just running that one simple command. Now imagine if I needed to create 30 or 40 more buckets, it's obviously much simpler and less tedious to leverage something like the AWS CLI to automate this process, rather than having to repeatedly walk through the various screens in the console.

As we discussed earlier when talking about passwords and how it's best practice to change the password after set period of time, the same principle applies when it comes to access keys. By rotating your access keys, you're decreasing the likelihood of your environment or identities being compromised and gaining access to your environment. When rotating these keys, you should follow a simple five-point process to ensure you don't lose access to your resources. Firstly, you should create a second access key. 

Now, that includes both the access key ID and a secret access key for the same user. So, now the user has two access keys associated to them. Next, download these access keys when prompted as you won't get the opportunity to do so again. Then associate these access keys with your application to start using the new access keys depending on what you're using will depend on how you do this. For example, if you're using the AWS CLI, then you would issue the command aws configure to add the new key information as we have just seen in the demonstration. Now, at this point you need to mark the existing access keys as inactive. 

Before deleting this now inactive key, you should test your new access keys and verify that programmatic access is being allowed as expected. And then finally, delete the old access keys. As an authentication method from a programmatic perspective, access keys are a great solution. However, if you are applying access keys to applications running on EC2 instances to gain access to other AWS resources within your environment, then there is a more efficient and secure solution available. And in this instance, you should use IAM Roles.