Identity and Access Management

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:

X.509 certificate: 

Command:

https://www.googleapis.com/service_accounts/v1/metadata/x509/SERVICE_ACCOUNT_EMAIL

Raw format: 

Command:

https://www.googleapis.com/service_accounts/v1/metadata/raw/SERVICE_ACCOUNT_EMAIL

JSON Web Key (JWK): 

Command:

https://www.googleapis.com/service_accounts/v1/jwk/SERVICE_ACCOUNT_EMAIL

User-managed key pairs

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:

service-account-name@project-id.iam.gserviceaccount.com

Default service accounts

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.

Check out this problem - Smallest Distinct Window.

Creating and managing service accounts

By default, each project is allowed a maximum of 100 service accounts that manage resource access. If necessary, you can ask for an increase in your quota.

Creating a service account

An alphanumeric ID, such as my-service-account, must be provided when creating a service account (SA_NAME in the samples below). Lowercase alphanumeric characters and dashes are permitted in the ID, which must be between 6 and 30 characters. A service account's name cannot be changed once it has been created. The email address given during account creation contains the service account name in the format SA_NAME@PROJECT ID.iam.gserviceaccount.com.

Additionally, each service account has an automatically produced, permanent numeric ID. When you create a service account, you also give the following details:

• The service account's optional description is SA_DESCRIPTION.
   
• The service account's friendly name is SA_DISPLAY_NAME.
   
• Your Google Cloud project's ID is PROJECT_ID.
   

You might have to wait for at least 60 seconds after creating a service account before using it. This is a result of read operations being consistent over time; it may take some time for the new service account to become apparent. You might retry the request with exponential backoff if you immediately attempt to read or use a service account and get an error after creating it.

• Navigate to the Create service account page in the Google Cloud dashboard.
   
• Choose a cloud-based project.
   
• To appear on the Google Cloud console, provide the name of a service account.
   
• The Google Cloud dashboard provides a service account ID based on this name. Changing the ID as needed. The ID cannot be modified afterward.
   
• Enter a service account description if desired.
   
• Click Done to complete creating the service account if you do not want to apply access controls at this time.
   
• Click Create and Continue to move on to the following step and create access controls right away.
   
• Optional: Select one or more IAM roles to give the project's service account access.
   
• Click Continue after you're done adding roles.
   
• Add individuals who are capable of impersonating the service account if you choose in the Service account users' role section.
   
• Including people with account management rights in the Service account admins, role section is optional.
   
• To complete creating the service account, click Done.
   

Give the service account one or more roles once you create it so that it can represent you in actions.
Additionally, you often need to activate the APIs for those resources in the project where the service account was established if it wants to access resources in other projects. 

Listing service accounts

You can list your service accounts to audit service accounts and keys or as part of a unique tool for managing service accounts.

• Navigate to the Service accounts page in the Google Cloud console.
   
• Choose a project.
   

All of your user-managed service accounts in the project you chose are listed on the Service accounts page. The page does not include service accounts handled by Google.

Updating a service account

A service account's display name (friendly name) and description are frequently used to record additional information about the service account, such as the account's goal or a contact person.

• Navigate to the Service accounts page in the Google Cloud console.
   
• Choose a project.
   
• To change the name of a service account, click its email address.
   
• Then click Save after entering the new name in the Name box.

Disabling a service account

Similar to removing a service account, disabling a service account prevents applications from using that service account to access Google Cloud services. The Compute Engine service accounts and default App Engine can be disabled to prevent the instances from accessing project resources. A service account that has already been disabled cannot be further disabled.

Disabled service accounts can simply be re-enabled as needed, unlike service accounts that have been deleted. To ensure that no crucial apps are using a service account, we advise disabling it before deleting it.

• Navigate to the Service accounts page in the Google Cloud console.
   
• Choose a project.
   
• You can disable a service account by clicking on its name.
   
• Click Disable service account under Service account status, then click Disable again to finalise the modification.

Enabling a service account

Applications will once again be able to access Google Cloud resources through a service account that has been disabled. Anytime you need to, you can reactivate a disabled service account. Any attempts to enable a service account that is already enabled will be ineffective.

• Navigate to the Service accounts page in the Google Cloud console.
   
• Choose a project.
   
• You can enable a service account by clicking its name.
   
• Click Enable service account under Service account status, and then click Enable again to commit the change.

Deleting a service account

The applications will no longer have access to Google Cloud resources through a service account that has been deleted. The instances will lose access to project resources if the default App Engine and Compute Engine service accounts are deleted. You have to make sure that no important programs are still utilising a service account. We advise disabling a service account before deleting it if you're unsure whether it's being used. If a disabled service account is still in use, it is simple to enable it again. The new service account is viewed as a different identity and does not inherit the roles given to the previous service account if you delete a service account first and then establish a new service account with the same name. In contrast, a service account's identity does not change, and its duties are retained when a service account is deleted and subsequently undeleted.

The role bindings associated with a deactivated service account are automatically wiped from the system after a maximum of 60 days.

• Navigate to the Service accounts page in the Google Cloud console.
   
• Choose a project.
   
• After choosing the service account, you wish to terminate, click Delete.

Undeleting a service account

In some circumstances, you may be able to restore a deleted service account using the undelete command. In most cases, you can recover a deleted service account if it fits the following description:

• Less than 30 days have passed since the service account was deactivated.
   
• IAM permanently deletes the service account after 30 days. Even if you submit a support request, Google Cloud cannot retrieve the service account once it has been permanently deleted.
   
• The removed service account's name does not already belong to any service account.
   
• Take the service account my-service-account@project-id.iam.gserviceaccount.com as an example, which you might have mistakenly deleted. You create a new service account called my-service-account@project-id.iam.gserviceaccount.com since you still require a service account with that name.
   

The permissions of the destroyed service account are not carried over to the new service account. It effectively operates independently of the deleted service account. The new service account had the same name as the deleted service account, so you cannot restore the deleted service account. To solve this problem, delete the new service account before attempting to restore the deleted service account.

You may create a new service account with the same name, revoke all of the roles from the destroyed service account, and then award the same roles to the new service account if you are unable to recover the deleted service account.

Finding a deleted service account's numeric ID

A service account's numeric ID must be provided in order to restore it. A unique 21-digit number, such as 123456789012345678901, serves as the service account's numeric ID. The original and the new service accounts will have distinct numeric IDs; for instance, if you delete a service account and then establish a new account with the same name.

You can obtain the allow policy and locate the numeric ID there if you are aware that binding in an allow policy includes the terminated service account. The numerical ID follows the name of the deleted service account. The removed service account's numeric ID, for instance, in this allowed policy, is 123456789012345678901:

Code: 

{
  "version": 1,
  "etag": "BwUjMhCsNvY=",
  "bindings": [
    {
      "members": [
        "deleted:serviceAccount:my-service-account@project-id.iam.gserviceaccount.com?uid=123456789012345678901"
      ],
      "role": "roles/iam.serviceAccountUser"
    },
  ]
}

Only the names of principals that have been erased are added with numeric IDs.

A different option is to look in your audit logs for the DeleteServiceAccount operation that removed the service account:

• Navigate to the Logs Explorer page in the Google Cloud console.
   
• Enter the following query in the query editor, replacing SERVICE ACCOUNT EMAIL with your service account's email address (for instance, my-service-account@project-id.iam.gserviceaccount.com):

Code:

resource.type="service_account"
resource.labels.email_id="SERVICE_ACCOUNT_EMAIL"
"DeleteServiceAccount"

 

• Click schedule if the service account was deactivated more than an hour ago. Click Apply after choosing a larger duration from the drop-down list than the Last 1 Hour.
   
• Click Run search. The DeleteServiceAccount operations that impacted service accounts with the name you supplied are shown in the Logs Explorer.
   
• One of the following methods will help you locate and note the deleted service account's numeric ID:
  • Find the numerical ID in the Unique ID field of the Log fields pane if the search results only show one instance of the DeleteServiceAccount activity.
     
  • If more than one log appears in the search results, take the following action:
    • Locate the proper log entry. Click the keyboard arrow right expander arrow next to a log entry to find the correct log entry. Examine the log entry's specifics to see if it contains the information about the action you wish to undo. Continue doing this until you locate the proper log entry.
       
    • Find the service account's numerical ID in the appropriate log entry. Expand the protoPayload field of the log item, then look for the resourceName field to find the numerical ID.
       

Everything in the resourceName column that comes after serviceAccounts is the numeric ID.

Undeleting the service account by numeric ID

You can attempt to restore the service account after locating the numerical ID for the destroyed service account.

To restore a service account, issue the gcloud beta iam service-accounts undelete command.

Command:

gcloud beta iam service-accounts undelete ACCOUNT_ID

 

Let's look into the details of Managing service account impersonation.

Managing service account impersonation

In this section we will look into the details of Managing service account impersonation.

Allowing principals to impersonate service accounts

A principal may pretend to be a service account by taking on one of various preset responsibilities, including:

• User of the Service Account (roles/iam.serviceAccountUser): The iam.serviceAccounts.actAs permission, which is part of this role, enables principals to gain indirect access to all of the resources that the service account has access to. For instance, if a principal has the Cloud SQL Admin role (roles/cloudsql.admin) on the project and the service account has the role of Service Account User, the principal can build a Cloud SQL instance pretending to be the service account.
   
• In addition, principals can use this role to do what is described on this page: link a service account to a resource.
   
• The —impersonate-service-account flag for the Google Cloud CLI as well as the creation of temporary service account credentials, are not permitted for principals in this position. The Service Account Token Creator job is also required to execute these operations.
   
• (roles/iam.serviceAccountTokenCreator) Service Account Token Creator: With this function, principals can act in places of authority as service accounts to:
  • Make OAuth 2.0 access tokens so that you can sign in to Google APIs.
     
  • Make OIDC (OpenID Connect) ID tokens.
     
  • Sign binary blobs and JSON Web Tokens (JWTs), so they can be used for authentication.
     

The following are some of the permissions for the role:

• You can generate OAuth 2.0 access tokens using the iam.serviceAccounts.getAccessToken method.
   
• You can produce OpenID Connect (OICD) ID tokens using the iam.serviceAccounts.getOpenIdToken method.
   
• Tokens can be obtained by service accounts using the following APIs: iam.serviceAccounts.implicitDelegation; iam.serviceAccounts.signBlob; iam.serviceAccounts.signJwt;
   
• The Workload Identity User role (roles/iam.workloadIdentityUser): This role enables principals to pretend to be GKE workload service accounts.
   
• The following are some of the permissions for the role:
  • You can generate OAuth 2.0 access tokens using the iam.serviceAccounts.getAccessToken method.
     
  • You can produce OpenID Connect (OICD) ID tokens using the iam.serviceAccounts.getOpenIdToken method.
     

You can also assign a different predefined role or a custom role that allows for the impersonation of service accounts.

The instructions for granting these privileges to specific service accounts and projects, folders, and organisations are provided in the following sections. Depending on the scope of access you want to allow, select the appropriate level:

• Grant the roles on the project, folder, or organisation for the principal to be able to impersonate all service accounts created there.
   
• Granting a single service account role will enable a principal to pretend to be that account.

Allow a principal to impersonate multiple service accounts

Granting a role on a project, folder, or organisation will enable a principal to pretend to be any service accounts created in those areas:

• Find the IAM page in the Google Cloud console.
   
• Select the project, folder, or organisation to which you wish to grant the role from the project selection at the top of the page.
   
• Select Add.
   
• Enter the email address of your principal.
   
• Choose a role that enables service account impersonation for the principal. See the list of roles for service account impersonation.
   
• Press Save.

Allow a principal to impersonate a single service account

Granting a role on a single service account will enable a principal to pretend to be that account:

• Navigate to the Service Accounts page in the Google Cloud dashboard.
   
• Choose a project.
   
• To authorise the principal to act as another user's service account, click the account's email address.
   
• Click On the Permissions tab.
   
• Click person_add Grant Access under Principals with access to this service account.
   
• Enter the email address of your principal.
   
• Choose a role that enables the principal to pretend to be other service accounts. See the list of roles for service account impersonation.
   
• To assign the role to the principal, click Save.
   

Repeat these procedures for every service account you want to award roles to.

Listing principals that can access a service account

To examine all principals who have access to a service account due to roles granted on the service account or roles granted on the project, folder, or organisation, utilise the Google Cloud console:

• Navigate to the Service Accounts page in the Google Cloud dashboard.
   
• Choose a project.
   
• To authorise the principal to act as another user's service account, click the account's email address.
   
• On the Permissions tab, click. The principals who have access to this service account are listed in the section under Principals with Access.

Attaching a service account to a resource

You can choose a user-managed service account as the resource's default identity for some Google Cloud resources. The action of doing this is referred to as associating or attaching the service account to the resource.
A resource impersonates the service account that is associated with it when it wants to access other Google Cloud services and resources. For instance, if you add a service account to a Compute Engine instance and the instance's programs use Google Cloud APIs using a client library, those programs will impersonate the service account by default. Typically, when you create a resource, you have to link a service account to it. You are unable to alter which service account is associated with a resource once it has been created. This is not true for compute engine instances; you can alter the service account that is associated with a certain instance as needed.

You must configure a service account before you can link it to a resource. The procedure varies depending on whether your service account and the resource are in the same project or distinct projects. You can build the resource and link the service account to it after configuring the service account.

Configuring a resource in the same project

As you would with any other principal, grant roles to the service account before attaching it to another resource in the same project so it has access to the necessary resources.

Configuring a resource in a different project

A service account may occasionally need to be attached to a resource that is part of a different project. You might need to tie one of your service accounts to a new resource in a different project if, for instance, you create all of your service accounts in a single project.

Do the following before to adding a service account to a resource in another project:

• Follow the instructions on this page to enable service account impersonation across projects in the project where the service account is located.
   
• Choose the undertaking for which you will produce the material.
   
• Decide on the resource type and the service that owns it so that you may attach the service account to it.
   
• For instance, Pub/Sub is the service that owns the resource if you are setting up a subscription to a Pub/Sub publication.
   
• Obtain the service representative's email address.
   
• Give the service agents the role of "Service Account Token Creator" (roles/iam.serviceAccountTokenCreator)
   

Let's look into the details of Creating and managing custom roles

Creating and managing custom roles

IAM identities with specified permissions are called IAM roles. Let's look into the details of it.

Creating a custom role

A caller needs to have the iam.roles.create permission in order to create a custom role. This access belongs by default to the organization's or project's owner, who is also able to establish and administer custom roles.

To start from scratch and build a new custom role:

• Navigate to the Roles page in the Google Cloud console.
   
• Choose the project or organisation you wish to establish a job for using the drop-down menu at the top of the page.
   
• Click Create Role.
   
• Give the role a name, title, description, and launch stage. Once a role is created, the name cannot be modified.
   
• To add permissions, click.
   
• Click Add Permissions after selecting the permissions you want to provide for the role. To filter and choose permissions based on services and kinds, use the All Services and All Types drop-down menus.
   

Steps to create a unique role based on a specified role that already exists:

• Navigate to the Roles page in the Google Cloud console.
   
• Choose the project or organisation for which you wish to create a role.
   
• Choose the roles you want to use as the foundation for the new custom role.
   
• To create a role from a selection, Click here.
   
• Give the role a name, title, description, and launch stage. Once a role is created, the name cannot be modified.
   
• The permissions you want to remove from the position should be unchecked.
   
• To include any permissions, click Add Permissions.
   
• Press Create.

Editing an existing custom role

Prior to updating a role, obtain it using roles. use roles to write the updated role after using get() to update the role. When setting the role, only use the etag value if it corresponds to the role in roles.get. An etag value is available here.

Steps to edit an existing custom role:

• Navigate to the Roles page in the Google Cloud console.
   
• Choose the project or organisation that contains the role you wish to update using the drop-down menu at the top of the page.
   
• Select a unique role.
   
• Click on the Edit Role button.
   
• Edit the role's Title, Description, or Role launch stage to make changes to the metadata.
   
• Make the following changes to the role's permissions:
  • To add additional permissions to the role, click Add Permissions.
     
  • To remove permissions from the role, uncheck Permissions.
     
• Then click Update.

Disabling a custom role

A custom role can be turned off by setting its launch stage to DISABLED. Any role bindings associated with a disabled role are deactivated, therefore, granting the role to a user has no impact.

• Navigate to the Roles page in the Google Cloud console.
   
• Choose a project from the drop-down menu at the top of the page.
   
• Choose your company or undertaking.
   
• Click Disable after selecting a custom role.

Listing roles

All custom roles created in your project or organisation can be listed. The steps are as follows:

• Navigate to the Roles page in the Google Cloud console.
   
• The page lists each custom role for the organisation or project that you have chosen.

Deleting a custom role

Any custom position in your project or organisation can be deleted. The steps are as follows:

• Navigate to the Roles page in the Google Cloud console.
   
• On the top of the page, select the role you want to delete and click Delete.
   

Any role bindings that make reference to a removed role still exist in your allowed policies but are ineffective. Within seven days, a job can be restored. The Google Cloud dashboard indicates that the role was destroyed over this seven-day span. Deleted roles can also be listed programmatically, but they are by default, excluded.

Undeleting a custom role

Roles can only be restored for 7 days after deletion. The role can be permanently destroyed after 7 days, at which point all role bindings that make reference to the role are also deleted. The steps are as follows:

• Navigate to the Roles page in the Google Cloud console.
   
• Locate the role you want to restore, then click Undelete on the more icon that appears at the end of the row.

Frequently Asked Questions

What is IAM?

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. 

Recommended Readings:

• Difference between Public Key and Private Key
   

You can refer to our guided paths on the Coding Ninjas Studio platform to learn more about DSA, DBMS, Competitive Programming, Python, Java, JavaScript, etc. To practice and improve yourself in the interview, you can also check out Top 100 SQL problems, Interview experience, Coding interview questions, and the Ultimate guide path for interviews. Do upvote our blog to help other ninjas grow. Happy Coding!!