Code360 powered by Coding Ninjas X Naukri.com. Code360 powered by Coding Ninjas X Naukri.com
Last Updated: Mar 27, 2024

Advanced Concepts of Identity and Access Management

Leveraging ChatGPT - GenAI as a Microsoft Data Expert
Speaker
Prerita Agarwal
Data Specialist @
23 Jul, 2024 @ 01:30 PM

Introduction

In the previous article, we looked at the details of Basic Concepts of Identity and Access Management, Granting IAM Roles, Managing access to projects, folders, organizations, and Service Accounts.

This blog explains the details of Advanced Concepts of Identity and Access Management along with the details of Creating and managing service accounts, Managing service account impersonation, and Creating and managing custom roles.

Without further ado, let's get started.

GCP Image

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.

Get the tech career you deserve, faster!
Connect with our expert counsellors to understand how to hack your way to success
User rating 4.7/5
1:1 doubt support
95% placement record
Akash Pal
Senior Software Engineer
326% Hike After Job Bootcamp
Himanshu Gusain
Programmer Analyst
32 LPA After Job Bootcamp
After Job
Bootcamp

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 are IAM groups?

A set of IAM users is known as an IAM user group. It may be simpler to manage the permissions for those users if you can define permissions for many users through user groups.

What is an IAM role?

IAM identities with specified permissions are called IAM roles.

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 Advanced Concepts of Identity and Access Management along with the details of Creating and managing service accounts, Managing service account impersonation, and Creating and managing custom roles.

We hope that this blog has helped you enhance your knowledge regarding Advanced Concepts of Identity and Access Management, and if you would like to learn more, check out our articles on Google Cloud Certification. You can refer to our guided paths on the Coding Ninjas Studio platform to learn more about DSADBMSCompetitive ProgrammingPythonJavaJavaScript, etc. To practice and improve yourself in the interview, you can also check out Top 100 SQL problemsInterview experienceCoding interview questions, and the Ultimate guide path for interviews. Do upvote our blog to help other ninjas grow. Happy Coding!!

Thank You Image
Topics covered
1.
Introduction
2.
Creating and managing service accounts
2.1.
Creating a service account
2.2.
Listing service accounts
2.3.
Updating a service account
2.4.
Disabling a service account
2.5.
Enabling a service account
2.6.
Deleting a service account
2.7.
Undeleting a service account
2.8.
Finding a deleted service account's numeric ID
2.9.
Undeleting the service account by numeric ID
3.
Managing service account impersonation
3.1.
Allowing principals to impersonate service accounts
3.2.
Allow a principal to impersonate multiple service accounts
3.3.
Allow a principal to impersonate a single service account
3.4.
Listing principals that can access a service account
3.5.
Attaching a service account to a resource
3.5.1.
Configuring a resource in the same project
3.5.2.
Configuring a resource in a different project
4.
Creating and managing custom roles
4.1.
Creating a custom role
4.2.
Editing an existing custom role
4.3.
Disabling a custom role
4.4.
Listing roles
4.5.
Deleting a custom role
4.6.
Undeleting a custom role
5.
Frequently Asked Questions
5.1.
What are IAM groups?
5.2.
What is an IAM role?
5.3.
What is the purpose of IAM?
6.
Conclusion