What is a Google Cloud Principal?

Definition

A Google Cloud Principal (also called a member in older docs) is the identity to which IAM bindings grant roles. Every Google Cloud API request has a principal, and IAM decides whether to allow or deny based on the bindings that include that principal.

In simple terms:

A principal is the "who" referenced in any Google Cloud IAM binding.

---

Why Principals Matter

• IAM bindings are useless without principals.
• Choosing the right principal type — and the right scope — determines blast radius.
• Misuse of principals (allUsers, broad domains, unmanaged service accounts) is a top source of GCP exposure.
• Federation principals introduce additional trust considerations.

---

Principal Types

1. Google Account (User)

• user:[email protected]
• Individual human identity managed in Cloud Identity / Google Workspace.
• Best for individual access (rare; prefer groups).

2. Google Group

• group:[email protected]
• Collection of users (managed in Cloud Identity / Workspace / Google Groups).
• Preferred for IAM bindings to enable lifecycle management.

3. Service Account

• serviceAccount:[email protected]
• Non-human identity used by workloads or via impersonation.
• Project-scoped by location but usable across projects.

4. Cloud Identity / Workspace Domain

• domain:example.com
• All users in your organization's domain.
• Use sparingly; a single binding to all employees can be very broad.

5. Workforce Identity Pool Members

• External (non-Google) human identities federated via SAML / OIDC.
• principalSet://iam.googleapis.com/locations/global/workforcePools/my-pool/group/engineers
• Useful for orgs with external IdP managing workforce.

6. Workload Identity Pool Members

• External (non-Google) workload identities federated via OIDC, SAML, or AWS.
• principalSet://iam.googleapis.com/projects/<num>/locations/global/workloadIdentityPools/my-pool/...
• Eliminates need for service account keys for external workloads (CI/CD, on-premises, AWS, Azure).

7. allAuthenticatedUsers

• Any authenticated Google account, including ones outside your org.
• Public-but-authenticated.
• Almost always wrong outside specific intentional cases.

8. allUsers

• Public, including unauthenticated.
• Anything bound here is publicly accessible.
• Reserved for truly public resources (and even then, usually via specific service settings, not broad IAM).

---

How Principals Appear in Bindings

bindings:
- role: roles/storage.objectViewer
  members:
  - user:[email protected]
  - group:[email protected]
  - serviceAccount:[email protected]
- role: roles/storage.objectAdmin
  members:
  - principalSet://iam.googleapis.com/projects/123/locations/global/workloadIdentityPools/github/attribute.repository/myorg/myrepo

---

Common Mistakes

• allUsers / allAuthenticatedUsers bindings.
• domain:example.com for resource access (too broad).
• Individual user bindings instead of groups (lifecycle drift).
• Default service accounts with Editor role used everywhere.
• Service account keys distributed instead of federation/impersonation.
• Workload Identity Federation pool with weak attribute conditions — wrong external identities can authenticate.
• Stale principals (departed users, decommissioned service accounts).

---

Real-World Examples

1. allUsers on BigQuery Dataset

Engineer ran a "demo" with allUsers Viewer on a sensitive dataset. Months later, the dataset was queryable publicly via BigQuery public datasets discovery. Major data exposure.

2. Domain-Wide Editor

A startup gave domain:startup.com Editor at Org level for "internal speed." A compromise of any employee account = full org compromise.

3. Workload Identity Federation Done Right

GitHub Actions pipelines authenticate via OIDC → workload identity pool with strict attribute condition (assertion.repository == "myorg/myrepo"). No long-lived keys; tight trust.

4. Default Compute SA Compromise

GKE pod compromise → default Compute Engine service account → Editor on entire project → mass data exfiltration.

---

Best Practices

1. Prefer groups to individual users for assignment.
2. No allUsers/allAuthenticatedUsers outside intentional public.
3. Domain-wide bindings only at high-trust roles in tightly scoped folders/projects.
4. Tag service accounts with owner/purpose; assign owners.
5. Workload Identity Federation for external workloads.
6. Workforce Identity Federation for external IdP users.
7. Strict attribute conditions on federation pools.
8. Disable / restrict default service accounts.
9. Quarterly cleanup of stale principals.
10. Audit log monitoring of new bindings, especially with allUsers / domain principals.

---

Checklist

• Group-based bindings dominant?
• No allUsers/allAuthenticatedUsers (outside intentional)?
• Domain bindings minimal and high-trust only?
• Service accounts owned and named clearly?
• Default service accounts tamed?
• Workload / Workforce Identity Federation used in lieu of keys?
• Federation attribute conditions strict?
• Quarterly stale principal cleanup?
• Audit log alerts on risky bindings?

---

How Forestall Helps

Forestall enumerates principals across your Google Cloud hierarchy:

• Effective access per principal.
• Public exposure detection.
• Domain-level binding risk.
• Federation pool reach.
• Stale principals.
• Service account governance gaps.

---

Frequently Asked Questions

Are principals the same as members?

Yes — older Google Cloud docs say "members"; current docs say "principals."

Can I bind a principal at a specific resource?

Many services support resource-level IAM (e.g., GCS buckets, BigQuery datasets). Use resource-level bindings where possible.

What if a service account has no key?

Better — workloads can authenticate via Workload Identity / instance metadata / impersonation without long-lived keys.

Are workload identity pool members principals?

Yes — federated identities are valid principals via principalSet://... references.

How do I avoid allUsers exposure?

Use Cloud Storage's "uniform bucket-level access" + "public access prevention." Use Org Policy iam.allowedPolicyMemberDomains to restrict allowed principal types.

---

Conclusion

Choosing the right Google Cloud Principal — and binding it at the right scope — is the foundation of GCP IAM hygiene. Prefer groups, eliminate public/domain-wide bindings outside specific use cases, govern service accounts, and adopt federation in place of long-lived keys. Combined with continuous monitoring of binding changes, principal hygiene closes a large portion of Google Cloud identity risk.