Skip to content
Notifications
Clear all

How do I get granular permissions for my marketing team?

1 Posts
1 Users
0 Reactions
26 Views
(@alexh82)
Honorable Member
Joined: 3 months ago
Posts: 419
Topic starter   [#7313]

We are migrating our cloud infrastructure to a more granular, zero-trust-aligned model, and a significant hurdle has been designing the appropriate permissions schema for our marketing team. Their required access patterns are diverse and often cross multiple service boundaries, making broad roles like `Editor` or `Owner` a significant compliance and security risk.

The team's core needs include:
* Read/write access to specific storage buckets for campaign assets (e.g., `projects/project-a/assets/campaigns/2024-Q3`).
* Read-only access to analytics datasets in BigQuery, scoped to particular tables and views.
* The ability to deploy and modify only a subset of Cloud Run services tagged as `environment: staging` and `team: marketing`.
* No permissions for networking configuration, service account management, or billing data.

Our current approach uses a combination of Google Cloud IAM custom roles and Terraform to manage bindings. However, we are encountering challenges with achieving true granularity without role explosion. For example, a condition to restrict access to a specific bucket prefix seems straightforward, but combining that with a condition for a specific service tag becomes complex.

```hcl
# Example of a problematic conditional binding attempt
resource "google_project_iam_member" "marketing_storage_dev" {
project = var.project_id
role = "roles/storage.objectAdmin"
member = "group:[email protected]"

condition {
title = "access_only_to_marketing_campaign_buckets"
expression = <<-EOT
resource.name.startsWith("projects/_/buckets/campaign-assets-")
&&
resource.name.endsWith("/objects/campaigns/")
EOT
}
}
```

The above is simplified and doesn't effectively solve the multi-service, attribute-based access control (ABAC) requirement. I am evaluating if moving towards a policy-as-code layer (e.g., Open Policy Agent with IAM) or leveraging IAM Conditions with more sophisticated tags and attributes is the more maintainable path.

I'm seeking reviews or experiences from others who have implemented granular, least-privilege access for dynamic teams like marketing or sales in Grok. Specifically:

* Have you found IAM Custom Roles combined with Conditions sufficient, or did you reach for an external policy engine?
* How do you structure your Terraform or Deployment Manager code to avoid repetition when similar granular policies are needed across multiple projects or environments?
* Are there any pitfalls in mixing resource-based (e.g., bucket ACLs) and identity-based (IAM) permissions in this scenario?

Our goal is a secure, auditable, and scalable model that doesn't hinder the team's operational velocity. Concrete examples of policy definitions and their trade-offs would be highly valuable.



   
Quote