{
	"id": "b24a4ad9-9076-4f3e-8c8e-d8e9f04c3b01",
	"created_at": "2026-04-06T01:30:05.357527Z",
	"updated_at": "2026-04-10T03:20:44.928768Z",
	"deleted_at": null,
	"sha1_hash": "3e0453302abd932a3cf29df8f4a2102b619e42b4",
	"title": "Overview of IAM Conditions",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 122276,
	"plain_text": "Overview of IAM Conditions\r\nArchived: 2026-04-06 00:34:56 UTC\r\nThis page describes the Conditions feature of Identity and Access Management (IAM). You can use IAM\r\nConditions to define and enforce conditional, attribute-based access control for Google Cloud resources.\r\nConditions and policy types\r\nYou can use conditions in the following places:\r\nAllow policy role bindings, including role bindings managed by Privileged Access Manager entitlements\r\nDeny policy rules\r\nPolicy bindings for principal access boundary policies\r\nThe following sections describe how you can use conditions in each of these places to enforce attribute-based\r\naccess control.\r\nConditions in allow policies\r\nYou can use conditions in allow policies to choose to grant access to principals only if specified conditions are\r\nmet. For example, you could grant temporary access to users so they can resolve a production issue, or you could\r\ngrant access only to employees making requests from your corporate network.\r\nConditions are specified in the role bindings of a resource's allow policy. If a role binding has a condition, then the\r\nprincipals in the role are only granted the role if the condition expression evaluates to true .\r\nTo add a condition to a role binding, you define the condition field:\r\n\"bindings\": [\r\n {\r\n \"role\": \"ROLE\",\r\n \"members\": [\r\n \"MEMBER_1\",\r\n \"MEMBER_2\"\r\n ],\r\n \"condition\": {\r\n \"title\": \"TITLE\",\r\n \"description\": \"DESCRIPTION\",\r\n \"expression\": \"EXPRESSION\"\r\n }\r\n }\r\n]\r\nhttps://cloud.google.com/iam/docs/conditions-overview\r\nPage 1 of 9\n\nIf you're using Privileged Access Manager entitlements, you can also add conditions to the roles in that\r\nentitlement. When a user successfully requests a grant for that entitlement, they are granted the role with the\r\nspecified condition.\r\nTo learn more about the fields in a condition, see Condition structure on this page.\r\nOnly some resource types accept conditions in role bindings. However, you can grant conditional access to other\r\nresource types by granting roles at the organization or project level.\r\nAs a best practice, don't add more than 100 conditional role bindings to a single allow policy. If you use a larger\r\nnumber of conditional role bindings, you might exceed the overall size limit for allow policies.\r\nTo learn how to add, modify, and remove conditional role bindings, see Managing conditional role bindings.\r\nConditions in deny policies\r\nYou can use conditions in deny policies to apply a deny rule only if a certain condition is met. For example, you\r\ncould deny a permission only if the resource that the principal is trying to access is tagged as a part of the prod\r\nenvironment.\r\nConditions are specified in the deny rules in a resource's deny policies. If the condition evaluates to true or\r\ncannot be evaluated, the deny rule applies and the principals are unable to use the specified permissions. If the\r\ncondition evaluates to false , the deny rule does not apply and the principals can use the specified permissions if\r\nthey have them.\r\nConditions in deny policies have the same structure as conditions in allow policies; however, they only recognize\r\nresource tag functions.\r\nTo add a condition to a deny rule, you define the denialCondition field:\r\n\"rules\": [\r\n {\r\n \"denyRule\": {\r\n \"deniedPrincipals\": [\r\n \"PRINCIPAL_1\",\r\n \"PRINCIPAL_2\"\r\n ],\r\n \"exceptionPrincipals\": [\r\n \"EXCEPTION_PRINCIPAL_1\",\r\n \"EXCEPTION_PRINCIPAL_2\"\r\n ],\r\n \"deniedPermissions\": [\r\n \"DENIED_PERMISSION_1\",\r\n \"DENIED_PERMISSION_2\"\r\n ],\r\n \"denialCondition\": {\r\n \"title\": \"TITLE\",\r\nhttps://cloud.google.com/iam/docs/conditions-overview\r\nPage 2 of 9\n\n\"description\": \"DESCRIPTION\",\r\n \"expression\": \"EXPRESSION\"\r\n }\r\n }\r\n }\r\n]\r\nTo learn more about the fields in a condition, see Condition structure on this page.\r\nTo learn how to create and manage deny policies, see Deny access.\r\nConditions in principal access boundary policy bindings\r\nYou can use conditions in policy bindings for principal access boundary policies to refine the principal set that the\r\nprincipal access boundary policy applies to. For example, you could only enforce a policy for service accounts, or\r\nexempt super-admin@example.com from a policy.\r\nConditions are specified in each policy binding. If a policy binding has a condition, then the policy in the policy\r\nbinding is enforced only if the condition evaluates to true .\r\nTo add a condition to a policy binding, you define the condition field in the policy binding:\r\n{\r\n \"displayName\": \"DISPLAY_NAME\",\r\n \"target\": {\r\n \"principalSet\": \"PRINCIPAL_SET\"\r\n },\r\n \"policyKind\": \"PRINCIPAL_ACCESS_BOUNDARY\",\r\n \"policy\": \"PAB_POLICY\",\r\n \"condition\": {\r\n \"title\": \"TITLE\",\r\n \"description\": \"DESCRIPTION\",\r\n \"expression\": \"EXPRESSION\"\r\n }\r\n}\r\nTo learn more about the fields in a condition, see Condition structure on this page.\r\nTo learn how to create policy bindings for principal access boundary policies, see Apply a principal access\r\nboundary policy to a principal set.\r\nCondition structure\r\nThe condition object has the following structure:\r\nhttps://cloud.google.com/iam/docs/conditions-overview\r\nPage 3 of 9\n\n\"condition\": {\r\n \"title\": ...,\r\n \"description\": ...,\r\n \"expression\": ...\r\n}\r\nThe condition's title is required, but the description is optional. Both the title and description are purely\r\ninformational fields to help you identify and describe the condition.\r\nThe expression field is required. It defines an attribute-based logic expression using a subset of the Common\r\nExpression Language (CEL). The condition expression can contain multiple statements; each statement evaluates\r\none attribute. Statements are combined using logical operators, following the CEL language specification.\r\nCEL for conditions\r\nCommon Expression Language, or CEL, is the expression language used to specify an expression in IAM\r\nConditions. It is tailored to express attribute-based logic expressions. For more information, see the CEL spec and\r\nits language definition.\r\nIn IAM Conditions, a subset of CEL is used to make boolean authorization decisions based on attribute data. In\r\ngeneral, a condition expression consists of one or more statements that are joined by logical operators ( \u0026\u0026 , || ,\r\nor ! ).\r\nEach statement expresses an attribute-based control rule, and ultimately determines whether the role binding, deny\r\nrule, or policy binding applies.\r\nConditions in IAM Conditions use the following CEL features:\r\nVariables: Conditions use variables to express a given attribute, such as request.time (of type\r\nTimestamp) or resource.name (of type String). These variables are populated with value based on the\r\ncontext at runtime.\r\nOperators: Every data type, such as Timestamp or String, supports a set of operators that can be used to\r\ncreate a logic expression. Most commonly, operators are used to compare the value contained in a variable\r\nwith a literal value, such as resource.service == 'compute.googleapis.com' . In this example, if the\r\ninput value of resource.service is compute.googleapis.com , then the expression evaluates to true .\r\nFunctions: A function is a compound operator for data types that support more complex operations. In\r\ncondition expressions, there are predefined functions that can be used with a given data type. For example,\r\nrequest.path.startsWith('/finance') uses a String prefix match function, and evaluates to true if the\r\nvalue of request.path contains a matching prefix, such as /finance .\r\nLogical operators: Conditions supports three logical operators that can be used to build complex logic\r\nexpressions from basic expression statements: \u0026\u0026 , || , and ! . These logical operators make it possible\r\nto use multiple input variables in a condition expression. For example: request.time.getFullYear() \u003c\r\n2020 \u0026\u0026 resource.service == 'compute.googleapis.com' joins two basic statements, and requires both\r\nstatements to be met in order to produce a true overall evaluation result.\r\nhttps://cloud.google.com/iam/docs/conditions-overview\r\nPage 4 of 9\n\nFor more information about supported variables, operators, and functions, see the attribute reference.\r\nCondition attributes\r\nCondition attributes are based on the requested resource—for example, its type or name—or on details about the\r\nrequest—for example, its timestamp or destination IP address.\r\nThe condition attributes that you can use in a condition expression depend on the policy type that you're writing\r\nconditions for. For a full list of condition attributes and more information about the attributes supported for each\r\npolicy type, see the attribute reference.\r\nThe following sections show examples of some of the attributes that you can use in conditions.\r\nResource attributes\r\nYou can use resource attributes to write conditions that evaluate the resource in the access request. The attributes\r\nthat you can evaluate include the following:\r\nThe resource type\r\nThe resource name\r\nThe Google Cloud service being used\r\nThe tags attached to the resource\r\nYou can use any of these attributes in allow policy role bindings. Additionally, you can use the resource tags\r\nattribute in deny policy deny rules.\r\nFor a complete list of resource attributes, see the resource attributes reference.\r\nTo learn how to use resource attributes to configure resource-based access, see Configuring resource-based access.\r\nExample expressions\r\nIn a role binding, the following condition expression allows access to Compute Engine VM instances, but no other\r\ntype of resource:\r\nresource.type == 'compute.googleapis.com/Instance'\r\nIn a role binding, the following condition expression allows access to Cloud Storage resources, but no other\r\nservice's resources:\r\nresource.service == 'storage.googleapis.com'\r\nhttps://cloud.google.com/iam/docs/conditions-overview\r\nPage 5 of 9\n\nIn a role binding, the following condition expression allows access only to Cloud Storage objects inside a specific\r\nbucket:\r\nresource.type == 'storage.googleapis.com/Object' \u0026\u0026\r\nresource.name.startsWith('projects/_/buckets/exampleco-site-assets/')\r\nIn a deny rule, the following condition expression denies access to Google Cloud resources that have the tag env:\r\nprod :\r\nresource.matchTag('123456789012/env', 'prod')\r\nPrincipal attributes\r\nThe principal attributes let you write conditions based on the principal that issued the request. The attributes that\r\nyou can evaluate include the following:\r\nThe type of principal in the request\r\nThe identity of the principal in the request\r\nYou can use these attributes in policy bindings for principal access boundary policies.\r\nFor details, see the conditions attribute reference.\r\nExample expressions\r\nIn a principal access boundary policy binding, the following condition expression ensures that the policy in the\r\nbinding is only enforced for service accounts:\r\nprincipal.type == 'iam.googleapis.com/ServiceAccount'\r\nIn a principal access boundary policy binding, the following condition expression ensures that the policy in the\r\nbinding isn't enforced for super-admin@example.com :\r\nprincipal.subject != 'super-admin@example.com'\r\nRequest attributes\r\nYou can use request attributes to write conditions that evaluate details about the request, such as the following:\r\nThe access level\r\nhttps://cloud.google.com/iam/docs/conditions-overview\r\nPage 6 of 9\n\nThe date and time\r\nThe destination IP address and port (for IAP TCP tunneling)\r\nThe expected URL host or path (for IAP)\r\nYou can use these attributes in allow policy role bindings.\r\nExample access level expression (for IAP only)\r\nIn the following example, your organization defines an access level, CorpNet , that limits access to the range of\r\nIP addresses where traffic enters and exits a corporate network. Then, you add the following condition expression\r\nto a role binding to allow access only if the request meets the CorpNet access level:\r\n'accessPolicies/199923665455/accessLevels/CorpNet' in\r\nrequest.auth.access_levels\r\nYour organization defines access levels based on attributes of the request, such as origin IP address, device\r\nattributes, the time of day, and more. For more details, see the Access Context Manager documentation.\r\nExample API attribute expression\r\nIn a role binding for a role with the iam.projects.setIamPolicy permission, the following condition expression\r\nallows a user to grant and revoke only the Billing Account Administrator ( roles/billing.admin ) role on the\r\nproject:\r\napi.getAttribute('iam.googleapis.com/modifiedGrantsByRole', [])\r\n .hasOnly(['roles/billing.admin'])\r\nTo learn more about using API attributes to limit role granting, see Setting limits on granting roles.\r\nExample date/time expressions\r\nIn a role binding, the following condition expression allows access until midnight on January 1st, 2021:\r\nrequest.time \u003c timestamp('2021-01-01T00:00:00Z')\r\nIn a role binding, the following condition expression allows access only during specified working hours, based on\r\nthe time zone for Berlin, Germany:\r\nrequest.time.getHours('Europe/Berlin') \u003e= 9 \u0026\u0026\r\nrequest.time.getHours('Europe/Berlin') \u003c= 17 \u0026\u0026\r\n// Days of the week range from 0 to 6, where 0 == Sunday and 6 == Saturday.\r\nhttps://cloud.google.com/iam/docs/conditions-overview\r\nPage 7 of 9\n\nrequest.time.getDayOfWeek('Europe/Berlin') \u003e= 1 \u0026\u0026\r\nrequest.time.getDayOfWeek('Europe/Berlin') \u003c= '\r\nIn a role binding, the following condition expression allows access only for June of 2020, based on the time zone\r\nfor Berlin, Germany:\r\nrequest.time.getFullYear('Europe/Berlin') == 2020\r\nrequest.time.getMonth('Europe/Berlin') \u003c 6\r\nTo specify a timestamp, use RFC 3339 format. To specify a time zone, use the identifiers in the IANA Time Zone\r\nDatabase.\r\nFor more details about date/time expressions, see the CEL specification.\r\nTo learn how to use date/time expressions to configure temporary access, see Configuring temporary access.\r\nExample destination IP and port expressions (for IAP TCP tunneling)\r\nIn a role binding, the following condition expression allows access to an internal destination IP address or port\r\nnumber:\r\ndestination.ip == '14.0.0.1'\r\ndestination.ip != '127.0.0.1'\r\ndestination.port == 22\r\ndestination.port \u003e 21 \u0026\u0026 destination.port \u003c= 23\r\nExample forwarding rule expressions\r\nIn a role binding, the following condition expression allows access for a principal if the request is not creating a\r\nforwarding rule, or if the request is creating a forwarding rule for an internal Google Cloud load balancer:\r\n!compute.isForwardingRuleCreationOperation() || (\r\n compute.isForwardingRuleCreationOperation() \u0026\u0026\r\n compute.matchLoadBalancingSchemes([\r\n 'INTERNAL', 'INTERNAL_MANAGED', 'INTERNAL_SELF_MANAGED'\r\n ])\r\n)\r\nFor details about load-balancing schemes, see Using IAM Conditions on Google Cloud load balancers.\r\nhttps://cloud.google.com/iam/docs/conditions-overview\r\nPage 8 of 9\n\nExample URL host or path expressions (for IAP)\r\nIn a role binding, the following condition expression allows access only for certain subdomains or URL paths in\r\nthe request:\r\nrequest.host == 'hr.example.com'\r\nrequest.host.endsWith('.example.com')\r\nrequest.path == '/admin/payroll.js'\r\nrequest.path.startsWith('/admin')\r\nExample expression with different types of attributes\r\nIn a role binding, the following condition expression allows access if the request is made during a specific time,\r\nmatching a resource name prefix, with the chosen access level, and for a specific resource type:\r\nrequest.time \u003e timestamp('2018-08-03T16:00:00-07:00') \u0026\u0026\r\nrequest.time \u003c timestamp('2018-08-03T16:05:00-07:00') \u0026\u0026\r\n((resource.name.startsWith('projects/project-123/zones/us-east1-b/instances/dev') ||\r\n (resource.name.startsWith('projects/project-123/zones/us-east1-b/instances/prod') \u0026\u0026\r\n 'accessPolicies/34569256/accessLevels/CorpNet' in request.auth.access_levels)) ||\r\n resource.type != 'compute.googleapis.com/Instance')\r\nWhat's next\r\nGet details about the condition attributes that you can use to manage access.\r\nLearn more about allow policies.\r\nFind resource types that accept conditional role bindings.\r\nSource: https://cloud.google.com/iam/docs/conditions-overview\r\nhttps://cloud.google.com/iam/docs/conditions-overview\r\nPage 9 of 9\n\nrequest.time.getHours('Europe/Berlin') request.time.getHours('Europe/Berlin')  \u003e= 9 \u003c= 17 \u0026\u0026 \u0026\u0026 \n// Days of the week range from 0 to 6, where 0 == Sunday and 6 == Saturday.\n   Page 7 of 9",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE"
	],
	"references": [
		"https://cloud.google.com/iam/docs/conditions-overview"
	],
	"report_names": [
		"conditions-overview"
	],
	"threat_actors": [],
	"ts_created_at": 1775439005,
	"ts_updated_at": 1775791244,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/3e0453302abd932a3cf29df8f4a2102b619e42b4.pdf",
		"text": "https://archive.orkl.eu/3e0453302abd932a3cf29df8f4a2102b619e42b4.txt",
		"img": "https://archive.orkl.eu/3e0453302abd932a3cf29df8f4a2102b619e42b4.jpg"
	}
}