The course is part of these learning pathsSee 4 more
To help you get the most out of the security tools offered in Google Cloud, this Course covers how to properly manage IAM, service accounts, and audit logs.
- How you can manage identity and access management in GCP
- Learn about service accounts, what they mean, and how you can manage them
- Audit logs and how to review them
This Course is intended for cloud administrators. If you are a cloud security practitioner or are involved in any sort of development with GCP, you will also benefit from taking this Course.
- Completion of Google Cloud Platform Fundamentals course on Cloud Academy or practical working experience with GCP infrastructure
- Basic proficiency with command-line tools and Linux operating system environments
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.
Daniel began his career as a Software Engineer, focusing mostly on web and mobile development. After twenty years of dealing with insufficient training and fragmented documentation, he decided to use his extensive experience to help the next generation of engineers.
Daniel has spent his most recent years designing and running technical classes for both Amazon and Microsoft. Today at Cloud Academy, he is working on building out an extensive Google Cloud training library.
When he isn’t working or tinkering in his home lab, Daniel enjoys BBQing, target shooting, and watching classic movies.