To use AWS services you must, of course, have an AWS account. The AWS account is how we authenticate ourselves to AWS and is how AWS charges us for services.
AWS has two kinds of accounts that we can use, as follows:
- The root account is what’s created when we sign up for an AWS account. The root account has full access to AWS services.
- An IAM user account is a less privileged account you can create within your root account. The owner of a root account creates IAM accounts, assigning the scope of permissions to each IAM account.
It is bad form to use the root account directly since the root account has complete access to AWS resources. If the account credentials for your root account were to be leaked to the public, significant damage could be done to your business. If the credentials for an IAM user account were leaked, the damage is limited to the resources controlled by that user account as well as by the privileges assigned to that account. Furthermore, IAM user credentials can be revoked at any time, and then new credentials generated, preventing anyone who is holding the leaked credentials from doing any further damage. Another security measure is to enable multi-factor authentication (MFA) for all accounts.
If you have not already done so, proceed to the AWS website at one of the preceding links and sign up for an account. Remember that the account created that way is your AWS root account.
Our first step is to familiarize ourselves with the AWS Management Console.
1. Finding your way around the AWS account
Because there are so many services on the AWS platform, it can seem like a maze of twisty little passages, all alike. However, with a little orientation, we can find our way around.
First, look at the navigation bar at the top of the window. On the right, there are three dropdowns. The first has your account name and has account-related choices. The second lets you select which AWS region is your default. AWS has divided its infrastructure into regions, which essentially means the area of the world where AWS data centers are located. The third connects you with AWS Support.
On the left is a dropdown marked Services. This shows you the list of all AWS services. Since the Services list is unwieldy, AWS gives you a search box. Simply type in the name of the service, and it will show up. The AWS Management Console home page also has this search box.
While we are finding our way around, let’s record the account number for the root account. We’ll need this information later. In the Account dropdown, select My Account. The account ID is there, along with your account name.
It is recommended to set up MFA on your AWS root account. MFA simply means to authenticate a person in multiple ways. For example, a service might use a code number sent via a text message as a second authentication method, alongside asking for a password. The theory is that the service is more certain of who we are if it verifies both that we’ve entered a correct password and that we’re carrying the same cell phone we had carried on other days.
To set up MFA on your root account, go to the My Security Credentials dashboard.
A link to that dashboard can be found in the AWS Management Console menu bar. This brings you to a page controlling all forms of authentication with AWS. From there, you follow the directions on the AWS website. There are several possible tools for implementing MFA. The simplest tool is to use the Google Authenticator application on your smartphone. Once you set up MFA, every login to the root account will require a code to be entered from the authenticator app.
So far, we have dealt with the online AWS Management Console. Our real goal is to use command-line tools, and to do that, we need the AWS CLI installed and configured on our laptop. Let’s take care of that next.
2. Setting up the AWS CLI using AWS authentication credentials
The AWS CLI tool is a download available through the AWS website. Under the covers, it uses the AWS application programming interface (API), and it also requires that we download and install authentication tokens.
Once you have an account, we can prepare the AWS CLI tool.
Once you have installed the AWS CLI tool on your laptop, we must configure what is known as a profile.
AWS supplies an AWS API that supports a broad range of tools for manipulating the AWS infrastructure. The AWS CLI tools use that API, as do third-party tools such as Terraform. Using the API requires access tokens, so of course, both the AWS CLI and Terraform require those same tokens.
To get the AWS API access tokens, go to the My Security Credentials dashboard and click on the Access Keys tab.
There will be a button marked Create New Access Key. Click on this and you will be shown two security tokens, the Access Key ID and the Secret Access Key. You will be given a chance to download a comma-separated values (CSV) file containing these keys. The CSV file looks like this:
$ cat ~/Downloads/accessKeys.csv
Access key ID,Secret access key
AKIAZKY7BHGBVWEKCU7H,41WctREbazP9fULN1C5CrQ0L92iSO27fiVGJKU2A
You will receive a file that looks like this. These are the security tokens that identify your account. Don’t worry, as no secrets are being leaked in this case. Those particular credentials have been revoked. The good news is that you can revoke these credentials at any time and download new credentials.
Now that we have the credentials file, we can configure an AWS CLI profile.
The aws configure command, as the name implies, takes care of configuring your AWS CLI environment. This asks a series of questions, the first two of which are those keys. The interaction looks like this:
$ aws configure –profile root-user
AWS Access Key ID [****************E3GA]: … ENTER ACCESS KEY
AWS Secret Access Key [****************J9cp]: … ENTER SECRET KEY
Default region name [us-west-2]:
Default output format [json]:
For the first two prompts, paste in the keys you downloaded. The Region name prompt selects the default Amazon AWS data center in which your service will be provisioned. AWS has facilities all around the world, and each locale has a code name such as us-west-2 (located in Oregon). The last prompt asks how you wish the AWS CLI to present information to you.
For the region code, in the AWS console, take a look at the Region dropdown. This shows you the available regions, describing locales, and the region code for each. For the purpose of this project, it is good to use an AWS region located near you. For production deployment, it is best to use the region closest to your audience. It is possible to configure a deployment that works across multiple regions so that you can serve clients in multiple areas, but that implementation is way beyond what we’ll cover in this book.
By using the –profile option, we ensured that this created a named profile. If we had left off that option, we would have instead created a profile named default. For any of the aws commands, the –profile option selects which profile to use. As the name suggests, the default profile is the one used if we leave off the –profile option.
A better choice is to be explicit at all times in which an AWS identity is being used. Some guides suggest to not create a default AWS profile at all, but instead to always use the –profile option to be certain of always using the correct AWS profile.
An easy way to verify that AWS is configured is to run the following commands:
$ aws s3 ls
Unable to locate credentials. You can configure credentials by running “aws configure”.
$ aws s3 ls –profile root-user
$ export AWS_PROFILE=root-user
$ aws s3 ls
The AWS Simple Storage Service (S3) is a cloud file-storage system, and we are running these commands solely to verify the correct installation of the credentials. The ls command lists any files you have stored in S3. We don’t care about the files that may or may not be in an S3 bucket, but whether this executes without error.
The first command shows us that execution with no –profile option, and no default profile, produces an error. If there were a default AWS profile, that would have been used. However, we did not create a default profile, so therefore no profile was available and we got an error. The second shows the same command with an explicitly named profile. The third shows the AWS_PROFILE environment variable being used to name the profile to be deployed.
Using the environment variables supported by the AWS CLI tool, such as AWS_PROFILE, lets us skip using command-line options such as –profile while still being explicit about which profile to use.
As we said earlier, it is important that we interact with AWS via an IAM user, and therefore we must learn how to create an IAM user account. Let’s do that next.
3. Creating an IAM user account, groups, and roles
We could do everything in this chapter using our root account but, as we said, that’s bad form. Instead, it is recommended to create a second user—an IAM user—and give it only the permissions required by that user.
To get to the IAM dashboard, click on Services in the navigation bar, and enter IAM. IAM stands for Identity and Access Management. Also, the My Security Credentials dashboard is part of the IAM service, so we are probably already in the IAM area.
The first task is to create a role. In AWS, roles are used to associate privileges with a user account. You can create roles with extremely limited privileges or an extremely broad range of privileges.
In the IAM dashboard, you’ll find a navigation menu on the left. It has sections for users, groups, roles, and other identity management topics. Click on the Roles choice. Then, in the Roles area, click on Create Role. Perform the following steps:
- Under Type of trusted identity, select Another AWS account. Enter the account ID, which you will have recorded earlier while familiarizing yourself with the AWS account. Then, click on Next.
- On the next page, we select the permissions for this role. For our purpose, select AdministratorAccess, a privilege that grants full access to the AWS account. Then, click on Next.
- On the next page, you can add tags to the role. We don’t need to do this, so click Next.
- On the last page, we give a name to the Enter admin because this role has administrator permissions. Click on Create Role.
You’ll see that the role, admin, is now listed in the Role dashboard. Click on admin and you will be taken to a page where you can customize the role further. On this page, notice the characteristic named Role ARN. Record this Amazon Resource Name (ARN) for future reference.
ARNs are identifiers used within AWS. You can reliably use this ARN in any area of AWS where we can specify a role. ARNs are used with almost every AWS resource.
Next, we have to create an administrator group. In IAM, users are assigned to groups as a way of passing roles and other attributes to a group of IAM user accounts. To do this, perform the following steps:
- In the left-hand navigation menu, click on Group, and then, in the group dashboard, click on Create Group.
- For the group name, enter Administrators.
- Skip the Attach Policy page, click Next Step, and then, on the Review page, simply click Create Group.
- This creates a group with no permissions and directs you back to the group dashboard.
- Click on the Administrators group, and you’ll be taken to the overview Record the ARN for the group.
- Click on Permissions to open that tab, and then click on the Inline policies section header. We will be creating an inline policy, so click on the Click here link.
- Click on Custom Policy, and you’ll be taken to the policy editor.
- For the policy name, enter AssumeAdminRole. Below that is an area where we enter a block of JavaScript Object Notation (JSON) code describing the Once that’s done, click the Apply Policy button.
The policy document to use is as follows:
{
“Version”: “2012-10-17”,
“Statement”: [
{
“Effect”: “Allow”, “Action”: “sts:AssumeRole”,
“Resource”: “arn:aws:iam::ACCOUNT-ID:role/admin”
}
]
}
This describes the policy created for the Administrators group. It gives that group the rights we specified in the admin role earlier. The Resource tag is where we enter the ARN for the admin group that was created earlier. Make sure to put the entire ARN into this field.
Navigate back to the Groups area, and click on Create Group again. We’ll create a group, NotesDeveloper, for use by developers assigned to the Notes project. It will give those user accounts some additional privileges. Perform the following steps:
- Enter NotesDeveloper as the group Then, click Next.
- For the Attach Policy page, there is a long list of policies to consider; for example, AmazonRDSFullAccess, AmazonEC2FullAccess, IAMFullAcce ss, AmazonEC2ContainerRegistryFullAccess, AmazonS3FullAccess, AdministratorAccess, and AmazonElasticFileSystemFullAccess.
- Then, click Next, and if everything looks right on the Review page, click Create Group.
These policies cover the services required to finish this chapter. AWS error messages that stipulate that the user is not privileged enough to access that feature do a good job of telling you the required privilege. If it is a privilege the user needs, then come back to this group and add the privilege.
In the left-hand navigation, click on Users and then on Create User. This starts the steps involved in creating an IAM user, described as follows:
- For the username, enter notes-app, since this user will manage all resources related to the Notes For Access type, click on both Programmatic access and AWS management console access since we will be using both. The first grants the ability to use the AWS CLI tools, while the second covers the AWS console. Then, click on Next.
- For permissions, select Add User to Group and then select both the Administrators and NotesDeveloper This adds the user to the groups you select. Then, click on Next.
- There is nothing more to do, so keep clicking Next until you get to the Review page. If you’re satisfied, click on Create user.
You’ll be taken to a page that declares Success. On this page, AWS makes available access tokens (a.k.a. security credentials) that can be used with this account.
Download these credentials before you do anything else. You can always revoke the credentials and generate new access tokens at any time.
Your newly created user is now listed in the Users section. Click on that entry, because we have a couple of data items to record. The first is obviously the ARN for the user account. The second is a Uniform Resource Locator (URL) you can use to sign in to AWS as this user. For that URL, click on the Security Credentials tab and the sign-in link will be there.
It is recommended to also set up MFA for the IAM account. The My Security Credentials choice in the AWS taskbar gets you to the screen containing the button to set up MFA. Refer back a few pages to our discussion of setting up MFA for the root account.
To test the new user account, sign out and then go to the sign-in URL. Enter the username and password for the account, and then sign in.
Before finishing this section, return to the command line and run the following command:
$ aws configure –profile notes-app
… Fill in configuration
This will create another AWS CLI profile, this time for the notes-app IAM user. Using the AWS CLI, we can list the users in our account, as follows:
$ aws iam list-users –profile root-user
{
“Users”: [ {
“Path”: “/”,
“UserName”: “notes-app”, “UserId”: “AIDARNEXAMPLEYM35LE”,
“Arn”: “arn:aws:iam::USER-ID:user/notes-app”,
“CreateDate”: “2020-03-08T02:19:39+00:00”,
“PasswordLastUsed”: “2020-04-05T15:34:28+00:00”
}
]
}
This is another way to verify that the AWS CLI is correctly installed. This command queries the user information from AWS, and if it executes without error then you’ve configured the CLI correctly.
AWS CLI commands follow a similar structure, where there is a series of sub- commands followed by options. In this case, the sub-commands are aws, iam, and list-users. The AWS website has extensive online documentation for the AWS CLI tool.
3.1. Creating an EC2 key pair
Since we’ll be using EC2 instances in this exercise, we need an EC2 key pair. This is an encrypted certificate that serves the same purpose as the normal Secure Shell (SSH) key we use for passwordless login to a server. In fact, the key-pair file serves the same purpose, allowing passwordless login with SSH to EC2 instances. Perform the following steps:
- Log in to the AWS Management Console and then select the region you’re using.
- Next, navigate to the EC2 dashboard—for example, by entering EC2 in the search box.
- In the navigation sidebar, there is a section labeled Network & Security, containing a link for Key pair.
- Click on that link. In the upper-right corner is a button marked Create key pair. Click on this button, and you will be taken to the following screen:
- Enter the desired name for the key pair. Depending on the SSH client you’re using, use either a pem (used for the ssh command) or a ppk (used for PuTTY) formatted key-pair file.
- Click on Create key pair and you’ll be returned to the dashboard, and the key-pair file will download in your browser.
- After the key-pair file is downloaded, it is required to make it read-only, which you can do by using the following command:
$ chmod 400 /path/to/keypairfile.pem
Substitute here the pathname where your browser downloaded the file.
For now, just make sure this file is correctly stored somewhere. When we deploy EC2 instances, we’ll talk more about how to use it.
We have familiarized ourselves with the AWS Management Console, and created for ourselves an IAM user account. We have proved that we can log in to the console using the sign-in URL. While doing that, we copied down the AWS access credentials for the account.
We have completed the setup of the AWS command-line tools and user accounts. The next step is to set up Terraform.
Source: Herron David (2020), Node.js Web Development: Server-side web development made easy with Node 14 using practical examples, Packt Publishing.