Implementation strategy and roadmap for GCP IAM Deny Policies in Fabric

[norbert-loderer]

We are currently exploring the use of IAM Deny policies to establish hard guardrails across our Google Cloud estate. However, we are seeking some architectural guidance on the recommended approach for implementing them within the CFF/FAST framework.

Our Use Case

We are considering applying IAM Deny policies at the organization level to establish broad, conditional guardrails. For example, preventing the deletion of stateful or production resources across the org, based on resource tags, with exceptions for break-glass or specific platform teams.

Here is an example of the kind of policy we are looking to implement:

{
  "displayName": "Prevent Production Resource Deletion",
  "rules": [
    {
      "denyRule": {
        "deniedPrincipals": [
          "principalSet://goog/public:all"
        ],
        "deniedPermissions": [
          "[compute.googleapis.com/instances.delete](https://compute.googleapis.com/instances.delete)",
          "[compute.googleapis.com/disks.delete](https://compute.googleapis.com/disks.delete)",
          "[sqladmin.googleapis.com/instances.delete](https://sqladmin.googleapis.com/instances.delete)",
          "[container.googleapis.com/clusters.delete](https://container.googleapis.com/clusters.delete)"
        ],
        "exceptionPrincipals": [
          "principalSet://goog/group/platform-team@example.com"
        ],
        "denialCondition": {
          "title": "Only deny in production projects",
          "expression": "resource.matchTag('env', 'production')"
        }
      }
    }
  ]
}

Additionally, we foresee using these at lower levels of the hierarchy, specifically at the project level.

Questions for the Maintainers

Given the modular nature of FAST, we have a few questions regarding the "right" place for these:

• Recommended Implementation Stage: Where should these policies be implemented to align with the CFF philosophy?

• Should organization-wide policies reside in 0-org-setup?

• For project-specific deny policies, should they be handled in the 2-project-factory stage or integrated directly into the project-factory module?

• Roadmap: Is there an existing plan to implement native support for IAM Deny policies within the FAST stages or any specific modules?

We want to ensure our implementation remains upgradeable and follows the upstream pattern. We would appreciate any insights or recommendations you might have!

[juliocc]

Recommended Implementation Stage: Where should these policies be implemented to align with the CFF philosophy?

The opinion of the maintainers is that IAM deny is almost always the wrong solution.

For example, in your case, do you really want to prevent the deletion of production resources or prevent accidental deletion of production resources? The former is an IAM issue and IAM deny might be right tool, whereas the latter is more of an operational issue.

Should organization-wide policies reside in 0-org-setup?

Yes. Org-level IAM policies (allow or deny) go in 0-org-setup.

For project-specific deny policies, should they be handled in the 2-project-factory stage or integrated directly into the project-factory module?

Probably, yes. However, going back to the point before, IAM deny should be an escape valve, not a regular tool to patch over-permissive IAM grants.

Roadmap: Is there an existing plan to implement native support for IAM Deny policies within the FAST stages or any specific modules?

No current plans, but we might consider it if a good use case comes up.

[juliocc]

#3970 added support for IAM deny