IAM¶

basic blocks are: identities (who), roles (what), resources (which)
resource hierarchy: [Organization > folders >] Project > Resources
- Lower level constructs cannot take away permissions, so most generous policy remains
Organization
- created for G Suite or Cloud Identity account create a project
- has one super administrator which can assign Organization Admin role to other users
- can add 1+ domains to one organization. First one added becomes the primary domain
Folder can be used to represent departments, teams etc to consolidate access policy
Roles collection of permissions, 3 broad categories
- Primitive: apply to all resources in a project Viewer, Editor, Owner
- Predefined: specific to resource type eg Compute Admin, Network Admin
- Custom: can be created using yaml files
  - can be applied at organization and project level, but not folder level
Policies are list of bindings
An organizational policy is a configuration of restrictions (constraints), applies to organization, folder and projects
- constraints examples: disable service account creation, VM serial port access etc
A binding binds list of members to a role optionally with condition
Members are who and can be: google account, cloud identity user, service account, google group, Cloud Identity/GSuite domain
- Cloud Identity is GSuite minus the product offering
- LDAP, MS AD can be (one-way) sync'ed to Google Cloud Directory
- SSO is supported, either using (easier) SAML or third-party
Condition are defined using Common Expression Language CEL and consists of variables, operators, functions
groups are not configured in GCP, but defined in gsuite, google admin console or cloud identity domains.
Service Accounts: server-to-server communications
- 3 types of Service Accounts
  - built-in (Compute, App Engine), one per project, defaults: Editor role, enabled for all instances unless overridden by Custom or no role
  - Google APIs (represent the internal processes that run), Editor role on project by default
  - Custom, use only predefined roles unlike default service accounts which can use both primitive and predefined roles
- Service Account are also resources, so Users and Groups can be granted ServiceAccountUser role to act as Service Account
- authenticate with keys, two types
  - GCP Managed: cannot be downloaded, automatically rotated,
  - User managed: retains private key, BP: prefer for on-prem use of service account
Scopes are legacy, OAuth based scopes used by Service Accounts
- BP: For Custom Service Accounts set scope to cloud-platform (full access) and use IAM roles to control permission instead
Permission has the form <service>.<resource>.<verb> (eg. compute.instances.list, iam.roles.create)
each role can be at a different stage (ALPHA, BETA, GA, DISABLED or DEPRECATED)
add-iam-policy-binding sub-command allows --member option allows {user,group,serviceAccount}:<email>, or entire domain domain:<domain>
- allUsers and allAuthenticatedUsers are reserved names are also allowed
IAM Recommender recommends permission that can be revoked because they haven't been used for 90 days, or grant new permission based on ML
IAM Troubleshooter takes member email, resource name and a permission to check. It goes through all policies to check permission
Authentication decision tree
Service Accounts have IDs that look like email address, but instead of password they have cryptographic keys
- Service Accounts are also resources, so an Editor can control its permissions, and Viewer can just use the Service Account
Org policies are not retroactive. e.g. if a policy is modified after a bucket is created, it won't affect existing bucket

Cloud Identity¶

Identity as a Service solution tied to a unique DNS name that is enabled for receiving email
- services like GMail require GSuite, otherwise use GCP cloud identity
works with
- two editions: free and premium. Premium adds mobile device management
features
- SSO, auto user provisioning
- device management, including remote wipe out
- groups
- set security requirements such as 2-step verification, password strength
One-way sync from MS AD and LDAP using Google Cloud Directory Sync GCDS
- runs on-prem to sync data in the cloud => AD data isn't exposed on the cloud
Can also use Managed Service for Microsoft Active Directory to manage cloud based AD service
- runs Microsoft AD Controllers on cloud
- Ways to integrate with on-prem AD
  - separate AD forests without cross-forest trust: requires duplicating information on both AD forests (okay for light use)
  - separate AD forests with cross-forest trust: good for moderate usage (apps, users need permissions across resources on-prem and cloud)
  - use single AD forest and share across environment for heavy usage such as VDI
SAML or OpenId-Connect are used for authentication whereas OAuth is used for authorization, which can pass authorization information between applications without passing user+password information
authentication via either of the two mutually exclusive ways (except super admin account)
- google authentication: google stores password and admin can specify min password length etc
- SSO using SAML/OpenID. Google then operates as a Service Provider and SSO acts as Identity Provider
BP: When Organization is first created, all users are granted Project Creator and Billing Account Creator roles; revoke these
patterns for authenticating corporate users in hybrid environment
- federating external Identity Provider with GCP acting as secondary IdP
  - Federate Active Directory using GCDS and AD FS
  - some tools such as Cloud console, gcloud, IAP etc must use Google as IdP
- extending an IdP to GCP: application on GCP reuse external IdP
  - used when IdP protocols aren't supported by Cloud Identity
  - Application directly call external IdP to authenticate users
  - Application can't perform API calls on the user's behalf, must use service account

Resource Manager¶

Manages resources containers:
- effective permissions are union of all. can't remove an explicit permission granted at higher level
A Project accumulates consumption of all contained resources and has exactly one billing account
- Use labels for finer grained resource tracking
- tags are applied to instances only and used primarily for networking (firewall rules)
All resources are subject to project quotas and limits. set by Google, can be requested to be increased
- number of resources: eg 5 VPC / project
- rate limits: 5 admin actions /second
- regional limit: 24 CPUs / region / project
are resource and quota boundaries.
An organization is collection of all billing accounts
Resources can be:
- global: eg. images, snapshot, networks
- regional: external IP addresses
- zonal: instances, disks

gcloud¶

service account: create, bind to role, print attribute value, create keys

gcloud iam service-accounts create spinnaker-account --display-name spinnaker-account
gcloud projects add-iam-policy-binding $PROJECT --role roles/storage.admin --member serviceAccount:$SA_EMAIL
gcloud iam service-accounts list --filter="displayName:spinnaker-account" --format='value(email)' # print email address of a service account
gcloud iam service-accounts keys create spinnaker-sa.json --iam-account $SA_EMAIL  # create and print key for a service count

Role: print metadata, create custom role, list grantable roles, list testable permissions

gcloud iam roles describe [ROLE_NAME]  # Role metadata
gcloud iam roles create viewer --project $DEVSHELL_PROJECT_ID --title "Role Viewer" --description "Custom role description." \
    --permissions compute.instances.get,compute.instances.list --stage ALPHA
gcloud iam list-grantable-roles //cloudresourcemanager.googleapis.com/projects/$DEVSHELL_PROJECT_ID # grantable roles on resources
gcloud iam list-testable-permissions //cloudresourcemanager.googleapis.com/projects/$DEVSHELL_PROJECT_ID

make application use a service-account for API calls

gcloud iam service-accounts create my-account
gcloud iam service-accounts keys create key.json --iam-account=my-account@my-project.iam.gserviceaccount.com
export GOOGLE_APPLICATION_CREDENTIALS=key.json
./my_application.sh