In this lecture, you will learn the basics of identity and access management in Google Cloud. I will also cover some best practices on how to apply IAM to a GCP project. 

When it comes to security, you typically do not want every employee to have the same level of access to every resource. For example, you probably want your system administrators to be able to create and delete virtual machines. However, your developers should probably stick to using the existing ones. Your developers *will* edit access to your code repository, but not your testers. Each role requires a different set of permissions. When running your workloads in the cloud, you need a way to effectively manage access to all your resources.

Google Cloud IAM (which stands for Identity and Access Management) is a managed service used to enforce security for your GCP resources. Cloud IAM offers a single dashboard where you can view the different identities and the associated access levels. IAM also presents a consistent interface that applies to many GCP services: including Compute Engine, App Engine, Kubernetes Engine, and Cloud Storage. You do not have to maintain separate access control mechanisms for each individual service.

In order to provide the most flexibility, GCP resources are organized into a hierarchy. With IAM, any policies applied at a higher level will automatically propagate down as well. So a policy applied at the organization level will also affect the underlying folders, projects, and resources. If you want to limit a policy to the project level, you can easily do that. And, in some cases, you can also apply policies directly to a specific resource. This makes it easy to create project, department, or company-wide protections. While also giving you the flexibility to override or extend them in certain cases.

At the very top, is the organization level. This is where you can apply policies to make them apply to the entire company. 

The next level down is folders. Having this level is actually optional. But the most common structure is to have a separate folder for each department in your organization. You can also add subfolders to represent different teams or projects as well.

Under folders is the project level. All of your resources must be assigned to a project. A project is used to group related cloud resources together. They are also used to isolate groups of resources for security and billing purposes. Projects are commonly used to represent team projects or even individual applications. IAM policies directly applied to one project do not affect the resources in another.

For example, a user can be granted full access to the resources in Project A, but have limited or no access to the resources in Project B. This is a good way to prevent one team from affecting the resources used by another team (either intentionally or inadvertently). For fine-grained control, you can also apply IAM policies on individual resources themselves (such as cloud storage buckets or Kubernetes containers). 

These security controls are all built around the core principle of “least privilege”. The main idea is to limit the permissions of your users and applications to be as small as possible. Ideally, you give each piece just enough power to do its job, and no more. 

By using Cloud IAM, you can enforce strong platform security and be certain that only authorized users are accessing your resources.