IAM (Identity and Access Management) gives administrators complete power and visibility to manage Google Cloud resources centrally by allowing them to approve who can execute actions on particular resources. IAM offers a unified view into security policy throughout your whole organisation, with built-in auditing to streamline compliance processes, and is ideal for businesses with complicated organisational structures, hundreds of workgroups, and several projects.
This blog explains the details of basic Concepts of Identity and Access management, along with the details of Granting IAM Roles, Managing access to projects, folders, and organizations and Service Accounts.
Without further ado, lets get started.
Granting an IAM role by using the Google Cloud console
Let’s learn how to assign IAM roles to principals at the project level using the Google Cloud console.
Grant an IAM role
A principal should be given the project's Logs Viewer position.
Find the IAM page in the Google Cloud console.
Choose a new project.
Select Person_ add to Grant access.
Type a principal's email address here.
Look for Logs Viewer in the drop-down menu labelled "Select a role," then select it.
Press Save.
Check to see if the IAM page lists the principal and the appropriate role.
You've been successful in giving a principal an IAM position.
Observe the effects of IAM roles
By performing the following, you may confirm that the principal to whom you assigned a role can access the desired Google Cloud console pages:
The principal to whom you delegated the role in the previous step should receive the following URL:
The principal is directed to your project's Logs Explorer page by this URL.
Make sure the principal can view and access the URL.
The principal will get an error message if they attempt to view a separate Google Cloud console page to which they do not have access.
Grant additional roles to the same principal
In addition to their Logs Viewer position, give the principal the Compute Viewer role.
Find the IAM page in the Google Cloud console.
Click Edit principal edit in the row that contains the principal to whom you wish to assign a different role.
Click Add another role in the Edit permissions pane.
Find Compute Viewer in the drop-down option labelled "Select a role," then click it. Press Save.
There is a new IAM role for the principal.
Revoke IAM roles
The following actions will revoke the principal's access to the responsibilities you gave them in the earlier steps:
Click Edit Principal Edit in the row that contains the principal to whom you have granted roles.
Click on the delete icon next to the Logs Viewer options and Compute Viewer roles in the Edit Permissions window.
Press Save.
Let's look into the details of Managing access to projects.
Manage access to projects, folders, and organizations
Access is provided by allowing policies, commonly referred to as IAM policies, in Identity and Access Management (IAM). A resource on Google Cloud has an allow policy linked to it. Every allowed policy has a set of role bindings that link one or more principals, such as users or service accounts, to an IAM role. These role bindings give the principals access to the designated roles on both the resource to which the allowed policy is tied and all of that resource's offspring.
Grant a single role
Do the following to assign a principal to a single role:
Find the IAM page in the Google Cloud console.
Choose a project, folder, or company.
Decide which principal will receive a role:
Find a row containing the principal, click edit Edit principal in that row, and then click add another role to grant the principal a role if they already have other responsibilities on the resource.
Click person, add Grant Access, then type the principal's email address or another identifier to grant the role to a principal who does not already hold it on the resource.
From the drop-down menu, pick the role you want to grant. Choose a role that only has the rights that your principal needs for proper security procedures.
Add a condition to the role.
Press Save.
The role of the resource is given to the principal.
Do the following to assign a principal a role across several projects, folders, or organisations:
Navigate to the Manage resources page in the Google Cloud console.
Choose each resource you want to provide permissions.
Click on the Show info panel if the info panel is not already displayed. Click Permissions after that.
Decide which principal will receive a role:
In order to assign a role to a principal who already has one, locate the principal's row and select modify.
Click Add another role after editing the principle in that row.
Click person Add principal, then input the principal's email address or another identifier to grant a role to a principal who does not already have one.
From the drop-down menu, pick the role you want to grant.
Add a condition to the role.
Press Save.
The chosen role on each of the chosen resources is given to the principal.
Revoke a single role
Do the following to remove one role from a principal:
Find the IAM page in the Google Cloud console.
Choose a project, folder, or company.
Locate the row that contains the principal whose access you wish to revoke. Then, on that row, click edit Edit principal.
For each of the roles, you want to revoke, click on the Delete button and then click Save.
Grant or revoke multiple roles
Use the read-modify-write pattern to edit the resource's allow policy to make extensive access modifications involving the granting and revocation of many roles:
Call getIamPolicy() to view the current allow policy.
Edit the allow a policy to add or remove any principals or role bindings using a text editor or programmatically.
Call setIamPolicy() to update the allow policy.
To alter the allow policy, utilise the Resource Manager client libraries, the REST API, or the gcloud CLI.
Let's dive into the details of service accounts.
Service accounts
An application or computing workload, such as a Compute Engine virtual machine (VM) instance, might use a specific type of account called a service account rather than an individual user. Applications use service accounts to conduct approved API calls on behalf of users who have been delegated domain-wide permissions, the service account itself, or Google Workspace or Cloud Identity users. In order for applications running on a Compute Engine VM to authenticate as the service account, a service account can be linked to the VM. IAM roles that enable the service account to access resources can also be granted. The service account serves as the application's identity, and its responsibilities regulate which resources the program can access.
Preventing creation of service accounts
The constraints/iam.disableServiceAccountCreation organisation policy restriction can be enforced in an organisation, project, or folder to stop new service accounts from being created.
Consider the following restrictions before enforcing this constraint:
Certain Google Cloud services cannot generate default service accounts if this constraint is applied to a project or to all projects within an organisation. Therefore, if the project runs workloads that require impersonating a service account, the project could not have a service account that the workload can use.
To solve this problem, you can make service account impersonation available for all projects. When this feature is enabled, you are able to create service accounts in a centralised project and then connect those service accounts to resources in additional projects.
You must create service accounts in order to use some capabilities, such as workload identity federation.
Consider employing organisation policy constraints to prevent federation from all identity providers if you do not use workload identity federation.
Types of keys for service accounts
A public/private RSA key pair is connected to every service account. The Service Account Credentials API uses this internal key pair to generate temporary service account credentials and then to sign blobs and JSON Web Tokens (JWTs). The Google-managed key pair is what this pair of keys is called. Additionally, you can generate several user-managed key pairs or public/private RSA key pairs and utilise the private key in order to authenticate with Google APIs. The term "service account key" refers to this private key.
Google-managed key pairs
The Service Account Credentials API and other Google Cloud services like App Engine and Compute Engine produce temporary credentials for service accounts using Google-managed key pairs. For a maximum of two weeks, Google-managed key pairs are automatically rotated and utilised for signing. The rotation mechanism is probabilistic; during the course of the key's lifetime, usage of the new key will progressively ramp up and down.
You can never directly access the private key that is part of a key pair that Google manages since it is always stored in escrow. Everybody can check signatures made with the private key by using the public key in a key pair that Google manages. The public key is available in a variety of formats, including:
For a service account, you can establish user-managed key pairs. Then, you can authenticate with Google APIs by using the private key from each key pair. A service account key is the name given to this private key. There are a maximum of 10 service account keys per service account. Google only keeps the visible half of a user-managed key pair.
For a service account, there are several ways to create a user-managed key pair:
To automatically create a user-managed key pair, utilise the IAM API. Google creates a pair of public and private keys, only keeps the public key, and gives you the private key back.
Make your own user-managed key pair, then only upload the public key. The secret key is never visible to Google.
User-controlled keys are incredibly strong credentials that, if improperly managed, might pose a security concern. In an organisation, project, or folder, you can impose the following organisational policy restrictions to restrict the use of user-managed keys:
constraints/iam.disableServiceAccountKeyCreation : Limits the creation of user-managed service account keys by principals.
constraints/iam.disableServiceAccountKeyUpload : Disallows principals from uploading a service account's public key.
Types of service accounts
Let's learn the details of various types of service accounts.
User-managed service accounts
Using the IAM API, the Google Cloud dashboard, or the Google Cloud CLI, you may create user-managed service accounts in your project. You are in charge of controlling and protecting these accounts.
In a project, you can, by default, create up to 100 user-managed service accounts. You can ask for a higher quota by using the Google Cloud console if the current one is insufficient for your needs. This quota does not apply to the default service accounts listed on this page.
You select a name for the service account when you create a user-managed service account in your project. This name appears in the service account's unique email address, which has the following format:
Some Google Cloud services generate user-managed service accounts when you enable or use them, allowing the service to run operations that access other Google Cloud resources. Default service accounts are what these accounts are called.
Your application can use the default service account's credentials to access Google Cloud APIs if running in a Google Cloud environment with one. Alternatively, you can sign in with your user-managed service account.
Google-managed service accounts
In order to function on your behalf, several Google Cloud services require access to your resources. The service needs to be accessed to any Pub/Sub topics that can cause the container to start when, for instance, you use Cloud Run to run a container. For a variety of Google Cloud services, Google generates and administers service accounts to address this demand. They are referred to as Google-managed service accounts. The allow policy for your project, the audit logs, or the IAM page in the Google Cloud dashboard may all contain references to Google-managed service accounts.
On the Service accounts page of the Google Cloud console, Google-managed service accounts are not included.
Service account locations
A project contains each service account. A service account cannot be transferred to another project once it has been created.
Your service accounts can be arranged into projects in one of several ways:
Create service accounts and resources: With this method, setting up service accounts is simple. However, when they are dispersed over numerous projects, it might be challenging to maintain track of your service accounts.
Organize service accounts under distinct projects: This strategy consolidates all of your organization's service accounts into a small number of projects, which may make them simpler to administer. Attaching service accounts to resources in other projects, which enables those resources to utilise the service account as their identity, necessitates further setup.
You often need to enable the API for a resource in both projects when a service account in one project uses a resource in another project. You are required to enable the Cloud SQL API in both my-service-accounts and my-application, for instance, if you already have a service account in the project my-service-accounts and a Cloud SQL instance in the project my-application.
Service account permissions
Service accounts are resources as well as identities.
Since service accounts are identities, you may grant them roles just like you would for any other principal to allow them access to resources in your project. For instance, you can grant the Storage Object Viewer role (roles/storage.objectViewer) to your application's service account so that it can access objects in a Cloud Storage bucket. Service accounts, on the other hand, are resources as well that accept allow policies. By giving additional principals a role on the service account or one of the parent resources of the service account, you can allow them access to the service account. Giving a user the Service Account User role (roles/iam.serviceAccountUser) on a service account, for instance, would allow them to impersonate a service account.
The Service Account User role
At the project level for all your service accounts in the project, or at the service account level, you can grant the Service Account User role (roles/iam.serviceAccountUser).
When a person is given the Service Account User role for a project, they gain access to all the service accounts in the project, including any potential future service accounts.
A user who has been assigned the role of Service Account User for a certain service account has access to only that service account.
The iam.serviceAccounts.actAs permission is one of the privileges available to this role. Therefore, users who have been granted the Service Account User role on a service account can utilise it to access all of the resources that the service account has access to without actually using them. A user who has been granted the Service Account Users role (roles/iam.serviceAccountUser) on a service account, for instance, can use that service account to create a Compute Engine instance if the service account has the Compute Admin role (roles/compute.admin). In this process, the user impersonates the service account and uses its authorised roles and permissions to carry out any actions.
Service accounts represent your service-level security. The security of the service is pre-determined by the individuals who hold the private external keys for the service accounts and who have IAM roles to manage and utilise the service accounts. The following are some top security recommendations:
Audit the service accounts and keys, and allow policies on those service accounts using the IAM API.
Delete your service accounts if they don't require external keys.
Remove people from the applicable allow policy if they are not authorised to administer or use service accounts.
Maintain the least amount of permissions possible for service accounts. Because they are automatically given the Editor (roles/editor) role on the project, utilise default service accounts with caution.
Short-lived service account credentials
Short-lived credentials that let you pretend to be a Google Cloud service account can be made. These credentials may be used to authenticate requests made to non-Google APIs as well as Google Cloud APIs.
These credentials are typically used to temporarily grant access to Google Cloud resources to various projects, organisations, or accounts. For instance, temporary emergency access can be offered in place of giving a caller from outside the system the account's permanent login information. As an alternative, an outside caller can impersonate a defined service account with fewer privileges without the need for the credentials of a service account with higher privileges.
Workload identity federation
You can allow identities to impersonate service accounts from workloads that run on platforms other than Google Cloud, such as Amazon Web Services (AWS) or Microsoft Azure. Instead of requiring a service account key, you can now directly access resources using transient credentials.
Application Default Credentials
Google Cloud Client Libraries use a mechanism called Application Default Credentials to automatically find service account credentials. Application Default Credentials will use a service account key that you specify in an environment variable as the service account key. The service account, which is attached to the resource that is running your code, is used by Application Default Credentials if you do not specify a key.
Let's continue our discussion about Advanced concepts of Identity and Access Management in our next blog.
IAM (Identity and Access Management) gives administrators complete power and visibility to manage Google Cloud resources centrally by allowing them to approve who can execute actions on particular resources.
What is an IAM user?
A resource in IAM with related credentials and permissions is known as an IAM user.
What is the purpose of IAM?
IAM (identity and access management) ensures that the appropriate individuals and job functions within your business have access to the resources they require to perform their duties.
Conclusion
In this article, we have extensively discussed the details of basic Concepts of Identity and Access management, along with the details of Granting IAM Roles, Managing access to projects, folders, and organizations and Service Accounts.
We hope that this blog has helped you enhance your knowledge regarding Basic Concepts of Identity and Access Management, and if you would like to learn more, check out our articles on Google Cloud Certification.
117+ registered 