GCP 101: Identity and Access Management (IAM)

Introduction to ACL & RBAC

Access Control Lists (ACLs) are a traditional method of managing access to resources. An ACL is a list of permissions attached to an object, defining who can access that object and what actions they can perform. For example, an ACL for a file might grant read access to User A and write access to User B. ACLs work on a per-object basis and can become cumbersome to manage in large environments.

Example: In a file system, an ACL could be set up as follows:

• User A: read, write
• User B: read
• User C: write

While, Role-Based Access Control (RBAC) is a more advanced access control method that simplifies permission management by assigning permissions to roles rather than individual users. Roles represent a set of permissions, and users are assigned roles according to their responsibilities. For example, a "Database Administrator" role might include permissions to create, modify, and delete databases. RBAC makes it easier to manage access control in large organizations by reducing the complexity of permission assignments.

Example: In an organization, RBAC could be set up as follows:

• Database Administrator role: create, modify, delete databases
• Network Administrator role: create, modify, delete networks
• User A: assigned Database Administrator role
• User B: assigned Network Administrator role

Resource Hierarchy in GCP

Google Cloud Platform organizes resources in a hierarchical structure, consisting of:

• Organization: The top-level container that represents your company or organization. For example, 8grams.tech.
• Folders: Logical containers that group projects based on department, team, or other criteria. For example, folders for "Marketing" and "Engineering".
• Projects: A collection of resources and services related to a specific application or service. For example, a project for a web application named "WebAppCRM"
• Resources: Individual services and components, such as Compute Engine instances, storage buckets, and databases. For example, a VM instance named "web-server."

Example: A sample GCP resource hierarchy for a company "8grams.tech" could be structured as follows:

• Organization: 8grams.tech
• Folder: Marketing
• Project: WebAppCRM
• Resource: VM instance "web-server-crm"
• Folder: Engineering
• Project: WebAppCore
• Resource: VM instance "web-server-core"

Identity and Access Management (IAM) in GCP

Google Cloud Platform's Identity and Access Management (IAM) service provides a centralized and unified way to manage access control for your GCP resources. IAM enables you to define who (identity) can perform what actions (permissions) on which resources. Using IAM, you can grant or revoke access to resources based on roles, simplifying access management across your organization.

Permissions and Roles

In GCP IAM, permissions are the basic building blocks that determine what actions a user can perform on a specific resource. Permissions follow the format service.resource.verb, such as storage.buckets.create for creating a storage bucket.

Roles in IAM are collections of permissions. When you grant a role to a user, the user receives all permissions associated with that role. GCP provides predefined roles like Editor or Viewer for common use cases, and you can also create custom roles tailored to your organization's needs.

Example: A sample IAM setup in GCP could include the following roles and permissions:

• Role: Storage Admin
• Permissions: storage.buckets.create, storage.buckets.delete, storage.objects.create
• Role: VM Admin
• Permissions: compute.instances.create, compute.instances.delete, compute.instances.stop

In this example, you can assign the Storage Admin role to users who need to manage storage resources and the VM Admin role to users responsible for managing virtual machines.

Built-in Roles and Custom Roles

In Google Cloud Platform (GCP), roles are collections of permissions that determine what actions a user can perform on a specific resource. GCP offers two types of roles: built-in roles and custom roles. Understanding the differences between these roles can help you make more informed decisions about access control in your GCP environment.

Built-in Roles
Built-in roles, also known as predefined roles, are roles provided by Google Cloud to cover common use cases and scenarios. These roles have a fixed set of permissions that are managed by Google and are updated as new features and services are introduced. Some examples of built-in roles include:

1. Owner: A user with this role has complete access to all GCP resources and services, including the ability to manage roles and permissions for other users.
2. Editor: This role allows a user to create, modify, and delete resources but does not grant the ability to manage roles and permissions for other users.
3. Viewer: A user with this role can view and inspect resources but cannot create, modify, or delete them.

Built-in roles are designed to simplify access control management in GCP, as they cover a wide range of common tasks and scenarios. However, there may be cases where the permissions granted by a built-in role are either too permissive or not permissive enough for your specific use case.

Custom Roles
Custom roles are roles that you create and manage within your GCP organization or project to suit your unique access control requirements. With custom roles, you can define a specific set of permissions tailored to your organization's needs. Custom roles are particularly useful when built-in roles do not provide the exact combination of permissions required for a particular task or user.

For example, you might want to create a custom role that grants a user the ability to start and stop Compute Engine instances but not create or delete them. To create this custom role, you would define the role with the compute.instances.start and compute.instances.stop permissions.

When deciding between built-in roles and custom roles, consider the following factors:

1. Complexity: Built-in roles are simpler to manage and maintain, as they are predefined and updated by Google. Custom roles, on the other hand, require manual management and updates.
2. Flexibility: Custom roles offer more flexibility, as they allow you to define a precise set of permissions tailored to your organization's needs. Built-in roles, while convenient, may not always provide the exact level of access control you require.
3. Security: Following the principle of least privilege is essential for maintaining a secure environment. Custom roles enable you to grant users the minimum permissions necessary for their tasks, reducing the risk of unauthorized access or accidental actions.

In summary, built-in roles in GCP are predefined roles that cover common use cases and scenarios, while custom roles allow you to create and manage roles with a specific set of permissions tailored to your organization's needs. Both built-in and custom roles have their advantages and limitations. Choosing the appropriate role type for your use case depends on your requirements for simplicity, flexibility, and security.

Units of Identity

There are three primary types of identities in GCP IAM:

• Google Accounts: Personal user accounts associated with a Google email address, like Gmail or Google Workspace.
• Service Accounts: Special accounts that represent applications, services, or resources within your GCP projects. Service accounts are used to grant permissions to non-human entities like applications, APIs, or virtual machines.
• Google Groups: Collections of Google Accounts that can be used to manage access control for multiple users at once.

Example: In a GCP project, you might have the following identities:

• User A: Google Account anton@8grams.tech
• User B: Google Account ridho@8grams.tech
• App Service Account: Service account app@8grams.iam.gserviceaccount.com
• Developers Group: Google Group containing User A and User B

Service Account

Service accounts are unique accounts that represent applications or services running on GCP. They are used to authenticate your application to other Google Cloud services without using user credentials. Service accounts have their own set of roles and permissions, allowing you to control access to resources on a per-application basis. You should use service accounts when:

• Your application needs to access GCP resources.
• You want to authenticate API calls between services within GCP.
• You need to separate the permissions of your application from those of your users.

Service accounts differ from other accounts in that they are not associated with a specific user and are used for programmatic access to GCP resources.

Example: In a GCP project, a service account named app@8grams.iam.gserviceaccount.com could be granted the "Storage Admin" role to allow the application it represents to manage storage resources.

Using Service Account in Applications

Connecting a service account to an application is crucial for securely accessing GCP services, such as Google Cloud Storage (GCS), from your application. The process ensures that your application can authenticate itself to the GCP service using the service account and the appropriate permissions, without requiring a personal user account.

The concept behind this process involves creating a service account, associating it with the necessary permissions or roles, and then using a JSON key file to authenticate the application with the service account. This JSON key file contains essential information about the service account, such as the client email, private key, and project ID, which the application uses to authenticate itself to GCP services.

When your application needs to access GCP services, it uses a library, such as the Google Cloud Client Libraries, to interact with the service's API. The library then uses the JSON key file to authenticate your application as the service account, allowing your application to perform actions based on the permissions granted to the service account.

By connecting a service account to your application, you can maintain granular control over access to GCP services and resources. Additionally, service accounts enable you to manage and secure access to resources for non-human entities like applications or services, ensuring that your application follows the principle of least privilege.

Analogy

In a company, every employee receives an ID card with specific information, such as their name, employee number, and access permissions (i.e., which rooms or floors they can access). This ID card helps to identify the employee and grants them access to certain areas based on their role.

Similarly, a service account is like an ID card for an application. The JSON key file contains specific information (such as client_email, private_key, and project_id) that helps identify the service account and grants the application access to certain GCP services based on the roles and permissions assigned to the service account.

When an employee wants to access a restricted area, they need to use their ID card to authenticate themselves at the entrance (e.g., by swiping the card or scanning a barcode). Once their access rights are verified, they can enter the restricted area.

In the same way, when an application needs to access a GCP service, it uses the JSON key file (like an ID card) to authenticate itself with the service's API. The GCP service verifies the access rights of the service account before granting the application access to the requested resources.

{
  "type": "service_account",
  "project_id": "your-project-id",
  "private_key_id": "a1b2c3d4e5f6g7h8i9j0",
  "private_key": "-----BEGIN PRIVATE KEY-----\nEXAMPLE_PRIVATE_KEY\n-----END PRIVATE KEY-----\n",
  "client_email": "your-service-account@your-project-id.iam.gserviceaccount.com",
  "client_id": "123456789012345678901",
  "auth_uri": "https://accounts.google.com/o/oauth2/auth",
  "token_uri": "https://oauth2.googleapis.com/token",
  "auth_provider_x509_cert_url": "https://www.googleapis.com/oauth2/v1/certs",
  "client_x509_cert_url": "https://www.googleapis.com/robot/v1/metadata/x509/your-service-account%40your-project-id.iam.gserviceaccount.com"
}

Here's a breakdown of each property in the JSON key file:

1. type: Specifies the type of credential in the key file. For a service account, the value is always "service_account".
2. project_id: The unique identifier for the Google Cloud project associated with the service account. This is used to identify the project when making API requests.
3. private_key_id: A unique identifier for the private key in the key file. It helps to identify the specific key when multiple keys are associated with a service account.
4. private_key: The private key in PKCS#8 format, which is used to sign requests on behalf of the service account. This key should be kept secure and never shared publicly.
5. client_email: The email address associated with the service account. This email is used as the identity when making requests to Google Cloud APIs.
6. client_id: A unique identifier for the service account, used by Google APIs to identify the account.
7. auth_uri: The URI for the OAuth 2.0 authentication endpoint, which is used to obtain an access token for the service account.
8. token_uri: The URI for the OAuth 2.0 token endpoint, which is used to exchange a JSON Web Token (JWT) for an access token.
9. auth_provider_x509_cert_url: The URL where the x509 certificates for the authentication provider (Google) can be found. These certificates are used to verify the authenticity of tokens issued by Google.
10. client_x509_cert_url: The URL where the x509 certificate for the service account can be found. This certificate may be used by some services to verify the authenticity of the service account.

These properties in the JSON key file are used by the Google Cloud Client Libraries or other SDKs to authenticate your application with Google Cloud services and access the resources associated with the service account.

Importance of IAM and Best Practices

IAM is crucial in GCP because it helps you manage access to your resources securely and efficiently. To make the most of IAM and maintain a secure environment, consider the following best practices and common mistakes:

Best Practices

• Grant least privilege: Assign the minimum permissions necessary for users to perform their tasks. This reduces the risk of unauthorized access or accidental actions.
• Use predefined roles when possible: GCP provides a wide range of predefined roles that cover common use cases. Using these roles can simplify your IAM setup and make it easier to manage.
• Regularly review and update IAM policies: Periodically review your IAM policies to ensure they align with your organization's needs and security requirements. Update policies as necessary to maintain a secure environment.

Common Mistakes

• Overly permissive access: Granting users more permissions than necessary can lead to security risks and unauthorized access. Follow the principle of least privilege to minimize potential vulnerabilities.
• Not updating IAM policies: Failing to regularly review and update IAM policies can result in outdated policies that no longer align with your organization's needs, potentially leading to security risks or unauthorized access.
• Using personal user accounts for applications: Using personal user accounts for applications can lead to security vulnerabilities and make it difficult to manage access control. Instead, use service accounts to represent applications or services running on GCP.
• Not monitoring IAM activities: Failing to monitor and audit IAM activities can make it difficult to detect unauthorized access, maintain compliance, and troubleshoot issues. Use Cloud Logging and Cloud Audit Logs to keep track of IAM-related activities.

In this article, we discussed the fundamental concepts of Identity and Access Management (IAM) in Google Cloud Platform (GCP). We explored the differences between Access Control Lists (ACLs) and Role-Based Access Control (RBAC), the GCP resource hierarchy, and the core components of IAM, such as permissions, roles, and units of identity.

By understanding these IAM concepts and following best practices, you can effectively manage access to your GCP resources and ensure a secure and efficient environment for your applications and users.

About 8grams

We are a small DevOps Consulting Firm that has a mission to empower businesses with modern DevOps practices and technologies, enabling them to achieve digital transformation, improve efficiency, and drive growth.

Ready to transform your IT Operations and Software Development processes? Let's join forces and create innovative solutions that drive your business forward.

Subscribe to our newsletter for cutting-edge DevOps practices, tips, and insights delivered straight to your inbox!