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.