WEBVTT 00:00.710 --> 00:04.220 -In this lecture, we will take a look at identity and 00:04.220 --> 00:06.390 access management in AWS. 00:08.240 --> 00:11.840 In the previous demo, we saw how to set up an AWS account. 00:12.830 --> 00:15.980 To sign up, we use an email address and a password. 00:17.330 --> 00:20.430 After completing the sign-up process, we can now log into 00:20.440 --> 00:23.800 the AWS management console using the same credentials. 00:25.500 --> 00:29.520 This email address that was used to sign up to the AWS account is 00:29.540 --> 00:31.470 also known as the root account. 00:31.760 --> 00:34.130 It has complete administrative privileges. 00:35.190 --> 00:39.540 You can manage any service within AWS using the root account, but this 00:39.540 --> 00:41.260 is not the recommended approach. 00:42.610 --> 00:46.580 This user account can be compared to the root user in Linux and admin 00:46.590 --> 00:50.300 user in Windows, which have complete administrative privileges to carry 00:50.300 --> 00:52.250 out any task in the operating system. 00:53.320 --> 00:57.070 Just like the root or admin user, you should not rely on the root 00:57.070 --> 01:00.290 account as your daily driver to operate your AWS account. 01:01.330 --> 01:05.450 When your AWS account is just set up, this is the only account you can use 01:05.450 --> 01:07.310 to sign into the management console. 01:08.700 --> 01:12.690 However, using the root account, we can create new users and assign 01:12.690 --> 01:14.270 them appropriate privileges. 01:15.480 --> 01:18.470 That should be the only purpose of using the root account. 01:19.080 --> 01:22.340 Once these users have been created, lock away the root account 01:22.340 --> 01:26.340 credentials securely and do not use it unless it's absolutely necessary. 01:27.070 --> 01:29.950 To start off, let us create a few new users called 01:29.970 --> 01:32.560 Lucy, Max, Abdul, and Lee. 01:33.990 --> 01:38.260 When we create users in AWS, there are two types of access that we can 01:38.270 --> 01:43.790 configure; access to the management console and programmatic access. 01:44.780 --> 01:47.710 To access the management console, a user should have a 01:47.710 --> 01:49.420 valid username and a password. 01:50.470 --> 01:53.950 The programmatic access is used to interact programmatically by 01:53.950 --> 01:57.100 using command-line interfaces such as the terminal on Linux 01:57.100 --> 01:59.380 and Mac or PowerShell in Windows. 02:01.150 --> 02:05.500 To do this, we create an access key ID and a secret access key, which 02:05.500 --> 02:09.150 need to be configured on the CLI before we can start making use of 02:09.150 --> 02:11.160 the terminal to connect to AWS. 02:12.430 --> 02:15.110 The programmatic access keys cannot be used to log 02:15.120 --> 02:16.440 into the management console. 02:17.800 --> 02:20.560 We will see how to use these in a demonstration video 02:20.590 --> 02:21.700 that follows the lecture. 02:23.070 --> 02:26.850 Now let us see how to assign permissions to these users. 02:27.740 --> 02:31.590 As a standard, when a user is just created, AWS assigns least 02:31.590 --> 02:33.180 privilege permission to the user. 02:34.340 --> 02:39.060 What a user can or cannot do in AWS is decided by the permissions that 02:39.070 --> 02:41.520 are defined within an IAM policy. 02:42.690 --> 02:46.330 For example, let us assume that Lucy is the technical lead for 02:46.340 --> 02:50.000 a project that will be deployed in AWS, which is the reason why 02:50.000 --> 02:51.890 the AWS account was created. 02:52.940 --> 02:57.370 She needs to have admin access to all services and resources in AWS. 02:58.680 --> 03:02.630 To do this, we can add an IAM policy called administrator 03:02.640 --> 03:04.390 access to her user account. 03:05.400 --> 03:08.370 This policy, along with several others, are managed 03:08.370 --> 03:12.330 by AWS and are available to use when creating a user. 03:13.380 --> 03:16.310 An IAM policy is defined in adjacent format. 03:17.420 --> 03:21.690 If we inspect the adjacent document of this policy from the AWS console, 03:22.170 --> 03:25.390 we can see that it's a simple adjacent document that defines the 03:25.400 --> 03:27.090 permissions granted by the policy. 03:28.160 --> 03:31.700 Under the policy statement, we can see the resources that are applicable 03:31.700 --> 03:36.040 to the policy, the action that can be carried out on those resources, 03:36.170 --> 03:37.680 and the effect of the policy. 03:38.920 --> 03:42.360 In this example, the resource and action have a value of 03:42.380 --> 03:46.520 star, which means all resources in AWS and all actions. 03:47.420 --> 03:51.130 The effect field has a value of allow, which effectively means 03:51.330 --> 03:56.640 allow all actions on all resources in AWS, which is why this policy is 03:56.640 --> 03:58.540 known as the administrative policy. 04:00.090 --> 04:03.510 Once this policy is attached to Lucy's user account, she 04:03.510 --> 04:07.190 has complete access to all the resources in the AWS account. 04:08.570 --> 04:11.970 As mentioned previously, the administrator access policy 04:12.000 --> 04:13.990 is an AWS managed policy. 04:14.920 --> 04:17.770 There are several of these provided by AWS that are 04:17.770 --> 04:20.820 designed to provide permissions for many common use cases. 04:21.960 --> 04:27.410 Once a use case is assigning by job function, as we just saw Lucy 04:27.420 --> 04:30.490 being the technical lead and the owner of the account has been 04:30.500 --> 04:34.360 granted admin access by attaching the AWS managed administrator 04:34.370 --> 04:36.030 access policy to her user. 04:37.660 --> 04:41.280 Here are some more AWS-managed policies that are designed for 04:41.290 --> 04:45.700 specific job functions such as a billing policy that will allow 04:45.700 --> 04:49.460 users to view billing information, set up, and authorize payments. 04:50.690 --> 04:53.780 The database administrator policy that allows users 04:53.790 --> 04:56.770 to set up, configure, and maintain databases such as 04:56.770 --> 04:59.860 DynamoDB, RDS, et cetera in AWS. 05:00.690 --> 05:03.240 The network administrator policy grants permissions 05:03.250 --> 05:06.570 to the user to set up and maintain AWS network resources. 05:07.790 --> 05:11.140 For the complete list of policies categorized by job functions, 05:11.250 --> 05:14.040 refer the reference document that follows this lecture. 05:15.270 --> 05:19.870 The other users of this team, Max, Abdul, and Lee are developers who 05:19.870 --> 05:24.490 need access to AWS EC2 and the S3 service to develop their application. 05:25.110 --> 05:29.700 To do this, we can attach two managed policies to each user like this. 05:30.870 --> 05:34.980 Better yet, since Max, Abdul, and Lee are part of the same team and 05:34.980 --> 05:38.590 have the same permission, we can add them to a group called developer. 05:39.750 --> 05:42.040 An IAM group is a collection of users. 05:42.660 --> 05:46.550 This allows us to specify permissions to multiple users at once. 05:47.820 --> 05:50.620 This way, we can directly attach the policies to the 05:50.630 --> 05:54.150 group rather than having to assign them to individual users. 05:55.630 --> 05:59.010 If you want additional permission for any user in a group, we can 05:59.030 --> 06:03.030 also adapt specific policies to an individual user in the group. 06:03.950 --> 06:07.890 Once permission has been attached to the group, the users part of 06:07.890 --> 06:12.730 the developer group have complete access EC2 and S3 service in AWS. 06:14.000 --> 06:16.950 The access provided so far has been for humans. 06:17.690 --> 06:20.860 People who either want to carry out tasks using the management 06:20.870 --> 06:24.400 console or programmatically by making use of the access key 06:24.400 --> 06:26.130 ID and the secret access keys. 06:27.550 --> 06:31.380 Until now, we have seen how to create users, groups, and 06:31.380 --> 06:33.620 attach policies to them in AWS. 06:33.900 --> 06:36.120 But what about other services? 06:37.360 --> 06:42.560 Say an EC2 instance wants to read from and write data to an S3 bucket, 06:43.180 --> 06:44.720 would that work out of the box? 06:45.730 --> 06:47.040 The answer is no. 06:47.990 --> 06:51.980 Just like regular users, resources in AWS also do not 06:51.990 --> 06:55.180 have any permission to interact with other services by default. 06:55.810 --> 06:58.090 They need to be granted access specifically. 06:58.700 --> 07:02.460 However, unlike regular users, we cannot attach an IAM 07:02.460 --> 07:04.090 policy to a service directly. 07:05.110 --> 07:09.230 Instead, in order to allow an EC2 instance to be able to interact with 07:09.270 --> 07:11.830 S3 buckets, we have to create a role. 07:13.230 --> 07:18.770 An IAM role allows us to securely grant access to an AWS service to act 07:18.820 --> 07:21.130 on other AWS services in the account. 07:22.170 --> 07:24.810 In this example, we need to create a role. 07:25.300 --> 07:29.500 Let's call it S3 access role to be applied on the EC2 service. 07:30.630 --> 07:34.010 With the role, we can attach the same IAM policy called 07:34.140 --> 07:37.710 Amazon S3 full access that we use for the developer group. 07:39.090 --> 07:42.430 Once this role is attached to an EC2 instance created in the 07:42.430 --> 07:46.410 account, that instance should have complete access to the S3 service. 07:48.050 --> 07:51.510 Note that there are other ways to give services such as EC2 07:51.750 --> 07:53.360 access to other resources. 07:53.650 --> 07:56.330 One example is configuring programmatic access. 07:57.440 --> 08:00.950 This is however insecure, but we will see how this is done in 08:00.950 --> 08:04.050 the coming lecture when we learn how to programmatically access 08:04.050 --> 08:06.030 AWS using secret access keys. 08:07.410 --> 08:11.690 Finally, IAM roles are not restricted to just providing access from one 08:11.690 --> 08:14.020 service to another service in AWS. 08:15.460 --> 08:19.920 Other users of IAM roles include providing access to an IAM user 08:19.920 --> 08:24.660 belonging to another AWS account, providing access to applications 08:24.670 --> 08:28.630 to interact with services in AWS, and providing access to 08:28.630 --> 08:30.700 users managed outside AWS. 08:31.070 --> 08:33.800 For example, access to users of an organization 08:33.820 --> 08:35.290 that uses Active Directory. 08:36.630 --> 08:40.260 Besides AWS managed policies, we can also create a 08:40.270 --> 08:41.770 custom policy of our own. 08:42.700 --> 08:45.420 This can be done from the AWS console like this. 08:46.950 --> 08:50.910 For example, if you want to create an AWS policy that will 08:50.910 --> 08:54.890 grant permissions for a user to create and delete tags on an EC2 08:54.900 --> 08:56.980 instance, we can do it this way. 08:57.570 --> 09:01.740 Here, we have the adjacent document, which is similar to the administrator 09:01.770 --> 09:06.370 access policy, but in the actions, we have specified permissions to create 09:06.410 --> 09:10.730 and delete tags for EC2 instead of a star, which is all actions. 09:11.750 --> 09:14.230 Once created, the policy will be available to use 09:14.230 --> 09:15.520 within the AWS account.