GCP Security · Domain 1
Configuring Access
About 25% of the exam
The resource hierarchy
- Organization
- the root of the hierarchy
- Folder
- groups projects by business unit
- Project
- the main resource container
- Resource
- the individual object being protected
- Inheritance
- policies flow down, never up
- Effective policy
- the union of everything inherited
- Billing account
- linked, not part of the hierarchy
- Organization policy
- guardrail applied at any node
Allow policies accumulate downward, so a grant made at the organization reaches every project underneath it
Principal types
- User account
- a person in the directory
- Group
- the preferred grant target
- Service account
- an identity for a workload
- Workload identity pool
- external workloads mapped inward
- Workforce identity pool
- external people mapped inward
- Domain
- everyone in a verified domain
- All authenticated users
- anyone holding a valid account
- All users
- public, including anonymous callers
Role types
- Basic role
- owner, editor, viewer, too broad
- Predefined role
- curated per service, preferred default
- Custom role
- your own list of permissions
- Permission
- one service and one verb
- Binding
- role plus principals plus condition
- Organization custom role
- defined once, used anywhere below
- Project custom role
- scoped to a single project
- Role describe
- lists the permissions it grants
Allow and deny policies
- Allow policies grant permissions to principals
- Deny policies block a permission outright
- A matching deny beats every allow
- Deny can stop even project owners
- Deny rules list principals and permissions
- Deny is evaluated before allow
Conditions on bindings
- Written in a common expression language
- Time based access using request time
- Resource name matching for narrow grants
- Tag matching keeps bindings maintainable
- Require a satisfied access level
- The condition lives on the binding
Service accounts
Basics
- An identity, and also a resource
- Roles granted to it and on it
- Attached to a workload at runtime
Impersonation
- A token creator role allows impersonation
- Impersonate for a single command
- Chains must be logged and reviewed
Keys
- Static keys are the biggest risk
- A constraint disables key creation entirely
- Prefer attached identities or federation
Workload identity federation
- External tokens exchanged for short credentials
- Attribute mapping turns claims into attributes
- Attribute conditions restrict which tokens qualify
- Removes long lived keys from pipelines
- The pool and provider define the trust
- Works for clusters and other clouds
Workforce identity and context
- External people authenticate with their provider
- No account needed in your directory
- Access levels describe device and network
- Context aware access gates by posture
- Conditions can require a satisfied level
- Sessions bounded by policy duration
Organization policy constraints
- Boolean constraint
- on or off at a node
- List constraint
- allowed or denied values
- Resource locations
- restricts where resources may exist
- Disable key creation
- blocks static service account keys
- External address limit
- stops public addresses on machines
- Trusted image projects
- only approved boot images
- Domain restricted sharing
- limits which identities may be granted
- Custom constraint
- your own rule on a type
Policy intelligence
Before a change
- The simulator replays recent access
- Dry run mode on organization policy
- Troubleshooter explains an effective decision
Ongoing
- Recommender flags over-granted permissions
- Usage measured over a trailing window
- Insights explain why it recommends
Evidence
- Asset inventory keeps configuration history
- Search across resources and policies
- Audit logs record every grant
Tags and conditional grants
- Tags are key and value resources
- Tags inherit down the hierarchy
- Conditions can reference a tag
- Labels are metadata, not access controls
- Tag bindings attach to a resource
- Environment tags drive production separation
Checks worth knowing
- Effective access
- the troubleshooter shows the reason
- Denied request
- the audit entry shows granted false
- Custom role contents
- describe the role to list permissions
- One-off elevation
- impersonate for a single command
- Change safety
- simulate before you enforce
- Unused permission
- recommender suggests a smaller role
- Inventory question
- search the asset inventory
- Read only oversight
- the policy viewer role
Access mistakes
Too broad
- Basic roles granted at organization
- All users left on a bucket
- Service account with editor everywhere
Keys
- Static keys committed to a repository
- Keys shared between environments
- Key creation never disabled centrally
Blind spots
- Conditions written but never tested
- Inherited grants nobody remembers
- Impersonation chains never reviewed
Service names to know
- Test a change first
- the policy simulator
- Explain an access decision
- the policy troubleshooter
- Suggest smaller roles
- the recommender
- Search every resource
- asset inventory
- External workloads without keys
- workload identity federation
- External people without accounts
- workforce identity federation
- Device and network conditions
- access context manager
- Hard block a permission
- a deny policy
Know the order
- Check deny policies
- Apply organization policy
- Sum inherited allows
- Evaluate conditions
- Grant or refuse
Grant to groups at the smallest node that works, then narrow it further with conditions and tags
Reference strip: hierarchy, principals, roles, guardrails, assurance
Hierarchy
- Organization, folders, projects, resources
- Allow policies inherit downward
- Constraints apply at any node
- Effective policy is the union
Principals
- Users and groups
- Service accounts for workloads
- Federated pools for outsiders
- Public principals to avoid
Roles
- Basic roles are too broad
- Predefined roles by default
- Custom roles when needed
- Conditions on the binding
Guardrails
- Deny policies override allows
- Organization policy constraints
- Custom constraints for your rules
- Dry run before enforcement
Assurance
- Simulator and troubleshooter
- Recommender for right-sizing
- Asset inventory history
- Audit logs for every grant
Quick exam traps
- Trap: A grant at the project level overrides a broader grant at the folder
- Trap: Removing an allow binding is the only way to block a permission
- Trap: Labels can be used in access conditions in place of tags
- Trap: A project scoped custom role can be reused in another project
- Trap: All authenticated users means only people in your organization
- Trap: Disabling a service account proves nothing depended on it
- Trap: Basic roles are acceptable as long as they go to groups
cybercertprep.com · original revision sheet written from the public body of knowledge