In this video, I will introduce Cloud Identity and Access Management, and how to use it to control and secure your cloud environment. When you build an application on your on-premises infrastructure, you're responsible for the entire stack. When you move an application to Google Cloud platform, Google handles many of the lower layers of security. This concept of shared responsibility is called the shared responsibility model, and clearly defines which responsibilities are handled by the cloud provider, Google, and which responsibilities are handled by the customer. Because of its scale, Google can deliver a higher level of operational efficiency and security at these layers than most of its customers could afford to do on their own. As shown in the slide, the upper layer of the responsibility model remains the customers responsibility. Google provides tools such as IAM to help customers implement the policies they chose at these layers. So what is identity access management? It is a way of identifying who can do what on which resource. The who can be a person, group, or application. The what refers to specific privilege or action. And the resource could be any GCP service. For example, I can give you the privilege or role of compute viewer. This provides you with read-only access to get and list compute engine resources, without being able to read the data stored on them. The who part of an IAM policy can be a Google account, a Google group, a service account, or a cloud identity domain. We will explore all of these identities later in the module. The can do what part of an IAM policy is defined by a role. There are three kinds of roles in Cloud IAM, let's explore each in turn. The primitive roles are broad. You apply them to a GCP project, and they affect all resources in that project, from virtual machines to firewall rules, databases, and logs. These are the owner, editor, and viewer roles. If you are a viewer on a given resource, you can examine it, but not change its state. If you're an editor, you can do everything a viewer can do, plus change its state. And if you're an owner, you can do everything an editor can do, plus manage roles and permissions on the resource. The owner role on a project lets you do one more thing too, you can set up billing. Often, companies want someone to be able to control the billing for a project, without the right to change resources in the project. And that's why you can grant someone the billing administrator role. But be careful, if you have several people working together on a project that contains sensitive data, primitive roles are probably too coarse a tool. Fortunately, GCP IAM provides finer grain types of roles. GCP services offer their own set of predefined roles, and they're defined where these roles can be applied. For example, later in this course, we'll talk more about Compute Engine, which offers virtual machines as a service. Compute Engine offers a set of predefined roles, and you can apply them to Compute Engine resources in a given project, a given folder, or the entire organization. Another example, consider Cloud Bigtable, which is a manage database service. Cloud Bigtable offers roles that can apply across an entire organization, to a particular project, or even an individual Bigtable database instance. Compute Engine's InstanceAdmin role lets whoever has it perform a certain set of actions on a virtual machine. What set of actions? Those listed here. Listing them, reading and changing their configuration, and starting and stopping them. And which virtual machines? Well, that depends where the role is applied. In this example, all the users of a certain Google group have the role, and they have it on all the virtual machines in project_a.