AWS is currently the pioneer and leading cloud service provider in the cloud market, with more than 200 services. AWS cloud has created a huge ecosystem to meet most cloud computing needs, with a large ecosystem that requires strict governance, flexibility and security. To avoid unnecessary loss, access management and decentralization are indispensable and extremely important when using the cloud. This article is intended to provide an overview of how AWS Identity and Access Management manages decentralization across resources.
1. Decentralization concept
Decentralization is the creation of a set of policies that decide “whether an entity is allowed to perform an action on a resource “.
- Policy – policy : is the most basic and important unit in the decentralization process, in aws, most policies have a json format and have syntax and structures that are specifically defined by aws.
- Subject – principal includes: user, role, federated user, application. Subject sends requests to perform an action on resouce.
- Action – action is the action to be performed on the resource defined in each service.
- Resource – resource is an object in service.With decentralization and identity aws to control access to resources from IAM Identity under the same account, ensure that services work together securely and control access to resources from out of account. Includes anonymous access outside of the account and anonymous access to public resources.
=> A service aws is decomposed into resource and resource actions of the service.
Refer to the service list
A policy is defined according to the json structure and includes the following basic attributes:
- Statement: Each policy has at least one statement, statement used to specify which action to execute and which resource is accessed. Statement consists of elements
- Sid : A string uniq used to identify statement
- Effect : Specifies the actions listed as Alllow / Deny
- Action : List the actions you want to execute (ec2: CreateImage, ec2: CreateNetworkAcl …)
- Principal : An account / user / role that is allowed or denied access to AWS resources
- Resource : It is the AWS resource that you want to apply the actions above
- Condition : Specifies the conditions that must be followed when applying this policy based on conditions keys defined by each resouce, action ( service-specific condition key ) and based on contex keys ( global condition keys ).
Each policy is a set of statements and each statement specifies that one or more DENY / ALLOW actions should be executed on one or more resources . Policy aws can specify the valid entity with the rule on statement with Principal based on Resource-base policy mechanism (only applies to some resources ).
3. IAM Identity
IAM Identities (users, groups, and roles) are the primary object that is authorized and uses the authority to perform actions.
- AWS account root user : The root user is created when you create an account, it has the highest authority in the account, can not be deleted and permissions modified. The root user should be using only separate tasks. Aws recommends against using a root user creating credentials and not using aws account root user for normal operations. aws_tasks-that-require-root
- IAM users is an object created by the user in aws and used to represent a person or service interacting with AWS. The IAM user can be authenticated by name and password or used with aws api, aws cli with generated credentials.
- IAM groups are a representation of a collection of users. Used to assign permissions to a group of users sharing a group of policies. A group is assigned the same authority as users based on attached policies and users in the group will also apply the same policies in that policy. Remember that it’s easy to manage permissions for each user group in your aws account.
- IAM roles are similar to users who are assigned policies to authorize them, but instead represent one person. Roles can be used to authorize a principal (which cannot be specified *). Characteristics:
- No long-term credentials or name password gives you aws access
- Used to grant temporary permissions to applications, users, and services that have not previously had access
- Iam role can grant temporary access to services resource access rights of another service (aws service role) or authorize access to another service ( aws service-linked role , AWS service role for an EC2 instance )
- The trust police mechanism is a resource-based police that allows the principal to determine which principals are allowed to use.
- Temporary credentials in IAM is a temporary license that is used for short-term tasks, temporary licenses that have access rights based on the specified IAM Identity (user or role).
In aws the user controls decentralization by creating policies – policies and attaching them to IAM identities (users, groups of users, or roles) or AWS resources. The set of policies in effect on the subject and on the resouce determines the outcome of ALLOW or DENY decentralization
To meet the needs of authorization for identifiers, resources, control of the authority of identifiers (IAM Identity) and determine the access rights of accounts in Origanizations. Aws uses many policy types for different purposes.
- Identity-based policies – json policy permission Identity-based policies are used to authorize Identity (users, roles, groups). It is in JSON format and is managed in 3 groups:
- Managed policies are independent policies you can use for many Identity. Divided into 2 categories
- AWS managed policies: These policies are created and managed by aws.
- Customer managed policies: policies are created and managed by users
- Inline policies policies created by the user and women are attached to a unique Identity and will be deleted when the identity is deleted.
- Guidelines for using indentity-based policy
- Managed policies are independent policies you can use for many Identity. Divided into 2 categories
- Resource-based policies – json policy permission is an inline policy attached to a resource, a resource-based policies stipulating principals to apply policies and use conditions to control access. It allows principals outside of the account to use resources in the account. Characteristics:
- When a resource-based policy designates a principal as a principal of another account, the principal still needs to be authorized to use resources by the Identity-based policy of the account that owns the principal (see example)
- IAM has a resource-based policy type, the trust role policy attached to the IAM role that allows the role to specify Trusted entities and perform cross-account access.
- IAM roles and resource-based policy are still distinct in cross-account access (more info).
- Permissions boundaries – json policy permission is a managed policy used for roles and users to limit the maximum decentralization of the subjects that can perform.
- The user or role cannot fulfill the requirements that violate policies that Permissions boundaries specified.
- Resource-based policy has not been limited by Permissions boundaries
- Permissions boundaries does not grant rights to the subject
- Organizations SCPs – json policy permission Use AWS Organizations service control policy (SCP) to define the maximum permissions for account members of an organization or organization unit (ou) . Likewise Permissions boundaries does not grant rights to the subject. Characteristics:
- Does not affect the external principals of the account in resource-based policy
- There is no restriction on user and role rights in the management account
- SCP applies to all users, the role includes the root users of the accounts added to aws Organizations or ou
- The SCP does not apply to service-linked roles
- Access control lists (ACLs) are used to allow cross-account access, and acl designates principals of other accounts to control access. ACL does not use JSON policy format, acl cannot be used with principals under the same account.
- Session policies – json policy permission is used for temporary crendentials or validated users to grant access to the applicable Identity-based policy temporary identifiers. It is understandable if a temporary crendentials not authorized by a session policy will be denied action or if the request is approved by the session policy but not authorized by the Identity-based policy will be denied.
If split according to the purpose of use, we will have: Identity-based policy, Session policy, Resource-based policy are authorization policies. For Permission boundaries, Organization SCPs are access restriction policies.
When a principal executes a request through aws api, aws cli, aws management console a request is sent to aws and processed in accordance with the following steps:
- Authentication – principals are authenticated by identity. In some cases with some services like s3 for access from anonymous users without identity authentication.
- Processing the request context – aws processes the information in the request and determines the policies that apply
- Evaluating policies within a single account – aws aggregates all policies according to the policy type, this affects the order of preference in policy evaluation.
- Determining whether a request is allowed or denied within an account – aws will determine whether the request is allowed or denied based on the policy has been aggregated and the request context
Process evaluation request ALLOW / DENY in the account
Aws is divided into 6 assessment steps based on the policy classification:
- Deny evaluation of any Deny statement in the policy from whatever policy type is compiled and first evaluated. If the Deny statement is applied, the request will be rejected
- Oraganizations policy If the principal belongs to an account that applies Organization policy from the SCP, the request must comply with the policy from the Oraganization policy, otherwise it will be denied. Even if the request comes from the aws account root user will still have to be authorized from the Oraganization policy.
- Resource-based policy If the policy from a Resource-based policy accepts the request, the request will be accepted immediately.
- IAM permission boundaries if the principal has permission boundaries and the request has not been authorized by the policies at IAM permission boundaries, the request will be denied.
- session policy if the principal is a temporary credentials it must comply with the session policy otherwise access is denied.
- Identity-based policy if the principal is not able to apply a resource-based policy, it must be authorized by the Identity-based policy to be enabled.
Accessing resources with an identifier belonging to another account requires authorization from a resource-based policy specified by the resource to be accessed.
The assessment process requires steps:
- Identity-based policy aggregation is applied to principals from Trusted AccountA and authenticates access from applicable policies.
- If the request is approved in the Trusted AccountA will be sent to Trusting AccountB, it will continue to be confirmed by the resource-based policy that applies to the resource. If approved the request will be made.
With aws IAM allows you to implement two decentralization strategies Attribute-based access control (ABAC) and role-based access control (RBAC). Inside:
- Role-based decentralization RBAC is the decentralized way in which you create permissions according to user roles (Dev, Database admin, …). In IAM, this is equivalent to creating policies and attaching identifiers. This helps to minimize privileges for users
- ABAC has a property-based decentralization whereby policies define the delegation based on the resource’s and the user’s attributes. From there, achieve flexibility and easy control of decentralization. In IAM ABAC is used based on tags attached to resources and Identity to easily decentralize groups of resources and identifiers.
This article outlines the basic concepts that people need to be able to use IAM AWS, for details, readers can refer to the documents attached in the article. Most of the articles are translated from aws’ documents and some personal identifications may have made mistakes, so I would like to hear from readers for comments to improve the article.