In this lesson, you are going to get a practical demonstration on how to use Cloud IAM.

You will notice that for this demo, I am using the “Daniel-Sandbox” project under the “CloudAcademy.com” organization. So first off, to access the IAM dashboard, you can use the navigation menu. Just click on “IAM & Admin”. Or you could also search for “IAM & Admin” in the search bar like this.

Now on the left-hand side, you will see several menu items including “IAM”, “Service Accounts”, and “Roles”. Let's look at the IAM page first. Here you can see the project principals and roles. The principal list contains all the principals (or accounts) that currently have access to this project. Basically, this is mostly going to be a list of users. This particular entry represents my account. You can use this page to create or delete accounts. So if I wanted to give access to another person, I can add them here.

The role list shows the roles that are assigned to accounts. Basically, roles are groups of permissions. So here if I expand this “Owners” entry, you can see that my user account is currently assigned the owner role. Roles define what an account is allowed to do.

So, the basic idea is that you create accounts under “principals” and then you can grant sets of permissions to those accounts by assigning one or more “roles”. The owner role means I can pretty much do whatever I want. I can add, delete, change or access almost anything. An owner role is great for starting out because it allows you to build whatever you want without restrictions. However, you do not want every user to be an “owner”. That would violate the principle of least privilege. Instead, users should use smaller roles with far more limited permissions. Not everyone needs to be able to change everything.

I am currently only using a couple of roles in this project, but there are many more available to choose from. You can get the full list by clicking on “Roles” in the side menu here. Currently, I have over 900 to choose from.

While some roles have a lot of permissions (like owner), most roles have only a small handful. In fact, most roles are specific to a particular service. For example, if I filter for “App Engine”, you can see that there are several roles specifically for working with App Engine. If a user was only assigned this “App Engine Code Viewer”, then they will only be able to “view App Engine app status and deployed source code”. That’s it. Basically, it’s a “look but not touch” rule. They won’t be able to create, delete or modify App Engine applications. Also, they won’t be able access any of the other services as well. By default, a user has no permissions. In order to do anything, you need to be granted permissions via roles. So as you can see, roles can be used to provide very large or very small sets of permissions to each user.

If you look here, you can see the permissions associated with this role. Each of these permissions is extremely specific. For example, this permission called “resourcemanager.projects.list” gives the user the ability to get a list of all projects. Without this permission, you wouldn’t be able to pick a project when logging in, since you couldn’t know which projects exist. This other permission “resourcemanager.projects.get” allows you to get more information about a specific project. 

Each role is comprised of many different permissions. And the reason you assign roles to principals instead of directly assigning permissions is because to do anything useful you need many different permissions. It would be a lot of extra work to have to assign each permission individually. So instead, you have roles which provide common groups of permissions. And then assign one or more roles to your principals.

You can use the Google default roles listed here, or you can also create your own custom roles as well. Roles allow you to assign hundreds or thousands of permissions, quickly and accurately.

So now that you understand the theory behind principals and roles, it’s time to give you a practical example. I am going to add a new user and assign it a few roles. To add a new user, click on “IAM” in the side menu and then click on the “Add” button here. The form is pretty simple. First, you need to enter the individual’s email addresses. And then you can pick the roles you wish to assign. 

So first, I am going to select the “Basic Viewer” role. This will provide read-only access to all the resources in this project. So this new user will at least be able to look at everything. Now I also want this user to be able to make some changes to App Engine. So I can add another role by clicking here. Now for this role, I will select “App Engine Creator”. This will allow this user to be able to create new App Engine applications. And once I click “save”, the user will be created and assigned the selected roles. 

And there you go. I have created a new user account. Now, an email will be sent to the “testuser1” email address and it will include instructions for how to log in and access the project. 

Now, this process works great for adding one user at a time. But what if you need to add hundreds or thousands of users? Using this technique would be extremely tedious. Luckily, there is a way to add many users at once. The trick here is to use Google Groups. A Google Group allows you to assign many different email addresses to a group email address. And you can use that group email address to create accounts for all the associated users. Let me show you how to do that.

So I'll bring up Google Groups and you can take a look at the groups that I have already set up. For this demo, I have created a group called “IAM Demo Group”. Now I just have a single user assigned to the group, but you could add as many as you want. And I can now use this group email address and to create a new account on the IAM page. 

Instead of creating a single account, this will actually create separate accounts for each user in the group. And any roles I pick here will be assigned to every account in the group as well. You might make a Google Group for all your developers, and then another group for all your testers, and a third group for your security team. Each member of the group will have the exact same permissions, so you wouldn’t want to create a single group with all employees in it.

Speaking of roles, it is helpful to know that they are categorized into three types: Basic, Predefined, and Custom. Basic roles provide large sets of permissions. The “owner” role is a good example. Assigning the “owner” role gives full access to all resources in a project. There are other basic roles as well including “viewer” (which allows you to view the current state of your resources, but not change them) and “editor” (which allows you to create and edit resources but does not include things such as modifying billing or adding new users).

Now, in addition to “basic” roles, there are also “predefined” roles. Predefined roles are much smaller sets of permissions. For example, “App Engine Code Viewer” is an example of a predefined role. Predefined roles allow you to assign granular sets of permissions to your users. While it might seem easier at first to just give everyone Editor or Owner level access, remember that would allow anyone to change anything. Do you really want a tester to be able to break production? Using predefined roles instead of basic roles is a security best practice.

The third type is the custom role. A custom role allows you to pick the exact permissions you want to assign to a user. You can combine several different predefined roles into a new role, or create a completely unique role from scratch. Let me show you how to do that.

First, click on “Roles” from the side menu, you can then click on “create role”. Let's call this custom role “IAM Demo Role”. You can also add a description if you want. And then you need to specify a unique ID for this role. I will call this “ca_iam_demo_role”. 

Next, you need to select a launch stage. This setting is mostly informational. It allows you to keep track of whether a new role has been sufficiently tested and is ready for widespread use. Normally you would start out in “Alpha”. After some initial testing, you could update the launch phase to “Beta” to signify that the role could be used for more extensive tests. Once you are finally certain that the role is ready for general use, you should then set the stage to “General Availability”. You also can set the launch stage to “Disabled” which means that granting this role to an account will have no effect. So I am going to follow best practices and set this to “Alpha”.

Finally, I can add permissions to the role. I just need to click on the “Add Permissions” button here. And now I get the entire list of all permissions. You can see that there are quite a few available. It looks like I have almost 5000. Because there are so many, Google has provided this filter. You can use it to list out the permissions associated with any existing roles. So let’s say I am interested in adding “Compute” Engine-related permissions. I can search for “Compute” and then select “Compute Viewer”. And this will list out the permissions assigned to that role. From here, I can then select the specific ones I want to add to my new custom role. I can search for other roles and grab permissions from there as well. Or I can directly pick permissions from the main list.

Once I am done, I just have to click on the “Create” button to confirm. Now, this new custom role will be added to my total list of roles, and I can assign it to a new or existing user. So let me add the role to my test user account. And there we go.

At this point, you should understand the difference between principals and roles. You also should know how to create a user, create a role, and assign roles to users.