4. Identity and Access Management (IAM) Flashcards
Principle of Least Privilege
A user/programme/process should have only the bare minimum privileges necessary to perform its function
Policy Architecture (structured in a JSON format)
Combination of:
+ Bindings (Member, Role, Condition)
+ Metadata
+ Audit Config
Binding - specifies how access should be granted on resources and it binds one or more members with a single role and any contact specific conditions that change how and when the role is granted
Metadata - includes additional information about the policy such as e-tag or version
Audit Config - specifies how access attempts should be audited
Policy Architecture: Members aka principals
- Google Account users
- Service Account - account that belongs to an application rather than an individual user
- Google Groups - can include not only Google Accounts but also Service Accounts, eg, groupA@googlegroups.com - convenient to grant permissions all at once
- G Suite Domain - Google Accounts that have been created in an organisation’s G Suite account
- Cloud Identity Domain - Google Accounts in an organisation that do not have access to the G Suite applications or features
- AllAuthenticatedUsers - special identifier for all service accounts and all users who have authenticated with a Google Account
- AllUsers - special identifier for all inet users, authenticated or not
-
Google Cloud Directory Sync - allows you to have access to users and groups on Cloud even if you don’t have a google account.
SSO can be used too
Policy Architecture: Roles
Determine what operations are allowed on a resource.
These permissions are not granted to users directly rather to a “group”/role
You grant a role to the user and so all the permissions that exist in the role are given to the user.
Correspond one to one with REST API.
Example:
service . resource . verb - all role granting commands follow this pattern
compute.instances.list
Policy Architecture: Role Types
- Basic/Primitive (Owner / Editor / Viewer / Billing Admin) - NOT recommended by Google. Basic roles set project-level permissions
- Predefined (created and automatically updated by Google); some permissions in the predefined roles are not available in custom!
- Custom (user defined - not maintained by Google to keep up with updates); custom role cannot be applied to a folder level, only can be applied to project or org level; moreover, custom roles creation by default is only possible by the Owner
Custom roles have a feature called “Launch Stage”:
- alpha: in testing
- beta: tested and awaiting for approval
- ga: generally available
Policy Architecture: Conditions
Specifies conditional, attribute-based access control for Google Cloud resources
Used to give access to e.g. contractors, only for a specified amount of time.
Policy Architecture: Metadata
etags
When different systems try to change IAM policy at the same time, to avoid the overwriting.
version
To avoid breaking existing integrations on new feature releases
version: 1 - no conditions will be attached to the roles
version: 2 - used for Google’s internal policies, you won’t normally see this
version: 3 - introduces the condition field in the role binding
Policy Architecture: Audit Config
Used to configure audit logging for a policy:
determines which permission types are logged and what identities are exempted from logging.
I.e. who is logged in and who is not allowed to log in.
Policies within the Resource Hierarchy (Domain – Resource)
- Can be set at any level of the resource hierarchy
- Policies are inherited at the lower levels from the above levels
View Policy Statement in Cloud Shell:
command
gcloud projects get-iam-policy project-name
OR
gcloud resource-manager folders get-iam-policy folder-name
OR
gcloud organizations get-iam-policy organization-name
Setting an audit config policy:
gcloud projects set-iam-policy project-name __.yaml
This can also be found in the IAM & Admin under ‘Audit Logs’.
Example:
bindings:
- members:
- serviceAccount: service…….
role: roles/compute.serviceAgent
- members:
- serviceAccount: …..
- serviceAccount: …..
role: roles/editor
- members:
- user: tonybowtieace@gmail.com
role: roles/owner
etag: BwWtFEMmKLO=
version: 1
bindings:
- members:
- user:kristinagugle@gmail.com
role: roles/owner
etag: BwYEMtFCQSI=
version: 1
Add a new user to the project
IAM & Admin –> IAM –> add –> put email and set a basic role (viewer etc). Can add conditions
Policy Limitations
- Each resource (organisation, folder, project) can only have ONE policy
- Each policy can only cover 1,500 people or 250 Google groups
- It takes up to 7 mins to update the policy changes, since they occur on the global level
- Each policy can have a maximum of 100 conditional role bindings
Limits on Conditions
1. Primitive roles cannot have conditions
2. allUsers or allAuthenticatedUsers also cannot have conditions
3. The same role and the same member can only have up to 20 conditions
Command to give someone a role of Storage Admin
gcloud projects add-iam-policy-binding project-name –member user:lauradeelightful@gmail.com –role roles/storage.admin
- The above gives access to create/delete/edit storage, folders
Service Account: Types
User-managed
- you create
- you are responsible for managing that account
- you choose the name of the service account
- Google RECOMMENDS
Default
- automatically granted the editor role
- advice is to manually remove the role or create a policy that would prevent this from happening
Google-managed
- created and managed by Google
- ends with gserviceaccount.com
Service Account: Keys (instead of passwords)
Each service account has 2 sets of authentication keys:
Google Managed:
Google stores the public and the private portion of the key.
Public portion is to be used for 2 weeks.
Private key is always held in escrow.
User Managed - not advised
You own the private and the public portion of the key pair.
Google stores public portion.
Private portion is managed by you, if you lose, you lose access to the Service Account.
Service Account: Permissions
Different people can have different permissions on the service account.
E.g. Luis can have an editor role on the service account while Betty only the viewer role.
This is because Service accounts can also act as resources, i.e. IAM policies can be assigned to them.
Service Account: Scopes
Legacy method to specify roles. This used to be the only way to set up permissions on a Service Account.
Used to identify whether an authenticated identity is authorised (to use the resource), i.e. to tell if the service account has the permission to edit/read or something else the resource.
Service Account: Usage (how)
- It can be attached to a specific resource
- Impersonalisation of a Service Account
- when creating a firewall rule, the service account can be used to filter on where to apply the rules.
- firewall rules can be attached to service accounts
- if the person has access to this service account with this firewall rule, you can only use it for this purpose
- if you have access to the service account that allows all egress, that means you can use it and do more stuff
Service Account (best practices)
- audit service accounts & keys using: serviceAccount.keys.list() method or the Logs Viewer page in the console
- delete external keys if the service account doesn’t use them
- create Service Accounts for each service separately with permissions only for that service
- to implement key rotation use IAM service account API
Service Account SSH (running instance from SSH):
command to view files in a bucket in Cloud Store
& trying to create and copy a new file into the storage
gsutil ls gs://new_bucket_globally_uniqueee
touch file1
gsutil cp file1 gs://new_bucket_globally_uniqueee
Service Account (CLI):
command to view all the service accounts
gcloud iam service-accounts list
Service Account (CLI):
command to create a new service account with a specific display name
gcloud iam service-accounts create my-new –display-name=’lala’
Cloud Identity: Features
It’s a tool that allows to define policies and manage users and groups using the Google Admin console. (eg if someone leaves the org, their account can be easily removed)
- Device Management
- Security
- Single Sign-on (SSO)
- Reporting
- Directory Management
Cloud Identity: Device Management
- Allows to access services using mobile, PC
- Passcodes are enforced
- Auditing is enforced
Cloud Identity: Security
2 step verification
Cloud Identity: Reporting
Logs + ability to export them to BigQuery for analysis
Cloud Identity: Directory Management
Can synch contacts in an organisation, share them.
Google Cloud Directory Synch (GCDS) - synch data in your google account with your microsoft active directory
Google Cloud Directory Sync (GCDS)
It allows to link the on-premises environment / AD (active directory) with the Google Cloud Identity.
Like linking accounts created in the organisation with the “twin” accounts on the Cloud.
Some best practices
- use Identity-Aware Proxy (IAP) - additional checks without the use of VPN on whether you can access the resource
- Restrict access to who can create and manage service accounts
- be cautious with owner roles
- mirror your Google Cloud resource hierarchy structure to your organisation structure
- set policies at the organisation and project levels, not resource level
- grant roles for users or groups at the folder level instead of the project level
Service Accounts
- for service accounts make sure that any user managed keys are rotated periodically to avoid being compromised - use serviceAccount.keys.list() method to audit
- name your service keys
- give understandable names to the service accounts
- establish naming convention for service accounts
Auditing
- check your Cloud Audit Logs to regularly audit IAM policy changes
- check/audit who has permissions to edit the IAM policies
- export audit logs to Cloud Storage for long-term retention
- restrict who can see the logs
Policy Management
- grant roles to a Google group, not individual users
- when granting multiple roles to a particular task, create a Google group
How to create firewall rules
- use VPC names to apply firewall rules directly to the networks chosen
- use tags
- use service accounts
Main roles
- Workplace or Cloud Identity super administrator - can do anything
– creates organisation admin roles
– point of contact in case of recovery issues
– controls the lifecylce of G Suite (workplace) / Cloud Identity account
Organisation level
- Organisation admin
– defines IAM policies/roles
– determines the structure of the resource hierarchy
– no permission to create folders
- Organisation viewer
Folder level
- Folder admin
- Folder creator - browse hierarchy and create folders
- Folder viewer - view folders and projects below the resource
Project level
- Project creator - when they create the project, they become the project ownder
- Project deleter
Resource specific role examples
When we talk about compute engines, and we talk about admin role they can
- delete
- get
- list
- set machine type
- start
- stop instances
compute.instances.delete
compute.instances.get …
service-resource-verb
Predefined role main examples
- Compute Admin - full control of all compute engine resources (compute.)
- Network Admin - create, modify, delete networking resources, except for firewall rules and SSL certificates
- Storage Admin - create, modify, delete disks, images and snapshots (so he won’t have the editor role on the project)
Create custom role (start/stop VMs but not be able to reconfigure them)
IAM & Admin –> roles –> create role
compute.instances.get + reset + list + resume + start + stop + suspend
Permissions on the service account
serviceAccountUser role - allows the person to access the service account resource, i.e. to have the same permissions on the resource as the service account has.
It’s a way to grant permissions to many people at the same time. Person A and Person B or Group Z will have permission on the service account, so they now have permission to edit the VM for instance.
List all permissions associated with a specific service account
gcloud iam service-accounts keys list –iam-account user@email.com
Egress Proxy Administrator
Controls which resources are available to the organisation (like which websites you can visit)
This is an organisation restriction feature
Resource hierarchy
Global
- images
- snapshots
- networks
Regional
- external IP addresses
Zonal
- instances
- disks
Quotas and Limits + Labels use cases
Can define:
1. How many resources can be created per project
2. How quickly you can make API requests in a project (rate limits)
3. How many resources you can create per region
Quotas help to review maybe you can use less of the resource
Labels: –> user-defined strings in the key-value format
- Team or cost centre labels
- Components
- Environment or stage (prod/test)
- owner/contact
- stage (inuse…)
NOTE: tags are user defined strings that are used mainly for applying firewall rules and they are available on instances only
