AWS – Account setup

Setting up an AWS account

Go to https://aws.amazon.com/

Click the Create Account button on the right hand side

Click verify email address

Email will be sent to that address which will contain a 6 digit verification code.

Enter that code back into the AWS sign in page

Enter a Root user password (Chrome picked one for me). Click Continue (step 1 of 5)

Select how you plan to use AWS – Business or Personal (I’ll chose Personal as I’m using it for my own projects)

Add the contact details and click the terms of AWS Customer Agreement

Click Agree and Continue (step 2 of 5)

Next is billing information

Selec the Payment method type. Can use a debit or credit card or a Bank Account (I’m going to skip this bit). Once they have been given you need to give a mobile phone number to allow AWS to send authentication numbers to a mobile device.

And that’s it.

AWS account setup! Now we need to tidy things up a bit as we have just bought access to an unlimited amount of computing (yeah!!) which you have to pay for (boo!!). There are two things we have to do

Secure that root user details – it’s the achilles heel of the site as it’s all controlling so you don’t want to be flashing it around the place.
Spending controls – some way of alerting you when you have spent a certain amount of money. AWS have your payment details so will take the month on a schedule basis.

Log into AWS. You will get the probably get the AWS Management Console with Console Home at the top. This is a dashboard of set activities. Mine has Cost and usage first up and then applications.

Where am I?

So we’ve created an account on AWS – we are on the Cloud baby! But where are we on the cloud? Are we in a single location in the Internet or are we god-like and omni-present? Well the answer from AWS is a bit of both. AWS has two sort of areas – the AWS network and the customers network. When you create an account this is on the AWS network as it means you can setup your computer solutions near your customers in what AWS call regions which largely breakdown into continents (although the US and Canada get there own). This means that you can set up computing in any region but you will be billed centrally. The other thing to know is that AWS has global services that are found in all regions and region specific services. Overtime the services may become global but just bear in mind that there could be regions specific services like IAM Identity Center which we’ll get to later.

Protecting Root (I’m root!) – Multifactor Authentication (MFA)

To find services either click the services icon in the top left or search for the service you are after. We need to do some security and that means searching for IAM – Identity And Management or something. It’s a security thing and if you try and remember everything in AWS you’ll go mad (it’s Identify (verification) and Access (validation) Management by the way..

IAM Dashboard – AWS makes two recommendations for the root account: 1) root user has multi-factor authentication (MFA). This means the root account has two forms of authentication- a password and a unique code/token so that someone can’t login without the separated factor.

There are a couple of difference options for the MFA. Choose one that suits you. Remember that we are not going to be using the root account to be working on the account so make sure that whatever the method it could be used if necessary as getting locked out of the root account would be bad.

The other thing that IAM checks for is that the root account doesn’t have any active access keys. There are none by default so this should be all good. But wait – what is an active access key and why shouldn’t the root account have one?

Access key are long-term credentials for an IAM user. They allow a user to sign programmatic requests like a person would have a special stamp to prove that it is a legitimate request. The access keys come in two forms – a public and secret one. A user can only have two access keys. They are very powerful so be very careful storing and using them. Ok – back to the security setup.

With root account secure (store the password and authenticator details/equipment somewhere safe) then we need to create a user with admin access but not super user (root) access.

To do this go back to IAM and in the Access Management menu on the left hand side elect Users. Click Create User. There is a 3 step process. First give the user a user name like compsortia_user. Second set the permissions for the user. This can be done by adding the user to a group, copy permissions of another user or attach policies directly. let’s select add user to a group.

You can select a group if one has already been made (it has not in this case) so we click create group. Name the group and then add the permission policies available (there are 1050 as the last count). Let’s call it Administrator and attach the AdministratorAccess policy. The AdministratorAccess policy has all the services and the access level (Full) for this account. Attach the user to the group and save. A admin user has been created!

Great. But how does this user log in and start doing work? Well for a person you need to select Provide user access to the AWS Management Console. This provides the option of a password. However, users in AWS take on two types: a human being and a computer account. Human’s will interact with AWS mainly through the management console which a person logs into just like the root account that we protected earlier. The root account is an Identity and Access Management (IAM as a reminder). But AWS doesn’t recommend IAM users to log into the Management console. Instead it recommends that human users use the Identity Center. By selecting the Identity Center the option of a password disappears.

What is the Identity Center?

Firstly IAM Identity Center is not new. AWS used to call it AWS Single Sign-On (SSO) which is a clue as to how it works (the symbol is a red box with a Cloud and then a key). Singe sign-on is exactly what it says it is – a single sign-on to multiple accounts. An example would be signing into your Windows account also signs you into your email. So for this to happen we need to have multiple platforms with IAM and these need to some how agree that credentials between them can be used.

But I’m only going to need to log into my AWS account. I don’t have multiple accounts. Well, that may be true to start with and if you are using AWS to simply learn and play in AWS then you probably won’t need the SSO or the Identity Center. However at some point you might want to use AWS in a professional organisation and it gets more complicated. Even if you decided to stick to just playing with AWS then you may have multiple AWS accounts – one for developing things, one for testing things, and one used for production that is all working.

OK. Blah blah blah. Let’s get started on how to use this thing.

Let’s use an example. Compsortia needs someone to log into the management console and see how we are getting on with billing and expenses. We’ve found a person to help who is helpfully called William Billing.

We create the user William Billing in IAM. We want Bill to access the management console so we click this option. When we do AWS recommends that we use Identity Center to manage all our human users. So we select User type: Specify a user in Identity Center – Recommend. Then click next then Manage in Identity Center – oh boy we are going to get William an account! A new tab pops up …

Enable IAM Identity Center – OK – click Enable – now we are getting that account …

Not quite. To enable IAM Identity Center you need to create an organisation instance of the identity centre.

AWS needs to confirm 2 details

Does this AWS account contain resources? Yes – it will contain William
Is this the right AWS Region? Yes – Europe (London)

Click enable and that enables the Identity Center and it creates an AWS Organisation. AWS Organisation that allows users to be managed across multiple accounts. We only have one account for now so let’s stick to just the Identity Center for now.

We create a user just like we would have in IAM.

We create a user called William.B and fill in all the details (we don’t use full names in usernames for security).

Next we add the user to a group. Annoyingly you need to have created the group first which I did called Billing.

Add the account to the group and hey presto – a user has been added. William will be emailed a link to verify the account. The link is valid for 7 days. When William clicks the link he will be sent to the AWS account asking William to change his password. Then it will ask him for his username that he’d like and then to log in again. Next and finally the multi-factor authentication is setup. Then William is all good to look at those bills we have to deal with.

Well… not quite. We have setup the account and we did click the box for accessing the management console but there is another thing we need to do. Give permissions to William to access the console. When William logs in he’ll be greeted with screen saying the all powerful admins will need to grant access.

Granting permissions for things are different in IAM Identity Center than straight IAM. In IAM we are grant permission to groups of computer users who do specific computer stuff. In Identity Center we are dealing with people who can be brilliant, dumb and at times evil so we control there access differently.

There are a couple of steps that we need to do to get William up and running. The first thing is to create a permission set for an account. This is easy as you select permission set and then choose the Predefined permission set (don’t worry about the custom permission set for today). This kicks off a three step workflow to set up the permission set.

There are about 12 predefined ones that align to jobs that people do on the account and thankfully one of these is billing. Choose that. The next page is details about the permission set you can change. Just keep everything as default for now. The third step confirms everything which creates the permission set. Note – you can’t have two permission sets with the same name.

OK. We now have a permission set. Now William can get to work

Summary.

Create a group e.g. Billing (can’t create a group called Administrator as this is not a role for the Identity Center).

Create a permission set (Billing). Chose the predefined permission set that fits the group you are creating.

This assigns permissions to that group and all the users in the group.

Create users. Send confirmation email. Perfect.

So we now need an account that has nearly admin access to my account so I don’t have to log in as root (remember this gets locked away).

First we go to Identity Center and ….

Create a permission set – predefined – DataScientist
Create a group – called DataScientist_Group (don’t call the group the same thing as the permission set as it will get confusing)
Assign the group to the account
Assign the permission set to the group (this assigns the group to the account with a permission set)
Create a user called Adam Inistrator
Add user to group DataScientist

Adam will get an email which he needs to sign in and set the MFA. Once this is done Adam will be able to log into the identity centre and through the dedicated console address

create an account called Adam Inistrator in Identity Center (what a name

Create

Create a user in IAM identity Center e.g William.B, William B

Quick thing to remember. I didn’t add any permissions to the Billing group so the group means nothing.

Create an account – this creates the root account

Once an account