{
	"id": "75ef1231-89da-4290-915a-0e5185933f56",
	"created_at": "2026-04-06T00:06:31.376957Z",
	"updated_at": "2026-04-10T03:20:38.088902Z",
	"deleted_at": null,
	"sha1_hash": "05355317e9ac9c56d1bbff8bc0617bbd0803b0b9",
	"title": "Understanding allow policies",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 177523,
	"plain_text": "Understanding allow policies\r\nArchived: 2026-04-05 17:52:46 UTC\r\nYou can grant access to Google Cloud resources by using allow policies, also known as Identity and Access\r\nManagement (IAM) policies, which are attached to resources. You can attach only one allow policy to each\r\nresource. The allow policy controls access to the resource itself, as well as any descendants of that resource that\r\ninherit the allow policy.\r\nThis page shows allow policies in JSON format. You can also use the Google Cloud CLI to retrieve allow policies\r\nin YAML format.\r\nPolicy structure\r\nAn allow policy is a collection of role bindings and metadata. A role binding specifies what access should be\r\ngranted to a resource. It associates, or binds, one or more principals with a single IAM role and any context-specific conditions that change how and when the role is granted. The metadata includes additional information\r\nabout the allow policy, such as an etag and version to facilitate policy management.\r\nEach role binding can include the following fields:\r\nOne or more principals, also known as members or identities. There are multiple types of principals,\r\nincluding single users, groups of users, and service accounts. For a full list of supported principal types, see\r\nPrincipal types.\r\nA role, which is a named collection of permissions that provide the ability to perform actions on Google\r\nCloud resources.\r\nA condition, which is an optional logic expression that further constrains the role binding based on\r\nattributes about the request, such as its origin or the target resource. Conditions are typically used to control\r\nwhether access is granted based on the context for a request.\r\nIf a role binding contains a condition, it is referred to as a conditional role binding.\r\nSome Google Cloud services don't accept conditions in allow policies. For a list of services and resource\r\ntypes that accept conditions, see Resource types that accept conditional role bindings.\r\nChanges to a principal's access are eventually consistent. This means that it takes time for access changes to\r\npropagate through the system. To learn how long it takes, on average, for access changes to propagate, see Access\r\nchange propagation.\r\nLimits on all principals\r\nEach allow policy can contain up to 1,500 principals. For the purposes of this limit, IAM counts all appearances\r\nof each principal in the allow policy's role bindings, as well as the principals that the allow policy exempts from\r\nhttps://cloud.google.com/iam/docs/policies\r\nPage 1 of 17\n\nData Access audit logging. It does not deduplicate principals that appear in more than one role binding. For\r\nexample, if an allow policy contains only role bindings for the principal user:my-user@example.com , and this\r\nprincipal appears in 50 role bindings, then you can add another 1,450 principals to the role bindings in the allow\r\npolicy.\r\nAlso, for the purposes of this limit, each appearance of a domain or Google group is counted as a single principal,\r\nregardless of the number of individual members in the domain or group.\r\nIf you use IAM Conditions, or if you grant roles to many principals with unusually long identifiers, then IAM\r\nmight allow fewer principals in the allow policy.\r\nLimits on groups and domains\r\nUp to 250 of the principals in an allow policy can be Google groups, Cloud Identity domains, or Google\r\nWorkspace accounts.\r\nFor the purposes of this limit, Cloud Identity domains, Google Workspace accounts, and Google groups are\r\ncounted as follows:\r\nFor Google groups, each unique group is counted only once, regardless of how many times the group\r\nappears in the allow policy. This is different from how groups are counted for the limit on the total number\r\nof principals in an allow policy—for that limit, each appearance of a group counts towards the limit.\r\nFor Cloud Identity domains or Google Workspace accounts, IAM counts all appearances of each domain or\r\naccount in the allow policy's role bindings. It does not deduplicate domains or accounts that appear in more\r\nthan one role binding.\r\nFor example, if your allow policy contains only one group, group:my-group@example.com , and the group appears\r\nin the allow policy 10 times, then you can add another 249 Cloud Identity domains, Google Workspace accounts,\r\nor unique groups before you reach the limit.\r\nAlternatively, if your allow policy contains only one domain, domain:example.com , and the domain appears in\r\nthe allow policy 10 times, then you can add another 240 Cloud Identity domains, Google Workspace accounts, or\r\nunique groups before you reach the limit.\r\nPolicy metadata\r\nThe metadata for an allow policy includes the following fields:\r\nAn etag field, which is used for concurrency control, and ensures that allow policies are updated\r\nconsistently. For details, see Using etags in a policy on this page.\r\nA version field, which specifies the schema version for a given allow policy. For details, see Policy\r\nversions on this page.\r\nFor organizations, folders, projects, and billing accounts, the allow policy can also contain an auditConfig field,\r\nwhich specifies the types of activity that generate audit logs for each service. To learn how to configure this part of\r\nan allow policy, see Configuring Data Access audit logs.\r\nhttps://cloud.google.com/iam/docs/policies\r\nPage 2 of 17\n\nUsing etags in a policy\r\nWhen multiple systems try to write to the same allow policy at the same time, there is a risk that those systems\r\nmight overwrite each other's changes. This risk exists because allow policies are updated using the read-modify-write pattern, which involves multiple operations:\r\n1. Reading the existing allow policy\r\n2. Modifying the allow policy\r\n3. Writing the entire allow policy\r\nIf System A reads an allow policy, and System B immediately writes an updated version of that allow policy, then\r\nSystem A will not be aware of the changes from System B. When System A writes its own changes to the allow\r\npolicy, System B's changes could be lost.\r\nTo help prevent this issue, Identity and Access Management (IAM) supports concurrency control through the use\r\nof an etag field in the allow policy. Every allow policy contains an etag field, and the value of this field\r\nchanges each time an allow policy is updated. If an allow policy contains an etag field, but no role bindings,\r\nthen the allow policy does not grant any IAM roles.\r\nThe etag field contains a value such as BwUjMhCsNvY= . When you update the allow policy, be sure to include\r\nthe etag field in the updated allow policy. If the allow policy has been modified since you retrieved it, the\r\netag value will not match, and the update will fail. For the REST API, you receive the HTTP status code 409\r\nConflict , and the response body is similar to the following:\r\n{\r\n \"error\": {\r\n \"code\": 409,\r\n \"message\": \"There were concurrent policy changes. Please retry the whole read-modify-write with exponential\r\n \"status\": \"ABORTED\"\r\n }\r\n}\r\nIf you receive this error, retry the entire series of operations: read the allow policy again, modify it as needed, and\r\nwrite the updated allow policy. You should perform retries automatically, with exponential backoff, in any tools\r\nthat you use to manage allow policies.\r\nExample: Simple policy\r\nConsider the following allow policy that binds a principal to a role:\r\n{\r\n \"bindings\": [\r\n {\r\n \"members\": [\r\nhttps://cloud.google.com/iam/docs/policies\r\nPage 3 of 17\n\n\"user:jie@example.com\"\r\n ],\r\n \"role\": \"roles/owner\"\r\n }\r\n ],\r\n \"etag\": \"BwUjMhCsNvY=\",\r\n \"version\": 1\r\n}\r\nIn the preceding example, Jie is granted the Owner basic role without any conditions. This role gives Jie almost\r\nunlimited access.\r\nExample: Policy with multiple role bindings\r\nConsider the following allow policy that contains more than one role binding. Each role binding grants a different\r\nrole:\r\n{\r\n \"bindings\": [\r\n {\r\n \"members\": [\r\n \"user:jie@example.com\"\r\n ],\r\n \"role\": \"roles/resourcemanager.organizationAdmin\"\r\n },\r\n {\r\n \"members\": [\r\n \"user:raha@example.com\",\r\n \"user:jie@example.com\"\r\n ],\r\n \"role\": \"roles/resourcemanager.projectCreator\"\r\n }\r\n ],\r\n \"etag\": \"BwUjMhCsNvY=\",\r\n \"version\": 1\r\n}\r\nIn the preceding example, Jie is granted the Organization Admin predefined role\r\n( roles/resourcemanager.organizationAdmin ) in the first role binding. This role contains permissions for\r\norganizations, folders, and limited projects operations. In the second role binding, both Jie and Raha are granted\r\nthe ability to create projects by the Project Creator role ( roles/resourcemanager.projectCreator ). Together,\r\nthese role bindings grant fine-grained access to both Jie and Raha, and Jie is granted more access than Raha.\r\nhttps://cloud.google.com/iam/docs/policies\r\nPage 4 of 17\n\nExample: Policy with conditional role binding\r\nConsider the following allow policy, which binds principals to a predefined role and uses a condition expression to\r\nconstrain the role binding:\r\n{\r\n \"bindings\": [\r\n {\r\n \"members\": [\r\n \"group:prod-dev@example.com\",\r\n \"serviceAccount:prod-dev-example@appspot.gserviceaccount.com\"\r\n ],\r\n \"role\": \"roles/appengine.deployer\",\r\n \"condition\": {\r\n \"title\": \"Expires_July_1_2022\",\r\n \"description\": \"Expires on July 1, 2022\",\r\n \"expression\":\r\n \"request.time \u003c timestamp('2022-07-01T00:00:00.000Z')\"\r\n }\r\n }\r\n ],\r\n \"etag\": \"BwWKmjvelug=\",\r\n \"version\": 3\r\n}\r\nIn this example, the version field is set to 3 , because the allow policy contains a condition expression. The\r\nrole binding in the allow policy is conditional; it grants the role to the prod-dev group and the service account\r\nprod-dev-example@appspot.gserviceaccount.com , but only until July 1, 2022.\r\nFor details about the features that each allow policy version supports, see Policy versions on this page.\r\nExample: Policy with conditional and unconditional role bindings\r\nConsider the following allow policy, which contains both conditional and unconditional role bindings for the same\r\nrole:\r\n{\r\n \"bindings\": [\r\n {\r\n \"members\": [\r\n \"serviceAccount:prod-dev-example@appspot.gserviceaccount.com\"\r\n ],\r\n \"role\": \"roles/appengine.deployer\"\r\n },\r\n {\r\n \"members\": [\r\nhttps://cloud.google.com/iam/docs/policies\r\nPage 5 of 17\n\n\"group:prod-dev@example.com\",\r\n \"serviceAccount:prod-dev-example@appspot.gserviceaccount.com\"\r\n ],\r\n \"role\": \"roles/appengine.deployer\",\r\n \"condition\": {\r\n \"title\": \"Expires_July_1_2022\",\r\n \"description\": \"Expires on July 1, 2022\",\r\n \"expression\":\r\n \"request.time \u003c timestamp('2022-07-01T00:00:00.000Z')\"\r\n }\r\n }\r\n ],\r\n \"etag\": \"BwWKmjvelug=\",\r\n \"version\": 3\r\n}\r\nIn this example, the service account serviceAccount:prod-dev-example@appspot.gserviceaccount.com is\r\nincluded in two role bindings for the same role. The first role binding does not have a condition. The second role\r\nbinding has a condition that only grants the role until July 1, 2022.\r\nEffectively, this allow policy always grants the role to the service account. In IAM, conditional role bindings don't\r\noverride role bindings with no conditions. If a principal is bound to a role, and the role binding does not have a\r\ncondition, then the principal always has that role. Adding the principal to a conditional role binding for the same\r\nrole has no effect.\r\nIn contrast, the prod-dev group is included only in the conditional role binding. Therefore, it has the role only\r\nbefore July 1, 2022.\r\nExample: Policy that binds a role to a deleted principal\r\nConsider the following allow policy. This allow policy binds a role to a service account, serviceAccount:my-service-account@my-project.iam.gserviceaccount.com , which was deleted. As a result, the service account's\r\nidentifier now has a deleted: prefix:\r\n{\r\n \"bindings\": [\r\n {\r\n \"members\": [\r\n \"deleted:serviceAccount:my-service-account@my-project.iam.gserviceaccount.com?uid=123456789012345678901\"\r\n ],\r\n \"role\": \"roles/owner\"\r\n }\r\n ],\r\n \"etag\": \"BwUjMhCsNvY=\",\r\n \"version\": 1\r\nhttps://cloud.google.com/iam/docs/policies\r\nPage 6 of 17\n\n}\r\nIf you create a new service account with the same name, the allow policy's role bindings for the deleted service\r\naccount don't apply to the new service account. This behavior applies for all types of deleted principals.\r\nThis behavior prevents new principals from inheriting roles that were granted to deleted principals. If you want to\r\ngrant roles to the new principal, add the new principal to the allow policy's role bindings, as shown in Policies\r\nwith deleted principals on this page.\r\nAll deleted principals have the prefix deleted: . Some types of deleted principals, like service accounts, also\r\nhave the suffix ?uid=numeric-id , where numeric-id is the deleted principal's unique numeric ID. In this\r\nexample, instead of serviceAccount:serviceAccount:my-service-account@my-project.iam.gserviceaccount.com , the allow policy shows the identifier deleted:serviceAccount:my-service-account@my-project.iam.gserviceaccount.com?uid=123456789012345678901 .\r\nDefault policies\r\nAll resources that accept allow policies are created with default allow policies. Most resources' default allow\r\npolicies are empty. However, some resources' default allow policies automatically contain certain role bindings.\r\nFor example, when you create a new project, the allow policy for the project automatically has a role binding that\r\ngrants you the Owner role ( roles/owner ) on the project.\r\nThese role bindings are created by the system, so the user doesn't need getIamPolicy or setIamPolicy\r\npermissions on the resource for the role bindings to be created.\r\nTo learn if a resource is created with an allow policy, refer to the resource's documentation.\r\nPolicy inheritance and the resource hierarchy\r\nGoogle Cloud resources are organized hierarchically, where the organization node is the root node in the\r\nhierarchy, then optionally folders, then projects. Most of other resources are created and managed under a project.\r\nEach resource has exactly one parent, except the organization. The organization, as the root node in the hierarchy,\r\nhas no parent. See the Resource Hierarchy topic for more information.\r\nThe resource hierarchy is important to consider when setting an allow policy. When setting an allow policy at a\r\nhigher level in the hierarchy, such as at the organization level, folder level, or project level, the granted access\r\nscope includes the resource level where this allow policy is attached to and all resources under that level. For\r\nexample, an allow policy set at the organization level applies to the organization and all resources under the\r\norganization. Similarly, an allow policy set at the project level applies to the project and all resources in the\r\nproject.\r\nPolicy inheritance is the term that describes how allow policies apply to resources beneath their level in the\r\nresource hierarchy. Effective policy is the term that describes how all parent allow policies in the resource\r\nhierarchy are inherited for a resource. It is the union of the following:\r\nhttps://cloud.google.com/iam/docs/policies\r\nPage 7 of 17\n\nThe allow policy set on the resource\r\nThe allow policies set on all of resource's ancestry resource levels in the hierarchy\r\nEach new role binding (inherited from parent resources) that affect the resource's effective allow policy are\r\nevaluated independently. A specific access request to the resource is granted if any of the higher-level role\r\nbindings grant access to the request.\r\nIf a new role binding is introduced to any level of a resource's inherited allow policy, the access grant scope\r\nincreases.\r\nExample: Policy inheritance\r\nTo understand allow policy inheritance, consider a scenario where you grant a user, Raha, two different IAM roles\r\nat two different levels in the resource hierarchy.\r\nTo grant Raha a role at the organization level, you set the following allow policy on your organization:\r\n{\r\n \"bindings\": [\r\n {\r\n \"members\": [\r\n \"user:raha@example.com\"\r\n ],\r\n \"role\": \"roles/storage.objectViewer\"\r\n }\r\n ],\r\n \"etag\": \"BwUjMhCsNvY=\",\r\n \"version\": 1\r\n}\r\nThis allow policy grants Raha the Storage Object Viewer role ( roles/storage.objectViewer ), which contains\r\nget and list permissions for projects and Cloud Storage objects. Because you set the allow policy on your\r\norganization, Raha can use these permissions for all projects and all Cloud Storage objects in your organization.\r\nTo grant Raha a role at the project level, you set the following allow policy on the project myproject-123 :\r\n{\r\n \"bindings\": [\r\n {\r\n \"members\": [\r\n \"user:raha@example.com\"\r\n ],\r\n \"role\": \"roles/storage.objectCreator\"\r\n }\r\n ],\r\nhttps://cloud.google.com/iam/docs/policies\r\nPage 8 of 17\n\n\"etag\": \"BwUjMhCsNvY=\",\r\n \"version\": 1\r\n}\r\nThis allow policy grants Raha the Storage Object Creator role ( roles/storage.objectCreator ), which lets them\r\ncreate Cloud Storage objects. Because you set the allow policy on myproject-123 , Raha can create Cloud\r\nStorage objects only in myproject-123 .\r\nNow that there are two role bindings that grant Raha access to the target Cloud Storage objects under myproject-123 , the following allow policies apply:\r\nAn allow policy at the organization level grants the ability to list and get all Cloud Storage objects under\r\nthis organization.\r\nAn allow policy at the project level, for the project myproject-123 , grants the ability to create objects\r\nwithin that project.\r\nThe following table summarizes Raha's effective policy:\r\nPermissions from the Storage\r\nObject Viewer role on the\r\norganization\r\nPermissions from the Storage\r\nObject Creator role on\r\n`myproject-123`\r\nEffective permissions for\r\nRaha on `myproject-123`\r\nresourcemanager.projects.get\r\nresourcemanager.projects.list\r\nstorage.objects.get\r\nstorage.objects.list\r\nresourcemanager.projects.get\r\nresourcemanager.projects.list\r\nstorage.objects.create\r\nresourcemanager.projects.get\r\nresourcemanager.projects.list\r\nstorage.objects.get\r\nstorage.objects.list\r\nstorage.objects.create\r\nPolicy versions\r\nOver time, IAM might add new features that significantly add or change fields in the allow policy schema. To\r\navoid breaking your existing integrations that rely on consistency in the allow policy structure, such changes are\r\nintroduced in new allow policy schema versions.\r\nIf you are integrating with IAM for the first time, we recommend using the most recent allow policy schema\r\nversion available at that time. The following section discusses the different versions available and how to use\r\neach. It also describes how to specify a policy version and discusses some troubleshooting scenarios.\r\nEvery existing allow policy specifies a version field as part of the allow policy's metadata. Consider the\r\nhighlighted portion of the following sample:\r\n{\r\n \"bindings\": [\r\n {\r\nhttps://cloud.google.com/iam/docs/policies\r\nPage 9 of 17\n\n\"members\": [\r\n \"user:jie@example.com\"\r\n ],\r\n \"role\": \"roles/owner\"\r\n }\r\n ],\r\n \"etag\": \"BwUjMhCsNvY=\",\r\n \"version\": 1\r\n}\r\nThis field specifies the syntax schema version of the allow policy. Each version of the allow policy contains a\r\nspecific syntax schema that can be used by role bindings. The newer version can contain role bindings with the\r\nnewer syntax schema that is unsupported by earlier versions. This field is not intended to be used for any purposes\r\nother than controlling the syntax schema for the allow policy.\r\nValid policy versions\r\nAllow policies can use the following allow policy versions:\r\nVersion Description\r\n1\r\nThe first version of the IAM syntax schema for policies. Supports binding one role to one or more\r\nprincipals. Does not support conditional role bindings.\r\n2 Reserved for internal use.\r\n3\r\nIntroduces the condition field in the role binding, which constrains the role binding using\r\ncontext-based and attribute-based rules. For more information, see the overview of IAM\r\nConditions.\r\nSpecifying a policy version when getting a policy\r\nFor the REST API and client libraries, when you get an allow policy, we recommend that you specify an allow\r\npolicy version in the request. When a request specifies an allow policy version, IAM assumes that the caller is\r\naware of the features in that allow policy version and can handle them correctly.\r\nIf the request does not specify an allow policy version, IAM assumes that the caller wants a version 1 allow\r\npolicy.\r\nWhen you get an allow policy, IAM checks the allow policy version in the request, or the default version if the\r\nrequest did not specify a version. IAM also checks the allow policy for fields that are not supported in a version\r\n1 allow policy. It uses this information to decide what type of response to send:\r\nIf the allow policy does not contain any conditions, then IAM always returns a version 1 allow policy,\r\nregardless of the version number in the request.\r\nhttps://cloud.google.com/iam/docs/policies\r\nPage 10 of 17\n\nIf the allow policy contains conditions, and the caller requested a version 3 allow policy, then IAM\r\nreturns a version 3 allow policy that includes the conditions. For an example, see scenario 1 on this page.\r\nIf the allow policy contains conditions, and the caller requested a version 1 allow policy or did not\r\nspecify a version, then IAM returns a version 1 allow policy.\r\nFor role bindings that include a condition, IAM appends the string _withcond_ to the role name, followed\r\nby a hash value; for example, roles/iam.serviceAccountAdmin_withcond_2b17cc25d2cd9e2c54d8 . The\r\ncondition itself is not present. For an example, see scenario 2 on this page.\r\nScenario 1: Policy version that fully supports IAM Conditions\r\nSuppose you call the following REST API method to get the allow policy for a project:\r\nPOST https://cloudresourcemanager.googleapis.com/v1/projects/project-id:getIamPolicy\r\nThe request body contains the following text:\r\n{\r\n \"options\": {\r\n \"requestedPolicyVersion\": 3\r\n }\r\n}\r\nThe response contains the project's allow policy. If the allow policy contains at least one conditional role binding,\r\nits version field is set to 3 :\r\n{\r\n \"bindings\": [\r\n {\r\n \"members\": [\r\n \"user:tal@example.com\"\r\n ],\r\n \"role\": \"roles/iam.securityReviewer\",\r\n \"condition\": {\r\n \"title\": \"Expires_July_1_2022\",\r\n \"description\": \"Expires on July 1, 2022\",\r\n \"expression\": \"request.time \u003c timestamp('2022-07-01T00:00:00.000Z')\"\r\n }\r\n }\r\n ],\r\n \"etag\": \"BwWKmjvelug=\",\r\nhttps://cloud.google.com/iam/docs/policies\r\nPage 11 of 17\n\n\"version\": 3\r\n}\r\nIf the allow policy does not contain conditional role bindings, its version field is set to 1 , even though the\r\nrequest specified version 3 :\r\n{\r\n \"bindings\": [\r\n {\r\n \"members\": [\r\n \"user:tal@example.com\"\r\n ],\r\n \"role\": \"roles/iam.securityReviewer\",\r\n }\r\n ],\r\n \"etag\": \"BwWKmjvelug=\",\r\n \"version\": 1\r\n}\r\nScenario 2: Policy version with limited support for IAM Conditions\r\nSuppose you call the following REST API method to get the allow policy for a project:\r\nPOST https://cloudresourcemanager.googleapis.com/v1/projects/project-id:getIamPolicy\r\nThe request body is empty; it does not specify a version number. As a result, IAM uses the default allow policy\r\nversion, 1 .\r\nThe allow policy contains a conditional role binding. Because the allow policy version is 1 , the condition does\r\nnot appear in the response. To indicate that the role binding uses a condition, IAM appends the string\r\n_withcond_ to the role name, followed by a hash value:\r\n{\r\n \"bindings\": [\r\n {\r\n \"members\": [\r\n \"user:tal@example.com\"\r\n ],\r\n \"role\": \"roles/iam.securityReviewer_withcond_58e135cabb940ad9346c\"\r\n }\r\n ],\r\n \"etag\": \"BwWKmjvelug=\",\r\nhttps://cloud.google.com/iam/docs/policies\r\nPage 12 of 17\n\n\"version\": 1\r\n}\r\nSpecifying a policy version when setting a policy\r\nWhen you set an allow policy, we recommend that you specify an allow policy version in the request. When a\r\nrequest specifies an allow policy version, IAM assumes that the caller is aware of the features in that allow policy\r\nversion and can handle them correctly.\r\nIf the request does not specify an allow policy version, IAM accepts only the fields that can appear in a version\r\n1 allow policy. As a best practice, don't change conditional role bindings in a version 1 allow policy; because\r\nthe allow policy does not show the condition for each role binding, you don't know when or where the role\r\nbinding is actually granted. Instead, get the version 3 representation of the allow policy, which shows the\r\ncondition for each role binding, and use that representation to update the role bindings.\r\nScenario: Policy versions in requests and responses\r\nSuppose you use the REST API to get an allow policy, and you specify version 3 in the request. The response\r\ncontains the following allow policy, which uses version 3 :\r\n{\r\n \"bindings\": [\r\n {\r\n \"members\": [\r\n \"user:raha@example.com\"\r\n ],\r\n \"role\": \"roles/storage.admin\",\r\n \"condition\": {\r\n \"title\": \"Weekday_access\",\r\n \"description\": \"Monday thru Friday access only in America/Chicago\",\r\n \"expression\": \"request.time.getDayOfWeek('America/Chicago') \u003e= 1 \u0026\u0026 request.time.getDayOfWeek('America\r\n }\r\n }\r\n ],\r\n \"etag\": \"BwUjMhCsNvY=\",\r\n \"version\": 3\r\n}\r\nYou decide that Raha should have the Storage Admin role ( roles/storage.admin ) throughout the week, not just\r\non weekdays. You remove the condition from the role binding and send a REST API request to set the allow\r\npolicy; once again, you specify version 3 in the request:\r\n{\r\n \"bindings\": [\r\n {\r\nhttps://cloud.google.com/iam/docs/policies\r\nPage 13 of 17\n\n\"members\": [\r\n \"user:raha@example.com\"\r\n ],\r\n \"role\": \"roles/storage.admin\"\r\n }\r\n ],\r\n \"etag\": \"BwUjMhCsNvY=\",\r\n \"version\": 3\r\n}\r\nThe response contains the updated allow policy:\r\n{\r\n \"bindings\": [\r\n {\r\n \"members\": [\r\n \"user:raha@example.com\"\r\n ],\r\n \"role\": \"roles/storage.admin\"\r\n }\r\n ],\r\n \"etag\": \"BwWd8I+ZUAQ=\",\r\n \"version\": 1\r\n}\r\nThe allow policy in the response uses version 1 , even though the request specified version 3 , because the\r\nallow policy uses only fields that are supported in a version 1 allow policy.\r\nPolicies with deleted principals\r\nIf a role binding in an allow policy includes a deleted principal, and you add a role binding for a new principal\r\nwith the same name, the role binding is always applied to the new principal.\r\nFor example, consider this allow policy that includes a role binding for a deleted service account, my-service-account@project-id.iam.gserviceaccount.com . As a result, the identifier for each the service account has a\r\ndeleted: prefix:\r\n{\r\n \"bindings\": [\r\n {\r\n \"members\": [\r\n \"deleted:serviceAccount:my-service-account@project-id.iam.gserviceaccount.com?uid=123456789012345678901\"\r\n ],\r\n \"role\": \"roles/owner\"\r\nhttps://cloud.google.com/iam/docs/policies\r\nPage 14 of 17\n\n}\r\n ],\r\n \"etag\": \"BwUjMhCsNvY=\",\r\n \"version\": 1\r\n}\r\nSuppose you create a new service account that is also named my-service-account@project-id.iam.gserviceaccount.com , and you want to grant it the Project Creator role\r\n( roles/resourcemanager.projectCreator ). To grant the role to the new service account, update the allow policy\r\nas shown in this example:\r\n{\r\n \"bindings\": [\r\n {\r\n \"members\": [\r\n \"deleted:serviceAccount:my-service-account@project-id.iam.gserviceaccount.com?uid=12345678901\r\n ],\r\n \"role\": \"roles/owner\"\r\n },\r\n {\r\n \"members\": [\r\n \"serviceAccount:my-service-account@project-id.iam.gserviceaccount.com\"\r\n ],\r\n \"role\": \"roles/resourcemanager.projectCreator\"\r\n }\r\n ],\r\n \"etag\": \"BwUjMhCsNvY=\",\r\n \"version\": 1\r\n}\r\nTo make it easier to audit your IAM allow policies, you can also remove the deleted user from the role binding to\r\nthe Owner role:\r\n{\r\n \"bindings\": [\r\n {\r\n \"members\": [\r\n \"deleted:serviceAccount:my-service-account@project-id.iam.gserviceaccount.com?uid=12345678901\r\n ],\r\n \"role\": \"roles/owner\"\r\n },\r\n {\r\n \"members\": [\r\n \"user:donald@example.com\"\r\nhttps://cloud.google.com/iam/docs/policies\r\nPage 15 of 17\n\n],\r\n \"role\": \"roles/resourcemanager.projectCreator\"\r\n }\r\n ],\r\n \"etag\": \"BwUjMhCsNvY=\",\r\n \"version\": 1\r\n}\r\nPolicy best practices\r\nThe following best practices apply to organizations with many Google Cloud users:\r\nWhen managing multiple principals with the same access configurations, use groups instead. Put each\r\nindividual principal into the group, and grant the intended roles to the group instead of individual user\r\naccounts principals.\r\nRoles granted at the organization level: Carefully consider which principals are granted roles at the\r\norganization level. For most organizations, only a few specific teams, such as Security and Network teams,\r\nshould be granted access at this level of the resource hierarchy.\r\nRoles granted at the folder levels: Consider reflecting your organization's operation structure by using\r\ntiers of folders, where each folder can be configured with different sets of access grants that are aligned\r\nwith business and operation needs. For example, a parent folder might reflect a department, one of its child\r\nfolder might reflect resource access and operation by a group, and another child folder might reflect a small\r\nteam. Both of these two folders might contain projects for their team's operation needs. Using folders in\r\nthis way can ensure proper access separation, while respecting allow policies inherited from parent folders\r\nand the organization. This practice requires less maintenance of allow policies when creating and managing\r\nGoogle Cloud resources.\r\nRoles granted at the project level: Grant role bindings at the project level when necessary to follow the\r\nprinciple of least privilege. For example, if a principal needs access to 3 of the 10 projects in a folder, you\r\nshould grant access to each of the 3 projects individually; in contrast, if you granted a role on the folder, the\r\nprincipal would gain access that they don't need to another 7 projects.\r\nAlternatively, you can use IAM Conditions to grant roles at the organization or folder level, but only for a\r\nsubset of folders or projects.\r\nOnly grant access to principals within your domain: To improve your organization's security, don't grant\r\nroles to principals outside of your domain. You can enforce this best practice by enforcing the\r\niam.allowedPolicyMemberDomains organization policy constraint.\r\nWhat's next\r\nLearn how to troubleshoot allow policies that contain the string withcond in role names.\r\nFind out how to manage the role bindings in an allow policy.\r\nhttps://cloud.google.com/iam/docs/policies\r\nPage 16 of 17\n\nGet an overview of IAM Conditions, which use version 3 allow policies.\r\nExplore the Policy Intelligence tools, which help you understand and manage your allow policies to\r\nproactively improve your security configuration.\r\nUse the Cloud Asset API to search allow policies.\r\nUse the Cloud Asset API to view effective allow policies.\r\nSource: https://cloud.google.com/iam/docs/policies\r\nhttps://cloud.google.com/iam/docs/policies\r\nPage 17 of 17",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE"
	],
	"references": [
		"https://cloud.google.com/iam/docs/policies"
	],
	"report_names": [
		"policies"
	],
	"threat_actors": [],
	"ts_created_at": 1775433991,
	"ts_updated_at": 1775791238,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/05355317e9ac9c56d1bbff8bc0617bbd0803b0b9.pdf",
		"text": "https://archive.orkl.eu/05355317e9ac9c56d1bbff8bc0617bbd0803b0b9.txt",
		"img": "https://archive.orkl.eu/05355317e9ac9c56d1bbff8bc0617bbd0803b0b9.jpg"
	}
}