removed emoji from filenames, Obsidian changed all relevant links
This commit is contained in:
parent
d316285a74
commit
68f1c38681
638 changed files with 710 additions and 3176 deletions
|
|
@ -0,0 +1,14 @@
|
|||
## How IAM works
|
||||
|
||||
With IAM, you manage access control by defining _who_ (identity) has _what access_ (role) for _which resource_. For example, Compute Engine virtual machine instances, Google Kubernetes Engine (GKE) clusters, and Cloud Storage buckets are all Google Cloud resources. The organizations, folders, and projects that you use to organize your resources are also resources.
|
||||
|
||||
In IAM, permission to access a resource isn't granted _directly_ to the end user. Instead, permissions are grouped into _roles_, and roles are granted to authenticated _principals_. (In the past, IAM often referred to principals as _members_. Some APIs still use this term.)
|
||||
|
||||
An _allow policy_, also known as an _IAM policy_, defines and enforces what roles are granted to which principals. Each allow policy is attached to a resource. When an authenticated principal attempts to access a resource, IAM checks the resource's allow policy to determine whether the action is permitted.
|
||||
|
||||
See:
|
||||
- [Identification](Identification.md) – "This is who I am"
|
||||
- [Authentication](../Standards/ISO27x/Authentication.md) – "This is how I prove it"
|
||||
- [Authorization](../Standards/ISO27x/Authorization.md) – "... then this is what you get access to"
|
||||
- [CISSP_Domain_5_1](../Standards/CISSP/CISSP_Domain_5_1.md), [CISSP_Domain_5_2](../Standards/CISSP/CISSP_Domain_5_2.md)
|
||||
- [Roles in Identity and Access Management (IAM)](../Literature%20notes/Roles%20in%20Identity%20and%20Access%20Management%20(IAM).md)
|
||||
Loading…
Add table
Add a link
Reference in a new issue