Identity and Access Management

Google Cloud's Identity and Access Management (IAM) is a framework that allows you to manage who (identity) has what access (role) to which resources. IAM provides the following capabilities:

1. Granular Access Control:

   • IAM enables fine-grained control over access to resources, allowing you to assign specific permissions to different users or groups.

   • Permissions are defined at the level of individual resources, such as projects, services, and individual API methods.

2. IAM Roles:

   • Primitive Roles: These are the basic roles available in GCP:

     • Owner: Full access to all resources.

     • Editor: Read/write access to all resources.

     • Viewer: Read-only access to all resources.

   • Predefined Roles: These roles provide more granular access tailored to specific services. For example:

     • Compute Admin: Full control over Compute Engine resources.

     • Storage Admin: Full control over Cloud Storage resources.

   • Custom Roles: These roles allow you to define a set of permissions tailored to your specific needs, combining multiple permissions into a single role.

3. IAM Policies:

   • Policies bind one or more roles to a list of members. A policy specifies who has what type of access.

   • Policies are defined at different levels of the resource hierarchy: organization, folder, project, and resource levels.

   • Policies are inherited from parent resources, allowing centralized management.

4. IAM Members:

   • Members can be individual users, groups, domains, or service accounts. Common types include:

     • Google Account: A specific user (e.g., [email protected]).

     • Service Account: An account used by applications and virtual machines (VMs) to make authorized API calls.

     • Google Group: A Google group email address (e.g., [email protected]).

     • Cloud Identity Domain: A domain that has been verified to be used by Google Cloud.

5. Service Accounts:

   • Special accounts that represent applications or virtual machines (VMs), rather than individual users.

   • Used to authenticate applications and services to interact with Google Cloud APIs.

   • Can have roles and permissions assigned to them, enabling automated and secure access to resources.

6. IAM Policy Binding:

   • A binding is a relationship between a member and a role. It is part of an IAM policy.

   • Example: Binding the role of roles/storage.objectViewer to a specific user, granting read-only access to Cloud Storage objects.

7. IAM Conditions:

   • Allow you to define conditional access control policies based on attributes of the request, such as the request's time, the resource's state, or the IP address.

   • Enhance security by enforcing access policies based on contextual information.

Example Scenario

Consider a scenario where you have a project with Cloud Storage buckets and Compute Engine instances:

1. Owners: Your admin team has the Owner role, giving them full access to manage resources.

2. Developers: Your dev team has the Editor role, allowing them to create and modify resources.

3. QA Team: The QA team has the Viewer role, providing them read-only access to resources.

4. Service Account: An application running on Compute Engine uses a service account with the role roles/storage.objectViewer to read data from Cloud Storage.