Google IAM and Admin
Author: Ronald Fung
Creation Date: 8 June 2023
Next Modified Date: 8 June 2024
A. Introduction
IAM lets you grant granular access to specific Google Cloud resources and helps prevent access to other resources. IAM lets you adopt the security principle of least privilege, which states that nobody should have more permissions than they actually need.
How IAM works
With IAM, you manage access control by defining who (identity) has what access (role) for which resource. For example, Compute Engine virtual machine instances, Google Kubernetes Engine (GKE) clusters, and Cloud Storage buckets are all Google Cloud resources. The organizations, folders, and projects that you use to organize your resources are also resources.
In IAM, permission to access a resource isn’t granted directly to the end user. Instead, permissions are grouped into roles, and roles are granted to authenticated principals. (In the past, IAM often referred to principals as members. Some APIs still use this term.)
An allow policy, also known as an IAM policy, defines and enforces what roles are granted to which principals. Each allow policy is attached to a resource. When an authenticated principal attempts to access a resource, IAM checks the resource’s allow policy to determine whether the action is permitted.
Note
: You can also use deny policies to prevent principals from using specific IAM permissions. For more information, see Deny policies.
The following diagram illustrates permission management in IAM.
An allow policy with two role bindings. The role bindings associate specific members with specific roles.
This model for access management has three main parts:
Principal
. A principal can be a Google Account (for end users), a service account (for applications and compute workloads), a Google group, or a Google Workspace account or Cloud Identity domain that can access a resource. Each principal has its own identifier, which is typically an email address.Role
. A role is a collection of permissions. Permissions determine what operations are allowed on a resource. When you grant a role to a principal, you grant all the permissions that the role contains.Policy
. The allow policy is a collection of role bindings that bind one or more principals to individual roles. When you want to define who (principal) has what type of access (role) on a resource, you create an allow policy and attach it to the resource.
In the preceding diagram, for example, the allow policy binds principals, such as user@example.com
, to roles, such as the App Engine Admin role (roles/appengine.appAdmin
). If the allow policy is attached to a project, the principals gain the specified roles within the project.
B. How is it used at Seagen
Seagen can use Google IAM (Identity and Access Management) and Admin to manage access to Google Cloud resources and services. Here are some steps to get started with Google IAM and Admin:
Create a Google Cloud account: Seagen can create a Google Cloud account in the Google Cloud Console. This will give them access to IAM and Admin features.
Create a project: Seagen can create a new project in the Google Cloud Console. The project will be associated with a Google Cloud billing account and can be used to manage access to Google Cloud resources and services.
Add users: Seagen can add users to the Google Cloud project by creating Google accounts or using existing G Suite accounts. They can then assign roles and permissions to the users using IAM.
Create custom roles: Seagen can create custom roles in IAM to provide more granular access control over Google Cloud resources and services. They can define the permissions and actions that are allowed for each role.
Set up resource hierarchy: Seagen can set up a resource hierarchy in the Google Cloud Console to organize their resources and services. They can use IAM to control access to each level of the hierarchy.
Monitor activity: Seagen can monitor activity in the Google Cloud Console using Admin features. They can view audit logs and usage reports to track user activity and resource usage.
Overall, by using Google IAM and Admin, Seagen can manage access to Google Cloud resources and services effectively and efficiently. By carefully assigning roles and permissions, creating custom roles, and monitoring activity, Seagen can ensure that their Google Cloud resources and services are secure and accessible to authorized users only.
C. Features
Google IAM (Identity and Access Management) and Admin provide a range of features that allow users to manage access to Google Cloud resources and services effectively and securely. Some of the key features of Google IAM and Admin include:
Role-based access control: Google IAM provides role-based access control to manage access to Google Cloud resources and services. Users can assign roles to users, groups, and service accounts based on their responsibilities.
Custom roles: Google IAM provides the ability to create custom roles to provide granular access control over Google Cloud resources and services. Users can define the specific permissions and actions that are allowed for each role.
Service accounts: Google IAM provides service accounts to allow applications and services to authenticate and access Google Cloud resources and services securely.
Resource hierarchy: Google IAM supports a resource hierarchy to organize Google Cloud resources and services. Users can use IAM to control access to each level of the hierarchy.
Audit logs: Google Admin provides audit logs to track user activity and changes to Google Cloud resources and services. Users can view audit logs in the Google Cloud Console or export them to external systems.
Usage reports: Google Admin provides usage reports to track resource usage and costs for Google Cloud services. Users can view usage reports in the Google Cloud Console or export them to external systems.
Overall, Google IAM and Admin provide a powerful set of features to manage access to Google Cloud resources and services effectively and securely. By carefully assigning roles and permissions, creating custom roles, and monitoring activity, users can ensure that their Google Cloud resources and services are secure and accessible to authorized users only.
D. Where Implemented
E. How it is tested
Testing Google IAM and Admin involves ensuring that access to Google Cloud resources and services is managed effectively and securely. Here are some steps to test Google IAM and Admin:
Create a test environment: Create a test environment that mimics the production environment as closely as possible. This includes creating test data, configuring Google Cloud services, and setting up test infrastructure.
Set up IAM: Set up IAM in the test environment and configure IAM settings such as roles, permissions, and service accounts. Ensure that the IAM policy is associated with the correct Google Cloud project.
Assign roles: Assign roles to users, groups, and service accounts in the test environment based on their responsibilities. Verify that the users, groups, and service accounts can access the appropriate Google Cloud resources and services.
Create custom roles: Create custom roles in IAM to provide more granular access control over Google Cloud resources and services. Define the permissions and actions that are allowed for each custom role.
Test resource hierarchy: Test the resource hierarchy by setting up a hierarchy in the test environment and using IAM to control access to each level of the hierarchy. Verify that users can access the appropriate resources and services based on their roles and permissions.
Monitor activity: Monitor activity in the test environment using Admin features. View audit logs and usage reports to track user activity and resource usage.
Overall, testing Google IAM and Admin involves creating a test environment, setting up IAM, assigning roles, creating custom roles, testing the resource hierarchy, and monitoring activity. By thoroughly testing Google IAM and Admin, users can ensure that access to Google Cloud resources and services is managed effectively and securely.
F. 2023 Roadmap
????
G. 2024 Roadmap
????
H. Known Issues
While Google IAM (Identity and Access Management) and Admin are generally reliable and stable, there are a few known issues that users may encounter. Some of the known issues are:
Role permission errors: Users may encounter errors when assigning roles and permissions in IAM. This can occur if the user does not have the correct permissions or if the role is not defined correctly. Users should carefully review their roles and permissions to ensure that they are defined correctly.
Custom role errors: Users may encounter errors when creating custom roles in IAM. This can occur if the user does not define the correct permissions or if the custom role conflicts with another role. Users should carefully review their custom roles to ensure that they are defined correctly.
Service account errors: Users may encounter errors when using service accounts in IAM. This can occur if the service account does not have the correct permissions or if the authentication credentials are invalid. Users should carefully review their service accounts to ensure that they are defined correctly.
Resource hierarchy errors: Users may encounter errors when setting up a resource hierarchy in IAM. This can occur if the user does not have the correct permissions or if the hierarchy is not defined correctly. Users should carefully review their resource hierarchy to ensure that it is defined correctly.
Audit log errors: Users may encounter errors when viewing audit logs in Admin. This can occur if the user does not have the correct permissions or if the audit logs are not available. Users should carefully review their audit logs to ensure that they are available and accessible.
Overall, while these issues may impact some users, Google IAM and Admin remain powerful and flexible tools for managing access to Google Cloud resources and services. By carefully monitoring their IAM policies, roles, and permissions, and reviewing their usage reports and audit logs, users can ensure that their Google Cloud resources and services are secure and accessible to authorized users only.
[x] Reviewed by Enterprise Architecture
[x] Reviewed by Application Development
[x] Reviewed by Data Architecture