Welcome back. In this lesson we'll cover authorization as well as identity and access management. Since we're talking about authentication and authorization we'll start with talking about how to get a user authenticated and then once they are authenticated, how do we make sure they only access the things that they're allowed to.

And then, let's jump into talking about a special type of account which is the server-to-server communication mechanism called Service Accounts. Okay, let's dive into getting users authenticated. Imagine you're in charge of managing the Google Cloud Platform for your company. You've just signed up and you need to get people access to the system.

You've probably noticed that in the console you can invite users that have a Google account. Now, this is perfect, it manages a couple of users. You can add the user, set up their roles and then you're on to other things. However, let's imagine that you have two hundred users. So, sending two hundred requests via the user's personal gmail account is not going to be the best option here.

So, this is where using G Suite, which was formerly called Google Apps for Work, will be ideal. It has session activity tracking, security alerts, suspicious activity detection and more. And, this will allow you to manage all of the users in one place. However, if you have two hundred users then, you probably already have an LDAP server which is why Google provides a tool called GCDS, which stands for Google Cloud Directory Sync, and it's a one way sync that allows you to sync users from your existing LDAP server to G Suite.

And, this allows you to sync users pretty easily. Again, it's one way syncing, so changing something in G Suite isn't going to change in your existing directory. It'll also allow you to apply roles to the mapping of things like users and groups. It works by running as a utility in your environment. Okay so, things are starting to shape up.

You don't need to manually import two hundred users and you'll be able to continue managing your users via your existing LDAP server, which is awesome. Remember your initial task was to get your users access to the services inside of the Google Cloud Platform that they need. And, with G Suite and the directory sync, you've done that, however we haven't talked about single sign on just yet.

Importing users is great and with single sign on it's even better. If you have your own authentication system you can use SAML for single sign on. The configuration is simple. You fill out three URLs, you upload your certificate and Google will do the rest. The user name is the only assertion that's used which makes it a pretty lightweight and easy to use setup.

Okay, now you're done. Your task was to get users set up with accounts inside of the Google Cloud Platform and with the use of G Suite, GCDS to sync from your LDAP server to Google and with single sign on with SAML, you have an authentication setup based on your existing infrastructure. Now, once we have users we need to be able to make sure that we can lock things down so that they only access the things they're allowed to.

And, for that we can use Identity and Access Management, which we typically abbreviate IAM. IAM allows you to have two types of roles. There's Primitive Roles and Predefined Roles. Primitive roles are project based roles and there's only a handful. We have owner, editor and viewer. And, using primitive roles you can set fairly simple project based permissions.

Owners can add and remove users from a project and they can basically do just about anything they want with a specific project. Editors are a bit more restricted. They can deploy applications, modify code and configure services and things like this. They have a lot of power so anyone with an editor role is basically what we would consider an admin.

The viewer role, as the name suggests, is a bit more restricted than the editor. It's just a view only access into the console. Now, these primitive roles can be great for small teams, however in our example earlier, we had a two hundred employee company and these roles are either going to be too restrictive or too permissive.

So, that's what Predefined Roles solve. They allow us much more granular roles. The Predefined Roles are a collection of common permissions related to a specific resource. As an example, the instance admin role allows a user to administer the compute engine instance and it's basically a combination of permissions for get, list, delete, start, stop, et cetera.

So, there are a lot of predefined roles that are geared towards common tasks like this. So, using these granular roles it'll make sure that users only have access to what they need. The Google Cloud Platform has a resource hierarchy and it starts with an organization and then it goes down to the project level, and then the resources that are inside of that project.

And, this hierarchy impacts permissions. For example, if you set the user as an editor for a project and you have them set as a view only role for something like logs, then the editor role at the parent level takes priority and they're going to be an editor for the logs. So, it's best practice to start with the least amount of permissions for a given user and increase it at the granular level.

Also, you're going to want to use groups whenever you can. It simplifies policy changes. Along the same lines, make sure you control who can make policy changes and you'll probably want to audit any changes. Alright, so we've talked about getting users into the system and authorizing them which is great, however sometimes you need to have an application running under a specific set of credentials and that's what we use service accounts for.

Service accounts authenticate applications running on your virtual machine instances to other Google Cloud Platform services. As an example, if you have an application that uses Cloud Storage, it first needs to authenticate to the Cloud Storage API. If you have a service account that has permissions to read and write files using the Google Cloud Storage API, then you could use that account in your application code to read and write files on Cloud Storage and doing it this way you don't need to pass credentials around.

There are three types of service accounts available to compute engine instances. We have user managed service accounts, built-in service accounts and the Google API service accounts. The user managed accounts allow you to create your own service accounts and then set the roles that you want it to have and this is going to allow you to break down the service accounts based on the very granular roles that you need.

The built-in accounts are Google created. There's one for compute engine and there's one for app engine. The compute engine default service account is created on a per project basis and it's going to have its own unique email address for each project. And, it's the default service account for new instances.

And, these built-in service accounts, by default, have editor permissions. However, you can change that if you want to and even use the curated roles if you need. Okay, and the one final type is the Google API service account. You may have noticed that this doesn't show up in the list of other service accounts and that's to prevent people from editing the permissions and breaking functionality for things such as auto scaling.

This is also an editor role by default and while you could change it, you probably shouldn't. Service accounts work by using encryption keys and the built-in service accounts will have their keys automatically managed by Google which means that Google will rotate the keys as a security measure, however, you can also do it manually should you choose to.

Okay, if you're going to use the service accounts that you created then you can use the IAM permissions to set just the roles you want. However, if you are going to use the default service account as an instances service account then, you may want to limit the accounts access with scopes. Access scopes are a way to determine what APIs the service account can interact with and more specifically, which actions it can execute for a given API.

Let's check it out in the console. If we start to create a new instance and then we scroll down to the service account we can see the options for access scopes and if we select this option here to set the scopes for each API you can see that we have a list of several different services that we have enabled for this project.

And, each has the ability to edit the options. Here's what you need to remember. Whatever scopes that we set here aren't going to be changeable unless we recreate the instance. Okay so, service accounts allow us to interact with the Google APIs from our code and run under whatever permissions this service account has.

And, this is a great way to avoid hard coding credentials in our application. Alright, let's wrap up here. In our next lesson we're going to be talking about Disk Snapshots. So, if you're ready to keep learning then let's dive in with our next lesson.