What Is Google Service Account?
Background
A service account is a special type of Google account intended to represent a non-human user that needs to authenticate and be authorized to access data in Google APIs.
Typically, service accounts are used in scenarios such as:
- Running workloads on virtual machines (VMs).
- Running workloads on on-premises workstations or data centers that call Google APIs.
- Running workloads which are not tied to the lifecycle of a human user.
Your application assumes the identity of the service account to call Google APIs, so that the users aren't directly involved.
A service account is a special type of Google account intended to represent a non-human user that needs to authenticate and be authorized to access data in Google APIs.
Typically, service accounts are used in scenarios such as:
- Running workloads on virtual machines (VMs).
- Running workloads on on-premises workstations or data centers that call Google APIs.
- Running workloads which are not tied to the lifecycle of a human user.
Your application assumes the identity of the service account to call Google APIs, so that the users aren't directly involved.
Managing service accounts
Service accounts can be thought of as both a resource and as an identity.
When thinking of the service account as an identity, you can grant a role to a service account, allowing it to access a resource (such as a project).
When thinking of a service account as a resource, you can grant roles to other users to access or manage that service account.
Service accounts can be thought of as both a resource and as an identity.
When thinking of the service account as an identity, you can grant a role to a service account, allowing it to access a resource (such as a project).
When thinking of a service account as a resource, you can grant roles to other users to access or manage that service account.
Granting access to service accounts
Granting access to a service account to access a resource is similar to granting access to any other identity. For example, if you have an application running on Compute Engine and you want the application to only have access to create objects in Cloud Storage. You can create a service account for the application and grant it the Storage Object Creator role.
Learn about Granting roles to all types of principals, including service accounts.
Granting access to a service account to access a resource is similar to granting access to any other identity. For example, if you have an application running on Compute Engine and you want the application to only have access to create objects in Cloud Storage. You can create a service account for the application and grant it the Storage Object Creator role.
Learn about Granting roles to all types of principals, including service accounts.
Keeping track of service accounts
Over time, as you create more and more service accounts, you might lose track of which service account is used for what purpose.
The display name of a service account is a good way to capture additional information about the service account, such as the purpose of the service account or a contact person for the account. For new service accounts, you can populate the display name when creating the service account. For existing service accounts use the serviceAccounts.update() method to modify the display name.
Over time, as you create more and more service accounts, you might lose track of which service account is used for what purpose.
The display name of a service account is a good way to capture additional information about the service account, such as the purpose of the service account or a contact person for the account. For new service accounts, you can populate the display name when creating the service account. For existing service accounts use the serviceAccounts.update() method to modify the display name.
Identifying unused service accounts
Unused service accounts create an unnecessary security risk, so we recommend disabling unused service accounts, then deleting the service accounts when you are sure that you no longer need them. You can use the following methods to identify unused service accounts:
- Service account insights tell you which service accounts in your project have not authenticated in the past 90 days.
- Activity analyzer lets you check when a service account or key was last used.
You can also use service account usage metrics to track service account and key usage generally.
Unused service accounts create an unnecessary security risk, so we recommend disabling unused service accounts, then deleting the service accounts when you are sure that you no longer need them. You can use the following methods to identify unused service accounts:
- Service account insights tell you which service accounts in your project have not authenticated in the past 90 days.
- Activity analyzer lets you check when a service account or key was last used.
You can also use service account usage metrics to track service account and key usage generally.
Deleting and recreating service accounts
It is possible to delete a service account and then create a new service account with the same name.
When you delete a service account, its role bindings are not immediately deleted. Instead, the role bindings list the service account with the prefix deleted:. For an example, see Policies with deleted principals.
If you create a new service account with the same name as a recently deleted service account, the old bindings may still exist; however, they will not apply to the new service account even though both accounts have the same email address. This behavior occurs because service accounts are given a unique ID within Identity and Access Management (IAM) at creation. Internally, all role bindings are granted using these IDs, not the service account's email address. Therefore, any role bindings that existed for a deleted service account do not apply to a new service account that uses the same email address.
Similarly, if you attach a service account to a resource, then delete the service account and create a new service account with the same name, the new service account will not be attached to the resource.
To prevent this unexpected behavior, consider using a new, unique name for every service account. Also, if you accidentally delete a service account, you can try to undelete the service account instead of creating a new service account.
If you cannot undelete the original service account, and you need to create a new service account with the same name and the same roles, you must grant the roles to the new service account. For details, see Policies with deleted principals.
If you also need the new service account to be attached to the same resources as the original service account, do one of the following:
- For Compute Engine instances, you can change the service account that is attached to the instance to replace the original service account with the new service account.
- For all other resources, you must delete the existing resource, then create a new resource of the same type and attach the new service account.
It is possible to delete a service account and then create a new service account with the same name.
When you delete a service account, its role bindings are not immediately deleted. Instead, the role bindings list the service account with the prefix deleted:. For an example, see Policies with deleted principals.
If you create a new service account with the same name as a recently deleted service account, the old bindings may still exist; however, they will not apply to the new service account even though both accounts have the same email address. This behavior occurs because service accounts are given a unique ID within Identity and Access Management (IAM) at creation. Internally, all role bindings are granted using these IDs, not the service account's email address. Therefore, any role bindings that existed for a deleted service account do not apply to a new service account that uses the same email address.
Similarly, if you attach a service account to a resource, then delete the service account and create a new service account with the same name, the new service account will not be attached to the resource.
To prevent this unexpected behavior, consider using a new, unique name for every service account. Also, if you accidentally delete a service account, you can try to undelete the service account instead of creating a new service account.
If you cannot undelete the original service account, and you need to create a new service account with the same name and the same roles, you must grant the roles to the new service account. For details, see Policies with deleted principals.
If you also need the new service account to be attached to the same resources as the original service account, do one of the following:
- For Compute Engine instances, you can change the service account that is attached to the instance to replace the original service account with the new service account.
- For all other resources, you must delete the existing resource, then create a new resource of the same type and attach the new service account.
Permissions for service accounts
This section describes common scenarios for permissions granted to service accounts, or user accounts that have the permissions to impersonate service accounts:
This section describes common scenarios for permissions granted to service accounts, or user accounts that have the permissions to impersonate service accounts:
Granting minimum permissions to service accounts
As with all types of principals, you should only grant the service account the minimum set of permissions required to achieve its goal. Learn about granting roles to all types of principals, including service accounts.
When granting permissions to users to access a service account, keep in mind that the user can access all the resources for which the service account has permissions. Therefore it's important to configure permissions of your service accounts carefully; that is, be strict about who on your team can act as (or impersonate) a service account. Use particular caution when allowing users to impersonate highly privileged service accounts, such as the Compute Engine and App Engine default service accounts.
Users with IAM roles to update the App Engine and Compute Engine instances (such as App Engine Deployer or Compute Instance Admin) can effectively run code as the service accounts used to run these instances, and indirectly gain access to all the resources for which the service accounts has access. Similarly, SSH access to a Compute Engine instance may also provide the ability to execute code as that instance.
As with all types of principals, you should only grant the service account the minimum set of permissions required to achieve its goal. Learn about granting roles to all types of principals, including service accounts.
When granting permissions to users to access a service account, keep in mind that the user can access all the resources for which the service account has permissions. Therefore it's important to configure permissions of your service accounts carefully; that is, be strict about who on your team can act as (or impersonate) a service account. Use particular caution when allowing users to impersonate highly privileged service accounts, such as the Compute Engine and App Engine default service accounts.
Users with IAM roles to update the App Engine and Compute Engine instances (such as App Engine Deployer or Compute Instance Admin) can effectively run code as the service accounts used to run these instances, and indirectly gain access to all the resources for which the service accounts has access. Similarly, SSH access to a Compute Engine instance may also provide the ability to execute code as that instance.
Service account permissions for common scenarios
Service accounts can be used in many different scenarios, and each of them requires certain permissions. This section describes common scenarios and what permissions are required.
Service accounts can be used in many different scenarios, and each of them requires certain permissions. This section describes common scenarios and what permissions are required.
Attaching service accounts to resources
If you want to start a long-running job that authenticates as a service account, you need to attach a service account to the resource that will run the job.
Permissions:
- Permissions to create the resource
iam.serviceAccounts.actAs
To find roles that include these permissions, search the roles list for the permissions.
There are several different Google Cloud resources that can run long-running jobs as service accounts. Some examples of these resources include:
- Compute Engine VMs
- App Engine apps
- Cloud Functions
When you create these resources, you have the option to attach a service account. This service account acts as the resource's identity.
To create a resource and attach a service account, you need permissions to create that resource and permission to impersonate the service account that you will attach to the resource. Permission to impersonate the service account is provided by any role that includes the iam.serviceAccounts.actAs permission.
After you create the resource and attach a service account to it, you can start a long-running job on the resource. The job runs as the service account that is attached to the resource, and uses that service account to authorize requests to Google Cloud APIs.
To learn more about attaching service accounts to resources, see Attaching a service account to a resource.
If you want to start a long-running job that authenticates as a service account, you need to attach a service account to the resource that will run the job.
Permissions:
- Permissions to create the resource
iam.serviceAccounts.actAs
To find roles that include these permissions, search the roles list for the permissions.
There are several different Google Cloud resources that can run long-running jobs as service accounts. Some examples of these resources include:
- Compute Engine VMs
- App Engine apps
- Cloud Functions
When you create these resources, you have the option to attach a service account. This service account acts as the resource's identity.
To create a resource and attach a service account, you need permissions to create that resource and permission to impersonate the service account that you will attach to the resource. Permission to impersonate the service account is provided by any role that includes the iam.serviceAccounts.actAs permission.
After you create the resource and attach a service account to it, you can start a long-running job on the resource. The job runs as the service account that is attached to the resource, and uses that service account to authorize requests to Google Cloud APIs.
To learn more about attaching service accounts to resources, see Attaching a service account to a resource.
Directly impersonating a service account
Permissions:
iam.serviceAccounts.getAccessTokeniam.serviceAccounts.signBlobiam.serviceAccounts.signJwtiam.serviceAccounts.implicitDelegation
Roles:
roles/iam.serviceAccountTokenCreator (Service Account Token Creator)
Once granted the required permissions, a user (or service) can directly impersonate (or assert) the identity of a service account in a few common scenarios.
First, the user may get short-term credentials for the service account using the iam.serviceAccounts.getAccessToken permission and by calling the generateAccessToken() method. By using short-term credentials, a user can issue commands to Google Cloud and can access all resources to which the service account has access. For example, this flow allows a user to use the gcloud --impersonate-service-account flag to impersonate the service account without requiring the use of a downloaded external service account key.
Second, the user may get artifacts signed by the Google-managed private key of the service account using the iam.serviceAccounts.signBlob permission and by calling either the signBlob() or signJwt() method. The Google-managed private key is always held in escrow and is never directly exposed. signBlob() allows signing of arbitrary payloads (such as Cloud Storage-signed URLs), while signJwt() only allows signing well-formed JWTs.
Finally, the user may impersonate (or assert) the service account without ever retrieving a credential for the service account. This is an advanced use case, and is only supported for programmatic access using the generateAccessToken() method. In scenarios with at least 3 service accounts, namely A, B, and C: service account A can get an access token for service account C if service account A is granted the iam.serviceAccounts.implicitDelegation permission on B, and B is granted the iam.serviceAccounts.getAccessToken permission on C.
Permissions:
iam.serviceAccounts.getAccessTokeniam.serviceAccounts.signBlobiam.serviceAccounts.signJwtiam.serviceAccounts.implicitDelegation
Roles:
roles/iam.serviceAccountTokenCreator(Service Account Token Creator)
Once granted the required permissions, a user (or service) can directly impersonate (or assert) the identity of a service account in a few common scenarios.
First, the user may get short-term credentials for the service account using the iam.serviceAccounts.getAccessToken permission and by calling the generateAccessToken() method. By using short-term credentials, a user can issue commands to Google Cloud and can access all resources to which the service account has access. For example, this flow allows a user to use the gcloud --impersonate-service-account flag to impersonate the service account without requiring the use of a downloaded external service account key.
Second, the user may get artifacts signed by the Google-managed private key of the service account using the iam.serviceAccounts.signBlob permission and by calling either the signBlob() or signJwt() method. The Google-managed private key is always held in escrow and is never directly exposed. signBlob() allows signing of arbitrary payloads (such as Cloud Storage-signed URLs), while signJwt() only allows signing well-formed JWTs.
Finally, the user may impersonate (or assert) the service account without ever retrieving a credential for the service account. This is an advanced use case, and is only supported for programmatic access using the generateAccessToken() method. In scenarios with at least 3 service accounts, namely A, B, and C: service account A can get an access token for service account C if service account A is granted the iam.serviceAccounts.implicitDelegation permission on B, and B is granted the iam.serviceAccounts.getAccessToken permission on C.
Generating OpenID Connect (OIDC) ID tokens
Permissions:
iam.serviceAccounts.getOpenIdToken
Roles:
roles/iam.serviceAccountTokenCreator (Service Account Token Creator)
A user (or service) can generate an OpenID Connect (OIDC)-compatible JWT token signed by the Google OIDC Provider (accounts.google.com) that represents the identity of the service account using the iam.serviceAccounts.getOpenIdToken permission.
These tokens are not directly accepted by most Google APIs without your organization deploying additional identity federation to grant access to Google. There are a few exceptions—for example, Identity-Aware Proxy, which allows OIDC-based access to user-run applications.
Permissions:
iam.serviceAccounts.getOpenIdToken
Roles:
roles/iam.serviceAccountTokenCreator(Service Account Token Creator)
A user (or service) can generate an OpenID Connect (OIDC)-compatible JWT token signed by the Google OIDC Provider (accounts.google.com) that represents the identity of the service account using the iam.serviceAccounts.getOpenIdToken permission.
These tokens are not directly accepted by most Google APIs without your organization deploying additional identity federation to grant access to Google. There are a few exceptions—for example, Identity-Aware Proxy, which allows OIDC-based access to user-run applications.
Generating external private keys
Permissions:
iam.serviceAccountKeys.create
Roles:
roles/editor (Editor)roles/iam.serviceAccountKeyAdmin (Service Account Key Admin)
A user or service can generate external private key material (RSA) that can be used to authenticate directly to Google as the service account. This key material can then be used with Application Default Credentials (ADC) libraries, or with the gcloud auth activate-service-account command. Any person who gains access to the key material will then have full access to all resources to which the service account has access. Such private key material should be treated with the highest concern, and should be considered less secure the longer the material exists. Therefore, rotating private key material is critical to maintaining strong security.
Permissions:
iam.serviceAccountKeys.create
Roles:
roles/editor(Editor)roles/iam.serviceAccountKeyAdmin(Service Account Key Admin)
A user or service can generate external private key material (RSA) that can be used to authenticate directly to Google as the service account. This key material can then be used with Application Default Credentials (ADC) libraries, or with the gcloud auth activate-service-account command. Any person who gains access to the key material will then have full access to all resources to which the service account has access. Such private key material should be treated with the highest concern, and should be considered less secure the longer the material exists. Therefore, rotating private key material is critical to maintaining strong security.
Using service accounts with Compute Engine
Compute Engine instances need to run as service accounts to have access to other Google Cloud resources. To make sure that your Compute Engine instances are more secure, consider the following:
You can create VMs in the same project with different service accounts. To change the service account of a VM after it's created, use the instances.setServiceAccount method.
You can grant IAM roles to service accounts to define what they can access. In many cases you won't need to rely on scopes anymore. This gives you the advantage of being able to modify permissions of a VM's service account without recreating the instance.
Since instances depend on their service accounts to have access to Google Cloud resources, avoid deleting service accounts when they are still used by running instances. If you delete the service accounts, the instances may start failing their operations.
Compute Engine instances need to run as service accounts to have access to other Google Cloud resources. To make sure that your Compute Engine instances are more secure, consider the following:
You can create VMs in the same project with different service accounts. To change the service account of a VM after it's created, use the
instances.setServiceAccountmethod.You can grant IAM roles to service accounts to define what they can access. In many cases you won't need to rely on scopes anymore. This gives you the advantage of being able to modify permissions of a VM's service account without recreating the instance.
Since instances depend on their service accounts to have access to Google Cloud resources, avoid deleting service accounts when they are still used by running instances. If you delete the service accounts, the instances may start failing their operations.
%20FREE%202022.jpg)
0 Comments