Professional Cloud Security Engineer

Configure Scoped Authorization for Native and Federated Identities

Scoped authorization means giving permissions only under specific conditions to limit access. In Google Cloud, you use IAM Conditions and IAM Deny Policies to create these detailed rules. These tools help enforce the least-privilege principle, where users and services get only the access they absolutely need, and they work for all types of identities, including Google service accounts, Google Groups, and external users from systems like AWS or Azure.

To set up scoped authorization, you add IAM Conditions to role bindings. These conditions are written in Common Expression Language (CEL) and check specific details at the moment someone tries to access a resource. For example, you could write a condition that only allows a service account to write to Cloud Storage buckets whose names start with "dev-". This makes permissions dynamic and based on context, like the resource's name or tags.

Managing federated identities (external users) requires extra care. When you use Workload Identity Federation, you must map the external identity provider's information (like an AWS account ID) to Google Cloud attributes. You then set attribute conditions to define exactly which external users or systems can get a Google Cloud access token. This prevents privilege escalation by ensuring only approved, external principals from specific companies or projects can gain access. You can also use organization policies to restrict which external identity providers can even be connected to your cloud environment.

For strong governance, you should monitor all important IAM changes, especially grants of powerful roles like Organization Admin, using Cloud Audit Logs. Applying tags to your resources (like "env: production") lets you write conditional policies that automatically apply based on those tags. Finally, organization policies like iam.allowedPolicyMemberDomains can lock down your hierarchy by only allowing role grants to users from your own company's domain, preventing accidental sharing with outsiders.

Implement and Manage IAM Deny Policies across Resource Hierarchies

IAM deny policies are a powerful tool for creating absolute security boundaries that cannot be bypassed by regular permissions. Unlike allow policies, which grant access, a deny policy explicitly blocks specific principals from using certain permissions, no matter what roles they have been given. You attach these policies at the organization, folder, or project level.

How Deny Policies Work

A deny policy contains deny rules. Each rule specifies which principals (like a user or group) are blocked, which permissions they are blocked from using, and can include exception principals (specific users who are exempt from the block). The IAM system always checks deny policies before allow policies. If a deny rule matches a request, the access is blocked immediately, even if the user has an allow policy that would normally grant it.

Resource Hierarchy and Inheritance

Deny policies are inherited down the Google Cloud resource hierarchy. If you attach a deny policy to your organization, it automatically applies to all folders and projects underneath it. This lets you set non-negotiable security rules at the highest level that lower-level project owners cannot override. Each resource can have many deny policies, providing layered security controls.

Policy Structure and Conditions

Deny rules can include denial conditions written in CEL, but they are more limited than IAM Conditions. Primarily, they can check the values of resource tags. For example, you could create a rule that denies everyone except project admins from deleting any project that has a tag "environment: production." The rules also support exception principals, allowing you to deny a permission to an entire group but still permit it for a few trusted individuals within that group.

Policy Evaluation and Override Behavior

The key feature of deny policies is that they override all allow grants. This makes them ideal for enforcing critical guardrails. For instance, you could grant a broad editor role to a team but use a deny policy to block them from creating service account keys, ensuring a key security rule is never violated. Policy changes usually take effect within minutes.

Required Roles and Permissions

To work with deny policies, you need specific IAM roles. The Deny Reviewer role (roles/iam.denyReviewer) lets you view policies. The Deny Admin role (roles/iam.denyAdmin) allows you to create, update, and delete deny policies. These roles contain the necessary permissions for full lifecycle management of these policies.

Common Use Cases

Common uses for deny policies include centralizing control over high-risk permissions (like deleting projects), creating exceptions to broad access grants, and protecting sensitive resources based on their tags. They are a foundational tool for creating organizational security guardrails.

Formulate Context-Aware Access with IAM Conditions

IAM Conditions let you add dynamic, context-based logic to permissions using the Common Expression Language (CEL). This moves beyond static role assignments to attribute-based access control (ABAC), where the decision to grant access depends on specific attributes of the request, like the resource being accessed or the time of day.

You build CEL expressions that evaluate to true or false when an access request is made. If the condition is true, the role binding applies and access is granted. These expressions can check many things:

• Resource Attributes: You can restrict permissions to specific resource types or names. For example, using resource.name.startsWith('projects/my-project/instances/dev-') would limit access only to Compute Engine instances with names starting with "dev-".
• Service-Specific Parameters: Conditions can check configurations unique to a service. For instance, you could write a condition that only allows a role to apply to Cloud Load Balancing forwarding rules that use a specific loadBalancingScheme.
• String matching in CEL is case-sensitive, so your expressions must match the exact casing of resource names and attributes to work correctly.

Conditions also provide administrative guardrails. A powerful CEL expression like api.getAttribute('iam.googleapis.com/modifiedGrantsByRole', []).hasOnly(['roles/storage.admin']) can limit an administrator so they can only grant or revoke the specific Storage Admin role, and no others. However, you must know that not all Google Cloud services support this specific attribute check; for example, BigQuery datasets do not enforce it, so an admin with dataset permissions could bypass the intended restriction.

These conditional controls work for all identity types, including federated identities from Workload Identity Federation. You can write conditions that evaluate the external principal's attributes, like their source AWS account or GitHub organization. It's important to remember that IAM Deny Policies and IAM Conditions are different: deny policy conditions are more limited and typically only evaluate resource tags, while IAM Conditions offer a richer set of CEL operators for granular, context-aware allow rules.