In Google Cloud Platform (GCP), permissions are granted by binding a "Member" (User, Group, Service Account) to a "Role" (Collection of permissions). If you get this wrong, you accidentally give a contractor full access to your billing account.
Service Account Keys (The Danger)
GCP uses JSON files as keys for Service Accounts.
Developers download these keys (`creds.json`) to their laptop to test code.
Then they git commit the code to GitHub.
Result: Hackers scan GitHub for "private_key_id", find the key, and use it to mine crypto on your account.
Solution: Use Workload Identity Federation instead of long-lived keys.
1. Primitive vs Predefined Roles
Primitive Roles: (Owner, Editor, Viewer).
These are too broad. "Editor" can delete almost anything. Never use them in production.
Predefined Roles: Granular.
Use `roles/storage.objectViewer` instead of `Editor` if someone just needs to read a file.
2. Hierarchy Inheritance
Policies flow down.
Organization -> Folder -> Project -> Resource.
If you grant "Owner" at the Organization level, that user owns every project in the company. Be careful with top-level grants.