The Resource Manager provides constraints that can be usedinorganization policies to limit the usage ofIdentity and Access Management (IAM)service accounts.

Many of these constraints determine whether service accounts and other resourcescan be created or configured in specific ways. These constraints are notretroactive; they do not affect previously created and configured serviceaccounts.

Before you begin

You must have permission to modifyorganization policies to setconstraints. For example, theorgpolicy.policyAdminrole has permission to set organization policy constraints. Read theUsing Constraintspage to learn more about managing policies at the organization level.

Managed constraints

The following constraints are types ofmanagedconstraint,which are set to true or false. Managed constraints are built on thecustom organization policyplatform.

To learn how to create organization policies that enforce managed constraints,seeUsing managed constraints in an organizationpolicy.

Prevent the Owner and Editor role from being granted to default service accounts

Some Google Cloud services automatically createdefault serviceaccounts. When a default serviceaccount is created, it is automatically granted the Editor role (roles/editor)on your project. Someone might also choose to grant a highly privileged role,like the Editor role or Owner role (roles/owner), to a default service accountat a later time.

The Editor and Owner roles are highly privilegedbasicroles. You shouldn't grant them toany principal in production, including default service accounts.

To prevent default service accounts from being granted the Editor or Ownerroles, use theiam.managed.preventPrivilegedBasicRolesForDefaultServiceAccounts managedconstraint. This constraint prevents default service accounts from ever beinggranted the Editor or Owner roles, either automatically or manually.

Disable service account creation

You can use theiam.managed.disableServiceAccountCreation managed constraintto disable the creation of new service accounts. This lets you centralizemanagement of service accounts while not restricting the other permissions yourdevelopers have on projects.

If you enforce this constraint in a project, then some Google Cloudservices cannot automatically createdefault service accounts. As aresult, if the project runs workloads that need toimpersonate a service account, theproject might not contain a service account that the workload can use. Toaddress this issue, you canenable service account impersonation across projects.When you enable this feature, you can create service accounts in a centralizedproject, then attach the service accounts to resources in other projects.

For more information about organizing service accounts, seeWhere to create service accounts.

Disable creation of API keys bound to service accounts

You can use theiam.managed.disableServiceAccountApiKeyCreation managed constraint todisable the creation ofAPI keys bound to service accounts.When this constraint is set, users cannot create API keys that are bound to serviceaccounts in projects affected by the constraint.

This constraint is enforced by default.

Disable service account key creation

You can use theiam.managed.disableServiceAccountKeyCreation managedconstraint to disable the creation of new external service account keys andCloud Storage HMAC keys. This lets youcontrol the use of unmanaged long-term credentials for service accounts. Whenthis constraint is set, user-managed credentials cannot be created for serviceaccounts in projects affected by the constraint.

Disable service account key upload

You can use theiam.managed.disableServiceAccountKeyUpload managed constraintto disable the upload of external public keys to service accounts. When thisconstraint is set, users cannot upload public keys to service accounts inprojects affected by the constraint.

Managed constraints (legacy) with boolean rules

The following constraints are types of legacy managed constraint withboolean rules,which are set to true or false.

Disable automatic role grants to default service accounts

Some Google Cloud services automatically createdefault service accounts. When a defaultservice account is created, it is automatically granted the Editor role(roles/editor) on your project.

To improve security, we strongly recommend that you disable the automatic rolegrant. Use theiam.automaticIamGrantsForDefaultServiceAccounts legacy managedconstraint to disable the automatic role grant.

Note: If your organization was created on or after May 3, 2024, this constraint is enforced by default.

Disable service account creation

You can use theiam.disableServiceAccountCreation legacy managed constraintto disable the creation of new service accounts. This lets you centralizemanagement of service accounts while not restricting the other permissions yourdevelopers have on projects.

If you enforce this constraint in a project, then some Google Cloudservices cannot automatically createdefault service accounts. As a result, ifthe project runs workloads that need toimpersonate a service account, theproject might not contain a service account that the workload can use. Toaddress this issue, you canenable service account impersonation across projects.When you enable this feature, you can create service accounts in a centralizedproject, then attach the service accounts to resources in other projects.

For more information about organizing service accounts, seeWhere to create service accounts.

Disable service account key creation

You can use theiam.disableServiceAccountKeyCreation legacy managed constraintto disable the creation of new external service account keys andCloud Storage HMAC keys. This lets youcontrol the use of unmanaged long-term credentials for service accounts. Whenthis constraint is set, user-managed credentials cannot be created for serviceaccounts in projects affected by the constraint.

Note: If your organization was created on or after May 3, 2024, this constraint is enforced by default.

Disable service account key upload

You can use theiam.disableServiceAccountKeyUpload legacy managed constraintto disable the upload of external public keys to service accounts. When thisconstraint is set, users cannot upload public keys to service accounts inprojects affected by the constraint.

Note: If your organization was created on or after May 3, 2024, this constraint is enforced by default.

Disable attachment of service accounts to resources in other projects

Each service account is located in a project. You can use theiam.disableCrossProjectServiceAccountUsage legacy managed constraint toprevent service accounts in a project from being attached to resources in otherprojects.

If you want to allow service accounts to be used across projects, seeEnabling service account impersonation across projects.

Restrict removal of project liens when service accounts are used across projects

When you allow a project's service accounts to be attached to resources in otherprojects, IAM adds aproject lien that prevents you fromdeleting the project. By default, anyone who has theresourcemanager.projects.updateLiens permission on the project can delete thelien.

If you enforce theiam.restrictCrossProjectServiceAccountLienRemoval legacymanaged constraint, then principals can delete the lien only if they have theresourcemanager.projects.updateLiens permission on the organization.

We recommend enforcing this constraint if any of your projects allowservice account impersonation across projects.

Disable workload identity cluster creation

You can use theiam.disableWorkloadIdentityClusterCreation legacy managedconstraint to require that any new Google Kubernetes Engine clusters have theWorkload Identity featuredisabled at the time of their creation. If you want to tightly control serviceaccount access in your organization, you may want to disable Workload Identityin addition to service account creation and service account key creation.

Existing GKE clusters with Workload Identity Federation for GKE enabled willnot be affected, and will continue to work as normal.

Setting a managed constraint (legacy) with boolean rules

gcloud resource-manager org-policies enable-enforce \    --organization 'ORGANIZATION_ID' \CONSTRAINT_NAME

disable-enforce

To learn about using constraints in organization policies, seeUsing Constraints.

Example managed constraint (legacy) with boolean rules

The following code snippet shows an organization policy that enforces theiam.disableServiceAccountCreation legacy managed constraint, which preventsservice accounts from being created:

name:organizations/012345678901/policies/iam.disableServiceAccountCreationspec:rules:-enforce:true

Managed constraints (legacy) with list rules

The following constraints are types of legacy managed constraint withlist rules,which are set to a list of values.

Extend lifetime of OAuth 2.0 access tokens

You cancreate an OAuth 2.0 access token that provides short-lived credentials for a service account.By default, the maximum lifetime of an access token is 1 hour (3,600 seconds).However, you can extend the maximum lifetime to 12 hours. To do so, identify theservice accounts that need an extended lifetime for access tokens, then addthese service accounts to an organization policy that includes theconstraints/iam.allowServiceAccountCredentialLifetimeExtension legacy managedconstraint.

Limit lifetime of service account keys

Aservice account key lets youauthenticate a request as a service account. By default, service account keysnever expire. You can change this default by setting an expiry time for allnewly created keys in your project, folder, or organization.

To set an expiry time, use theconstraints/iam.serviceAccountKeyExpiryHourslegacy managed constraint to specify the number of hours for which a newlycreated key is valid. After this amount of time, the service account keyexpires, and you can no longer use it.

This legacy managed constraint accepts the followingALLOW values; it doesnot acceptDENY values. As a best practice, use the shortest expiry time thatmeets your needs:

• 1h: 1 hour
• 8h: 8 hours
• 24h: 24 hours (1 day)
• 168h: 168 hours (7 days)
• 336h: 336 hours (14 days)
• 720h: 720 hours (30 days)
• 1440h: 1,440 hours (60 days)
• 2160h: 2,160 hours (90 days)

Theconstraints/iam.serviceAccountKeyExpiryHours constraint can't be mergedwith a parent policy. To enforce this constraint, you must either replace orinherit the parent policy.

Specify allowed external identity providers

If you useworkload identity federation, whichlets external identities access Google Cloud resources, you can specifywhich external identity providers are allowed. By default, all providers areallowed. To set a limit, use theconstraints/iam.workloadIdentityPoolProviders legacy managed constraint tospecify URIs for the allowed providers, using the following formats:

• Amazon Web Services (AWS):https://sts.amazonaws.com

  To limit which AWS accounts are allowed, use theconstraints/iam.workloadIdentityPoolAwsAccounts legacy managed constraintas described on this page.

• Microsoft Azure:https://sts.windows.net/azure-tenant-id

• Other identity providers that support OpenID Connect (OIDC): Use the issuerURI from your identity provider.

Specify allowed AWS accounts

If you useworkload identity federation, whichlets external identities access Google Cloud resources, you can specifywhich AWS accounts are allowed to access your resources. By default, workloadsfrom any AWS account are allowed to access your Google Cloud resources. Tolimit which AWS accounts are allowed, use theconstraints/iam.workloadIdentityPoolAwsAccounts legacy managed constraint tospecify a list of allowed account IDs.

Automatically disable exposed service account keys

Google Cloud occasionally detects that a particular service account key has beenexposed—for example, it might detect a key in a public repository. Tospecify what Google Cloud does with these keys, use theiam.serviceAccountKeyExposureResponse legacy managed constraint. Keys thatare monitored include long-lived service account keys and API keys that arebound to a service account.

This legacy managed constraint accepts the followingALLOW values; itdoesn't acceptDENY values.

• DISABLE_KEY: If Google Cloud detects an exposed key, it willautomatically disable the key. It also creates a Cloud Audit Logs event andsends a notification about the exposed key to project owners andsecuritycontacts.

  Note: Starting on June 16, 2024, if you don't set a value for this constraint,Google Cloud will default to the behavior described forDISABLE_KEY.

• WAIT_FOR_ABUSE: Google Cloud won't proactively disable exposed keys.However, Google Cloud might still disable exposed keys if they're usedin ways that adversely affect the platform. Regardless of whether the exposedkey is disabled, Google Cloud creates a Cloud Audit Logs event andsends a notification about the exposed key to project owners andsecuritycontacts.

When Google Cloud detects a exposed key or disables an exposed key, it also does thefollowing:

• Generates Cloud Audit Logs events.

  • When Google Cloud detects that a key has been exposed, an abuse event iscreated in theAbuse Event logs.

  • When Google Cloud disables a key, the audit logs contain the disableaction by principalgcp-compromised-key-response@system.gserviceaccount.com.

• Sets theextendedStatus.value field of the exposed or disabled key. The extended status field includes thelocation where the leak was detected.

If you do decide to set the constraint toWAIT_FOR_ABUSE, we recommend thatyou subscribe to Cloud Audit Logs events, review your security contact informationinEssential Contacts,and ensure that your security contacts respond to notifications in a timely manner.

Theiam.serviceAccountKeyExposureResponse constraint can't be merged with aparent policy. To enforce this constraint, you must replace the parent policy.

Setting a managed constraint (legacy) with list rules

gcloudresource-managerorg-policiesallow\CONSTRAINT_NAME\VALUE_1[VALUE_N...]\--organization=ORGANIZATION_ID\

To learn about using constraints in organization policies, seeUsing Constraints.

Example managed constraint (legacy) with list rules

The following code snippet shows an organization policy that enforces theiam.allowServiceAccountCredentialLifetimeExtension legacy managed constraint,which extends the maximum lifetime of OAuth 2.0 access tokens for listed serviceaccounts:

name:organizations/012345678901/policies/iam.allowServiceAccountCredentialLifetimeExtensionspec:rules:-values:allowedValues:-SERVICE_ACCOUNT_ADDRESS

Enforcing constraints conditionally using tags

Tags can be used to include orexclude tagged resources from organization policy enforcement. Aftercreating a tagand attaching it to a service account,you can add a condition to the policy to conditionally include or excludedtagged service accounts from enforcement.

For more details on using tags with organization policies, seeSetting an organization policy with tags.

Error messages

Disable service account creation

Ifiam.disableServiceAccountCreation is enforced, creating a service accountwill fail with the error:

FAILED_PRECONDITION: Service account creation is not allowed on this project.

Disable creation of API keys bound to service accounts

Ifiam.managed.disableServiceAccountApiKeyCreation is enforced, creating an API keythat is bound to a service account will fail with the error:

FAILED_PRECONDITION: Operation denied by org policy:["constraints/iam.managed.disableServiceAccountApiKeyCreation":"When enforced, disables creation of API Keys bound to service accounts."]

Disable service account key creation

Ifiam.disableServiceAccountKeyCreation is enforced, creating a service accountwill fail with the error:

FAILED_PRECONDITION: Key creation is not allowed on this service account.

Disable workload identity cluster creation

Ifiam.disableWorkloadIdentityClusterCreation is enforced, creating aGKE cluster with Workload Identity enabled will fail with theerror:

FAILED_PRECONDITION: Workload Identity is disabled by the organizationpolicy constraints/iam.disableWorkloadIdentityClusterCreation. Contact youradministrator to enable this feature.

Troubleshooting known issues

Default service accounts

Applying theiam.disableServiceAccountCreation constraint will prevent thecreation of service accounts in that project. This limitation also affectsGoogle Cloud services that, when enabled, automatically create defaultservice accounts in the project, such as:

• Compute Engine
• GKE
• App Engine
• Dataflow

If theiam.disableServiceAccountCreation constraint is applied, attempting toenable these services will fail because their default service accounts cannot becreated.

To resolve this issue:

1. Temporarily remove theiam.disableServiceAccountCreation constraint.
2. Enable the desired services.
3. Create any other desired service accounts.
4. Finally, re-apply the constraint.