29 lines
No EOL
2.9 KiB
Markdown
29 lines
No EOL
2.9 KiB
Markdown
## 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)
|
||
|
||
## 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) |