You are currently viewing How To Create And Manage Cloud IAM Policy In GCP

How To Create And Manage Cloud IAM Policy In GCP

How To Create And Manage Cloud IAM Policy In GCP

Hello Everyone

Welcome to CloudAffaire and this is Debjeet.

In the last blog post, we have discussed the service account in GCP.

In this blog post, we are going to discuss Cloud IAM Policy in GCP.

What is Cloud IAM Policy?

Access control for Google Cloud resources is managed by Cloud IAM policies. A Cloud IAM policy is attached to a resource, and restricts access to both the resource itself as well as any child resources through policy inheritance.

Policy structure:

A policy is a collection of bindings, audit configuration, and metadata. A binding specifies how access should be granted on resources. It associates (or binds) one or more members with a single role and any context-specific conditions that change how and when the role is granted. The AuditConfig field specifies the configuration data for how access attempts should be audited. The metadata includes additional information about the policy, such as an etag and version to facilitate policy management.

  • bindings: A binding specifies how access should be granted on resources.
    • member: A member, also known as an identity or principal, can be a user account, service account, Google group, or domain
    • role: A role is a named collection of permissions that grant access to perform actions on Google Cloud resources.
    • condition: A condition is a logic expression that further constrains the role binding based on attributes about the request, such as its origin, the target resource, and so on.
  • AuditConfig: An AuditConfig field, which is used to configure audit logging for the policy.
  • metadata: includes additional information about the policy, such as an etag and version to facilitate policy management.
    • etag: An etag field, which is used for concurrency control, and ensures that policies are updated consistently.
    • version: A version field, which specifies the schema version for a given policy.

Policy etags:

When you have multiple systems trying to write to the same Cloud IAM policy at the same time, there is a risk that those systems might overwrite each other’s changes. This risk arises because modifying an Cloud IAM policy involves three operations: retrieving the current policy, modifying its content as desired, and then setting the new policy in its entirety. If two systems are doing this at once, it is possible that one of those systems will set an updated policy not realizing that the policy had been changed between when it was initially retrieved and now.

To avoid such scenarios, Cloud IAM supports concurrency control through the use of an etag field in the policy. Whenever you retrieve a policy, be sure that you use the etag from the retrieved policy when you submit your modified policy. If the policy has been modified since you retrieved it, the etag will not match and your update will fail. When this occurs, retry the entire operation: retrieve the policy again, apply your modifications, and submit the updated policy. We recommend that you perform this retry logic automatically in any code or scripts that you use to manage Cloud IAM policies.

Policy limitations:

  • Every Google Cloud resource that supports a Cloud IAM policy at its level in the resource hierarchy can have a maximum of one policy. For example, organizations, folders, projects, or individual resources (such as Compute Engine disks, images, and more).
  • Each policy can contain up to a total of 1,500 members across all of its bindings, regardless of the member types. In addition, the Google Group member type is limited to 250 across all role bindings in one policy.
  • In general, any policy changes will take effect within 60 seconds after either calling setIamPolicy() or by updating a role binding in the Cloud Console. However, under certain circumstances, it may take up to 7 minutes for policy changes to fully propagate across the system.
  • Some GCP services do not currently support resource-level conditional policies. For example, a conditional policy that constrains access to a service’s resource can be set on the project, but a conditional policy set on the resource itself is not supported.

Policy inheritance:

The resource hierarchy is important to consider when setting Cloud IAM policy. When setting a policy at a higher level in the hierarchy, such as at the organization level, folder level, or project level, the granted access scope includes the resource level where this policy is attached to and all resources under that level. For example, a policy set at the organization level applies to the organization and all resources under the organization. Similarly, a policy set at the project level applies to the project and all resources in the project.

Policy inheritance is the term that describes how policies apply to resources beneath their level in the resource hierarchy. Effective policy is the term that describes how all parent policies in the resource hierarchy are inherited for a resource. It is the union of:

  • The policy set on the resource, and
  • The policies set on all of resource’s ancestry resource levels in the hierarchy

Each new role binding (inherited from parent resources) that affect the resource’s effective policy are evaluated independently. A specific access request to the resource is granted if any of the higher-level role bindings grant access to the request.

Policy versions:

Over time, Cloud IAM may add new features that significantly add or change fields in the policy schema. To avoid breaking your existing integrations that rely on consistency in the policy structure, such changes are introduced in new policy schema versions. Every existing Cloud IAM policy specifies a version field as part of the policy’s metadata.

Policy versions feild specifies the syntax schema version of the policy. Each version of the policy contains a specific syntax schema that can be used by bindings. The newer version may contain role bindings with the newer syntax schema that is unsupported by earlier versions. This field is not intended to be used for any purposes other than policy syntax schema control. Below is the details of current available policy versions:

  • Version 1: The first version of Cloud IAM policy schema. Supports binding one role to one or more members. Does not support conditional bindings.
  • Version 2: Invalid. For internal use only.
  • Version 3: Introduces the condition field in the role binding, which further constrains the role binding via context-based and attribute-based rules.

Policy conditions:

With Cloud IAM Conditions, you can choose to grant resource access to identities (members) only if configured conditions are met. For example, this could be done to configure temporary access for users in the event of a production issue or to limit access to resources only for employees making requests from your corporate office.

Conditions are specified in the role bindings of a resource’s Cloud IAM policy. When a condition exists, the access request is only granted if the condition expression evaluates to true. Each condition expression is defined as a set of logic statements allowing you to specify one or more attributes to check. Common Expression Language, or CEL, is the expression language used to specify an expression in Cloud IAM Condition. It is tailored to express attribute-based logic expressions.

How To Create And Manage Cloud IAM Policy In GCP:

Hope you have enjoyed this article. All the public cloud providers are changing the console user interface rapidly and due to this some of the screenshots used in our previous AWS blogs are no longer relevant. Hence, we have decided that from now onwards most of the demo will be done programmatically. Let us know your feedback on this in the comment section.

To get more details on cloud IAM policy, please refer below GCP documentation.


Leave a Reply