Users aren’t native to GCP – they are either GSuite domain users, Google Group users, Google Account members or Cloud Identity Domain (like GSuite but doesn’t have access to GSuite apps)

Users don’t get assigned permissions directly. They get assigned ROLES

ROLES come in 3 forms

  1. PRIMITIVE ROLES  – Owner, Editor, Viewer
  2. Pre-Defined Roles – e.g. Pub-Sub Publisher, Cloud Storage objectAdmin, objectViewer, admin, objectCreator
  3. Custom Roles

Service Accounts

  1. Either generated by GCP for services or manually created for an application hosted on GCP.
  2. Advantage? – Avoids storing the credentials at app level – App level assumes identity of the service account

You can treat a service account either as a resource or as an identity.

  1. Your application uses a service account as an identity to authenticate to Google Cloud Platform services. For example, if you have a Compute Engine Virtual Machine (VM) running as a service account, you can grant the editor role to the service account (the identity) for a project (the resource).
  2. At the same time, you might also want to control who can start the VM. You can do this by granting a user (the identity) the serviceAccountUser role for the service account (the resource).

gcloud iam service-accounts create my-sa-vm-identity –display-name ‘my sa vm identity’

gcloud projects add-iam-policy-binding my-project –member serviceAccount:my-sa-vm-identity@myproject.iam.gserviceaccount.com –role roles/editor

Folders (Dept A –> Team A and B –> Products 1 and 2) and Projects (Under each product—>Dev Project, Test Project, Prod Project) and Resources (App Engine Services, Cloud Storage Buckets)

 

Resource hierarchy

Anuj holds professional certifications in Google Cloud, AWS as well as certifications in Docker and App Performance Tools such as New Relic. He specializes in Cloud Security, Data Encryption and Container Technologies.

Initial Consultation

Anuj Varma – who has written posts on Anuj Varma, Hands-On Technology Architect, Clean Air Activist.