What is the key difference between a managed service account and a group managed service account?
This page explains service accounts, types of service accounts, and the IAM roles that are available to service accounts. Show
Before you begin
What are service accounts?A service account is a special kind of account used by an application or compute workload, such as a Compute Engine virtual machine (VM) instance, rather than a person. Applications use service accounts to make authorized API calls, authorized as either the service account itself, or as Google Workspace or Cloud Identity users through domain-wide delegation. For example, a service account can be attached to a Compute Engine VM, so that applications running on that VM can authenticate as the service account. In addition, the service account can be granted IAM roles that let it access resources. The service account is used as the identity of the application, and the service account's roles control which resources the application can access. A service account is identified by its email address, which is unique to the account. Differences between a service account and a user accountService accounts differ from user accounts in a few key ways:
Preventing creation of service accountsYou can prevent the creation of service accounts by enforcing the Before you enforce this constraint, consider the following limitations:
Service accounts and Google groupsYou can add service accounts to a Google group, then grant roles to the group. However, adding service accounts to groups is not a best practice. Service accounts are used by applications, and each application is likely to have its own access requirements. Types of keys for service accountsEach service account is associated with a public/private RSA key pair. The Service Account Credentials API uses this internal key pair to create short-lived service account credentials, and to sign blobs and JSON Web Tokens (JWTs). This key pair is known as the Google-managed key pair. In addition, you can create multiple public/private RSA key pairs, known as user-managed key pairs, and use the private key to authenticate with Google APIs. This private key is known as a service account key. Google-managed key pairsGoogle-managed key pairs are used by the Service Account Credentials API, and by Google Cloud services such as App Engine and Compute Engine, to generate short-lived credentials for service accounts. Google-managed key pairs are automatically rotated and used for signing for a maximum of two weeks. The rotation process is probabilistic; usage of the new key will gradually ramp up and down over the key's lifetime. The private key in a Google-managed key pair is always held in escrow, and you can never access it directly. The public key in a Google-managed key pair is publicly accessible, so that anyone can verify signatures that are created with the private key. You can access the public key in several different formats:
If you download and cache the public key, we recommend caching it for at most 24 hours to ensure that you always have the current key. Regardless of when you retrieve the public key, it will be valid for at least 24 hours after you retrieve it. User-managed key pairsYou can create user-managed key pairs for a service account, then use the private key from each key pair to authenticate with Google APIs. This private key is known as a service account key. Each service account can have up to 10 service account keys. Google stores only the public portion of a user-managed key pair. There are a few different ways to create a user-managed key pair for a service account:
User-managed keys are extremely powerful credentials, and they can represent a security risk if they are not managed correctly. To limit the use of user-managed keys, you can enforce the following organization policy constraints in an organization, project, or folder:
If you enforce these constraints because you are using workload identity federation, consider using the organization policy constraints for workload identity federation to specify which identity providers are allowed. Types of service accountsUser-managed service accountsYou can create user-managed service accounts in your project using the IAM API, the Google Cloud console, or the Google Cloud CLI. You are responsible for managing and securing these accounts. By default, you can create up to 100 user-managed service accounts in a project. If this quota does not meet your needs, you can use the Google Cloud console to request a quota increase. The default service accounts described on this page do not count towards this quota. When you create a user-managed service account in your project, you choose a name for the service account. This name appears in the email address that identifies the service account, which uses the following format: Default service accountsWhen you enable or use some Google Cloud services, they create user-managed service accounts that enable the service to deploy jobs that access other Google Cloud resources. These accounts are known as default service accounts. If your application runs in a Google Cloud environment that has a default service account, your application can use the credentials for the default service account to call Google Cloud APIs. Alternatively, you can create your own user-managed service account and use it to authenticate. For details, see Finding credentials automatically. The following table lists the services that create default service accounts:
Google-managed service accountsSome Google Cloud services need access to your resources so that they can act on your behalf. For example, when you use Cloud Run to run a container, the service needs access to any Pub/Sub topics that can trigger the container. To meet this need, Google creates and manages service accounts for many Google Cloud services. These service accounts are known as Google-managed service accounts. You might see Google-managed service accounts in your project's allow policy, in audit logs, or on the IAM page in the Google Cloud console. Google-managed service accounts are not listed in the Service accounts page in the Google Cloud console. For example:
Service account locationsEach service account is located in a project. After you create a service account, you cannot move it to a different project. There are a few ways to organize your service accounts into projects:
Service account permissionsService accounts are both identities and resources. Because service accounts are identities, you can let a service account access resources in your project by granting it a role, just like you would for any other principal. For example, if you want to let your application's service account access objects in a Cloud Storage bucket, you can grant the service account the Storage Object Viewer role ( For more information on granting roles to principals, including service accounts, see Granting, changing, and revoking access. However, service accounts are also resources that accept allow policies. As a result, you can let other principals access a service account by granting them a role on the service account, or on one of the service account's parent resources. For example, to let a user impersonate a service
account, you could grant the user the Service Account User role ( For more information on granting roles to principals, including service accounts, see Granting, changing, and revoking access. For more information on granting roles on service accounts, see Managing service account impersonation. The Service Account User roleYou can grant the Service Account User role (
This role's permissions include the For more information on granting users roles on service accounts, see Managing service account impersonation. Service accounts represent your service-level security. The security of the service is determined by the people who have IAM roles to manage and use the service accounts, and people who hold private external keys for those service accounts. Best practices to ensure security include the following:
To learn more about best practices, see Understanding service accounts. The Service Account Token Creator roleThis role lets principals impersonate service accounts to do the following:
See Creating short-lived service account credentials for details. The role's permissions include the following:
The Workload Identity User roleThis role lets principals impersonate service accounts from GKE workloads. The role's permissions include the following:
Access scopesAccess scopes are a legacy method of specifying permissions for a Compute Engine virtual machine (VM) instance. They define the default OAuth scopes used in requests from the gcloud CLI and client libraries. Google Cloud now uses IAM, not access scopes, to specify permissions for Compute Engine instances. However, you are still required to set an access scope when you configure an instance to impersonate a service account. For more information, see the Compute Engine documentation. Short-lived service account credentialsYou can create short-lived credentials that allow you to assume the identity of a Google Cloud service account. These credentials can be used to authenticate calls to Google Cloud APIs or other non-Google APIs. The most common use case for these credentials is to temporarily delegate access to Google Cloud resources across different projects, organizations, or accounts. For example, instead of providing an external caller with the permanent credentials of a highly-privileged service account, temporary emergency access can be granted instead. Alternatively, a designated service account with fewer permissions can be impersonated by an external caller without requiring a more highly privileged service account's credentials. For more information, see Creating short-lived service account credentials. Workload identity federationYou can grant identities from a workload that runs outside of Google Cloud, such as on Amazon Web Services (AWS) or Microsoft Azure, the ability to impersonate a service account. This lets you access resources directly, using short-lived credentials, instead of using a service account key. To learn more, see Workload identity federation. Application Default CredentialsApplication Default Credentials is a tool that Google Cloud Client Libraries use to automatically discover service account credentials. You can specify a service account key in an environment variable, and Application Default Credentials automatically uses that service account key. If you do not specify a key, then Application Default Credentials uses the service account that is attached to the resource that is running your code, or the default service account for the service that is running your code. To learn more, see Finding credentials automatically. What's next
Try it for yourselfIf you're new to Google Cloud, create an account to evaluate how our products perform in real-world scenarios. New customers also get $300 in free credits to run, test, and deploy workloads. Get started for free What is the difference between service accounts and managed service accounts?Managed Service Accounts are more secure then ordinary service accounts. Ordinary service accounts are normal user accounts with complex passwords used for running various server services. Managed Service Accounts are different. They can only created with PowerShell.
What is group managed service account?Group managed service accounts (gMSAs) are managed domain accounts that you use to help secure services. gMSAs can run on a single server or on a server farm, such as systems behind a network load balancing or Internet Information Services (IIS) server.
Why use a group managed service account?Group Managed Service Accounts (gMSAs) provide a higher security option for non-interactive applications/services/processes/tasks that run automatically but need a security credential.
What is the difference between a service account and a user account?A service account is a user account that's created explicitly to provide a security context for services that are running on Windows Server operating systems. The security context determines the service's ability to access local and network resources.
|