Amazon AWS Security Concepts: Difference between revisions

From NovaOrdis Knowledge Base
Jump to navigation Jump to search
 
(243 intermediate revisions by the same user not shown)
Line 14: Line 14:


=AWS Account=
=AWS Account=
{{External|https://docs.aws.amazon.com/IAM/latest/UserGuide/console_account-alias.html}}


The AWS Account is identified by a 12 digit '''account ID''' or an '''alias'''. Each AWS account has associated a special sign-in identity that has complete access to all AWS services and resources in the account, called [[#AWS_Account_Root_User|AWS account root user]]. Each AWS account has its own billing and subscriptions to AWS products. To create an AWS account, go to http://aws.amazon.com, and then click Sign Up. For more details see http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/get-set-up-for-amazon-ec2.html.
The AWS Account is identified by a 12 digit '''account ID''' or an '''alias'''. There's no mention of "account name" in [https://docs.aws.amazon.com/IAM/latest/UserGuide/console_account-alias.html AWS documentation]. Each AWS account has associated a special sign-in identity that has complete access to all AWS services and resources in the account, called [[#AWS_Account_Root_User|AWS account root user]]. Each AWS account has its own billing and subscriptions to AWS products. Each AWS account has its own IAM users, groups and roles. To create an AWS account, go to http://aws.amazon.com, and then click Sign Up. For more details see http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/get-set-up-for-amazon-ec2.html. It is a common practice to keep different environments separated from each other by using different AWS accounts, one per environment. This approach helps with resource isolation.  


=<span id='AWS_User'></span>AWS Account Root User=
==Account ID==
{{External|https://docs.aws.amazon.com/general/latest/gr/acct-identifiers.html}}
 
The AWS Account ID is a 12-digit number, which uniquely identifies an AWS account.
 
The AWS account ID is reported on command line by:
[[AWS_Security_Operations#IAM_Information|aws sts get-caller-identity]]
 
The sign-in page URL has the following format by default:
<syntaxhighlight lang='text'>
https://<Account_ID>.signin.aws.amazon.com/console/
</syntaxhighlight>
 
==Account Alias==
A reason to introduce an account alias is to give a friendly name to the sign-in page. If an alias is created, then the sign-in page can also be accessed at:
<syntaxhighlight lang='text'>
https://<Account_Alias>.signin.aws.amazon.com/console/
</syntaxhighlight>
The AWS account can have only one alias. If a new alias is created, the new alias overwrites the previous alias, and the URL containing the old alias stop working. The account alias must be unique across all AWS products. It must contain only digits, lowercase letters and hyphens.
 
The account alias can be obtained with [[AWS_Security_Operations#List_AWS_Account_Aliases|list-account-aliases]] IAM CLI operation.
 
==<span id='AWS_User'></span>AWS Account Root User==
{{External|[https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html The AWS Account Root User]}}
{{External|[https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html The AWS Account Root User]}}


Line 23: Line 46:


AWS services require that you provide credentials when you access them. The console requires your password. You can create access keys for your [[#AWS_Account|AWS account]] to access the command line interface or API. However, [https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#create-iam-users it is not recommended to access AWS using the credentials for your AWS account root user]. Use an [[#IAM_User|IAM user]], which is an authenticated identity associated with a person, system, or application who can use AWS products, each with individual security credentials, all controlled by and billed to a single [[#AWS_Account|AWS account]]. The IAM user is provisioned with  [[#IAM_.28AWS_Identity_and_Access_Management.29|IAM]].
AWS services require that you provide credentials when you access them. The console requires your password. You can create access keys for your [[#AWS_Account|AWS account]] to access the command line interface or API. However, [https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#create-iam-users it is not recommended to access AWS using the credentials for your AWS account root user]. Use an [[#IAM_User|IAM user]], which is an authenticated identity associated with a person, system, or application who can use AWS products, each with individual security credentials, all controlled by and billed to a single [[#AWS_Account|AWS account]]. The IAM user is provisioned with  [[#IAM_.28AWS_Identity_and_Access_Management.29|IAM]].
==Cross-Account Delegation Access==
{{Internal|AWS Cross-Account Delegation Access|Cross-Account Delegation Access}}


=IAM (AWS Identity and Access Management)=
=IAM (AWS Identity and Access Management)=
Line 40: Line 67:
IAM, like many other AWS services, is eventually consistent. IAM achieves high availability by replicating data across multiple servers within Amazon's data centers around the world. If a request to change some data is successful, the change is committed and safely stored. However, the change must be replicated across IAM, which can take some time. Such changes include creating or updating users, groups, roles, or policies.
IAM, like many other AWS services, is eventually consistent. IAM achieves high availability by replicating data across multiple servers within Amazon's data centers around the world. If a request to change some data is successful, the change is committed and safely stored. However, the change must be replicated across IAM, which can take some time. Such changes include creating or updating users, groups, roles, or policies.


=IAM Identities=
=IAM Identifiers=
==Friendly Name==
Also see [[#Path|path]], below.
==IAM ARN==
==IAM Unique ID==
{{External|https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_identifiers.html#identifiers-unique-ids}}
 
When IAM creates a user, user group, role, policy, instance profile or server certificate, it assigns to each resource a unique ID, with standard prefixes:
 
{| class="wikitable" style="text-align: left;"
! Prefix
! Resource Type
|-
|  ABIA || [https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_bearer.html AWS STS service bearer token]
|-
|  ACCA || Context-specific credential
|-
| <span id='AGPA'></span>AGPA  || [[#IAM_Group|IAM Group]]
|-
|  <span id='AIDA'></span>AIDA || [[#IAM_User|IAM User]]
|-
| AIPA || Amazon EC2 instance profile
|-
| AKIA || Access key
|-
| ANPA || Managed policy
|-
| ANVA || Version in a managed policy
|-
| APKA || Public key
|-
| <span id='AROA'></span>AROA  || [[#IAM_Role|IAM Role]]
|-
| ASCA || Certificate
|-
| ASIA || [https://docs.aws.amazon.com/STS/latest/APIReference/API_Credentials.html Temporary (AWS STS) access key IDs]
|-
|}
 
=<span id='IAM_Identity'></span>IAM Identities=
 
An IAM identity is a [[#IAM_User|IAM user]], a [[#IAM_Group|group of users]] or a [[#IAM_Role|role]]. IAM identities get [[#IAM_Permission_Policy|permission policies]] attached to them, and the [[#Permission|permissions]] specified in these policy define what kind of access the identity has for a specific AWS resource.
 
The IAM identity of a user making an AWS CLI call is reported on command line by:
[[AWS_Security_Operations#IAM_Information|aws sts get-caller-identity]]
 
<syntaxhighlight lang='text'>
{
    "UserId": "AIXXXXXXXXXXXXXXXXXXX",
    "Account": "999999999999",
    "Arn": "arn:aws:iam::999999999999:user/test-user"
}
</syntaxhighlight>
 
==IAM User==
==IAM User==
{{External|[https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users.html IAM User]}}
{{External|[https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users.html IAM User]}}


An IAM user is an entity with an authenticated identity associated with a person, system, or application who can use AWS products, each with individual security credentials, all controlled by and billed to a single [[#AWS_Account|AWS account]]. With IAM, each user is allowed to do only what they need to do as part of the user's job.
An IAM user is an entity with an authenticated identity associated with a person, system, or application who can use AWS products, each with individual security credentials, all controlled by and billed to a single [[#AWS_Account|AWS account]]. With IAM, each user is allowed to do only what they need to do as part of the user's job.
  [[#AWS_Account_Root_User|AWS account root user]] (ovidiu@novaordis.com)
<font size=-1>
       |
  [[#AWS_Account_Root_User|AWS account root user]] (ovidiu@acme.com)
      +---- IAM Users
  └─ IAM Users
                |
       └─ ofeodorov
                +-- ofeodorov
</font>
When a new user is created, its [[#IAM_Unique_ID|IAM unique ID]] is prefixed by "[[#AIDA|AIDA]]".


===IAM User Operations===
===IAM User Operations===
* [[AWS_Security_Operations#Create_an_IAM_User|Creating an IAM User]]
* [[AWS_Security_Operations#List_IAM_Users|List IAM users]]
* [[AWS_Security_Operations#Get_more_Information_about_my_IAM_User|Get more information about my IAM user]]
* [[AWS_Security_Operations#Create_an_IAM_User|Create an IAM user]]


==IAM Group==
==IAM Group==
{{External|[https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html IAM Group]}}
{{External|[https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html IAM Group]}}


An IAM Group is a collection of [[#IAM_User|IAM users]], whose main purpose is to define permissions for multiple users.
An IAM Group is a collection of [[#IAM_User|IAM users]], whose main purpose is to define permissions for multiple users. When a new group is created, its [[#IAM_Unique_ID|IAM unique ID]] is prefixed by "[[#AGPA|AGPA]]".


===IAM Group Operations===
===IAM Group Operations===
Line 66: Line 149:
{{External|[https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html IAM Roles]}}
{{External|[https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html IAM Roles]}}


An IAM role is an IAM identity that has specific permissions. The permissions are associated with the role via [[#IAM Permission Policy|permission policies]]. From this perspective, an IAM role is similar to an IAM user, in that it is an AWS identity with permission policies that determine what the identity can and cannot do in AWS. However, instead of being uniquely associated with one person, a role is intended to be assumable by anyone who needs it. Also, a role does not have standard long-term credentials such as a password or access keys associated with it. Instead, the role can be assumed and it provides to the user assuming it temporary security credentials for the role session.
An IAM role is an [[#IAM_Identity|IAM identity]] that associates specific [[#Permission_Policy|permission policies]], which ultimately translate to specific [[#Permission|permissions]], for a set duration of time, to another entity.  When a new role is created, its [[#IAM_Unique_ID|IAM unique ID]] is prefixed by "[[#AROA|AROA]]".
 
An IAM Role can be conceptually thought of as a set of [[#Temporary_Security_Credentials|temporary credentials]]. It is also important to understand that there can be just one role in effect at a time - a single set of security credentials. There is not such a thing as multiple roles at the same time.
 
The entities an IAM role can be associated with are [[#IAM_User|IAM users]], application code running on an EC2 instance that needs to perform actions on AWS resource, an AWS service that needs to act on a resource on a user's account to provide its features, users from a corporate directory who use identity federation with SAML, etc.
 
A role works by issuing keys that are valid for short durations, making them a more secure way to grant access. The role does not have standard long-term credentials such as a password or long-lived access keys associated with it. The role provides the entity assuming it temporary security credentials for the [[#Role_Session|role session]].
 
A role contains:
* one (or more) [[#IAM_Permission_Policy|permission policies]], which tell what individual permissions the role has, what resources can be accessed and what [[#Action|actions]] can be performed on these resources.
* the "trust relationship", which consists of one and only one [[#Trust_Policy|trust policy]] that says what [[#Trusted_Entity|trusted entities]] can assume this role.
 
From this perspective, an IAM role is similar to an IAM user, in that it is an [[#IAM_Identities|IAM identity]] with permission policies that determine what the identity can and cannot do in AWS and also what [[#Trusted_Entity|trusted entities]] can assume this identity. However, instead of being uniquely associated with one person, a role is intended to be assumable by anyone who needs it.


An IAM role also includes a [[#Trust_Policy|trust policy]].
Roles can be used to delegate permissions to an [[Amazon_AWS_Concepts#AWS_Service|AWS service]] to carry out actions in behalf of the logged in user, to enable application code running in EC2 to access and modify resources, to grant access to users from another AWS account or to enable federated sign-in.
 
::[[File:AWSIAMRole.png]]
 
===Assuming a Role===
{{External|[https://aws.amazon.com/premiumsupport/knowledge-center/iam-assume-role-cli/ How do I assume an IAM role using the AWS CLI?]}}
{{External|[https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-cli.html Switching to an IAM Role (AWS CLI)]}}
 
An entity can assume a role. "Assuming a role" means that the credentials the entity interacts with AWS resources change. When the role is assumed, the role issues [[Amazon_AWS_Security_Concepts#Temporary_Security_Credentials|temporary security credentials]] that can be used to access resources or call [[Amazon_AWS_Concepts#AWS_Service|AWS services]]. This is a security best practice, which consists in using short term credentials.
 
The role carries a [[#AssumeRolePolicyDocument|policy]] that grants the entity the permission to assume the role.  
 
More practical details on how a role can be assumes are available in the Operations page: {{Internal|AWS_Security_Operations#Assuming_an_IAM_Role|Assuming an IAM Role}}


===Role Attributes===
===Role Attributes===
Line 84: Line 191:
====AssumeRolePolicyDocument====
====AssumeRolePolicyDocument====


Declares the policy that grants an entity permission to assume this role. The policy specifies which entities (for example service) are allowed to assume the role.
Declares the [[#Trust_Policy|trust policy]] that grants an entity permission to [[#Assuming_a_Role|assume]] this role. The policy specifies which entities (for example service) are allowed to assume the role.


====Policies====
====Policies====


The list of policies implied by the role.
The list of [[#Permission_Policy|permission policies]] implied by the role.


===AWS Service Role===
===<span id='Trust_Policy'></span><span id='Trust_Relationship'></span>Trust Policy===
An [[#IAM_Role|IAM role]], and in general an IAM identity, has one, and only one trust policy. The trust policy specifies what [[#Trusted_Entity|entities]] can assume the identity - a trust relationship defines who can assume a role. This can be visually inspected in the AWS IAM Console, selecting a role shows its [[#Trusted_Entity|Trusted entities]] in a dedicated column.
 
When a role is created with AWS Console, the trust policy is created automatically and it can be customized afterwards.
 
In the trust policy example below, the entity that can assume ([[AWS_Security_Token_Service#sts:AssumeRole|sts:AssumeRole]]) the role with this trust policy is the "ec2.amazonaws.com" service, but the trust policy can contain more than one principals ([[#AWS_Account|AWS account]], [[#IAM_User|IAM user]], [[#IAM_Role|IAM role]], federated user or assumed-role user). More details about the content of the "Principal" section are available in the [[#Trusted_Entity|Trusted Entity]] section, below.
<span id='Trust_Policy_Example'></span><syntaxhighlight lang='json'>
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "sts:AssumeRole",
      "Principal": {
          "Service": "ec2.amazonaws.com",
          "AWS": [
            "arn:aws:iam::123456789012:root",
            "arn:aws:iam::999999999999:user/some.user"
          ]
      },
      "Condition": { "Bool": { "aws:MultiFactorAuthPresent": "true" } }
    }
  ]
}
</syntaxhighlight>
 
====Trusted Entity====
{{External|[https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_principal.html AWS JSON Policy Elements: Principal]}}
 
The trusted entity is defined in the "Principal" section Trusted entities can be:
* an [[#AWS_Account|AWS account]], declared as "arn:aws:iam:999999999999:root" in the Principal section of the trust policy.
* an [[#IAM_User|IAM User]], declared as "arn:aws:iam::999999999999:user/example-username" in the Principal section of the trust policy.
* an identity provider
 
If the entity that eventually needs to assume the role is different from the entities listed in the "Principal" section, there must be at least one principal there that allows the end recipient to assume the role. For more details, see [https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-user.html Creating a Role to Delegate Permissions to an IAM User].


An AWS Service Role is a role that a service assumes to perform actions in a user's account, on the user's behalf. The service role must include all permissions required for the service to access the AWS resources it needs. Service roles provide access only within user's account and cannot be used to grant access to services in other accounts. A service role works if the user who attempts to use it has the permissions to [[#Granting_a_User_Permissions_to_Pass_a_Role_to_an_AWS_Service|pass]] it (iam:PassRole).
If the Principal element contains the ARN for a specific IAM role or user, then that ARN is transformed to a unique principal ID when the policy is saved. This helps mitigate the risk of someone escalating their permissions by removing and recreating the role or user. The unique principal ID is not normally seen in the console because there is also a reverse transformation back to the ARN when the trust policy is displayed. However, if the the role or user is deleted, then the principal ID appears in the console because AWS can no longer map it back to an ARN. Therefore, if you delete and recreate a user or role referenced in a trust policy's Principal element, you must edit the role to replace the ARN.


===Granting a User Permissions to Pass a Role to an AWS Service===
====Trust Policy Operations====
* [[AWS_Security_Operations#Create_a_Trust_Policy|Create a trust policy]]
* [[AWS_Security_Operations#Edit_in_Console|Edit the trust policy for a role in console]]
* [[AWS_Security_Operations#Enable_an_IAM_User_to_Assume_an_IAM_Role|Enable an IAM User to assume an IAM Role]]


{{External|[https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_passrole.html Granting a User Permissions to Pass a Role to an AWS Service]}}
===AWS Service Role===


To pass a role and implicitly its permissions to an [[Amazon_AWS_Concepts#AWS_Service|AWS service]], a user must have permissions to pass the role to the service. This helps administrators ensure that only approved users can configure a service with a role that grants permissions. To allow a user to pass a role to an AWS service, the user must be granted the PassRole permission, either directly, or to one of its roles or groups.
An AWS Service Role is a role that a service assumes to perform actions in a user's account, on the user's behalf. The service role must include all permissions required for the service to access the AWS resources it needs. Service roles provide access only within user's account and cannot be used to grant access to services in other accounts. A service role works if the user who attempts to use it has the permissions to [[#Granting_a_User_Permissions_to_Pass_a_Role_to_an_AWS_Service|pass]] it ([[#iam:PassRole|iam:PassRole]]).


===AWS Service Role for an EC2 Instance===
====AWS Service Role for an EC2 Instance====
{{External|[https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-ec2.html Using an IAM Role to Grant Permissions to Applications Running on Amazon EC2 Instances]}}
{{External|[https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-ec2.html Using an IAM Role to Grant Permissions to Applications Running on Amazon EC2 Instances]}}
{{External|[https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/iam-roles-for-amazon-ec2.html IAM Roles for Amazon EC2]}}
{{External|[https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/iam-roles-for-amazon-ec2.html IAM Roles for Amazon EC2]}}
Line 107: Line 251:


The recommended alternative is to give the EC2 instance a special service role, via a mechanism named [[#Instance_Profile|instance profile]]. The service role can then be assumed by the application running on the EC2 instance, allowing it to perform actions. The role is assigned to the EC2 instance when it is launched. Applications running on that instance can retrieve role-supplied [[#Temporary_Security_Credentials|temporary security credentials]] and perform actions that the role allows. The temporary credentials are rotated automatically, so the developers do not have to manage credentials and do not have to worry about long-term security risks.
The recommended alternative is to give the EC2 instance a special service role, via a mechanism named [[#Instance_Profile|instance profile]]. The service role can then be assumed by the application running on the EC2 instance, allowing it to perform actions. The role is assigned to the EC2 instance when it is launched. Applications running on that instance can retrieve role-supplied [[#Temporary_Security_Credentials|temporary security credentials]] and perform actions that the role allows. The temporary credentials are rotated automatically, so the developers do not have to manage credentials and do not have to worry about long-term security risks.
====Instance Profile====
 
The sequence of operations required to set up and use an EC2 service role is:
* Define the service role, [[AWS_Security_Operations#Create_an_EC2_Service_Role|via the console]] or programmatically.
* [[Amazon_EC2_Operations#Create_an_Instance_Profile|Create the instance profile]].
* [[Amazon_EC2_Operations#Add_a_Role_to_an_Instance_Profile|Add the created role to the instance profile]].
* [[Amazon_EC2_Operations#Associate_an_Instance_Profile_with_an_EC2_Instance|Associate the instance profile with the EC2 instance]].
* Create the EC2 instance.
* [[Amazon_EC2_Operations#Use_Temporary_Credentials_Made_Available_via_Instance_Metadata|Use temporary credentials made available via instance metadata]].
 
=====Instance Profile=====
{{External|[https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-ec2_instance-profiles.html Using Instance Profiles]}}
{{External|[https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-ec2_instance-profiles.html Using Instance Profiles]}}


An instance profile is a container for one - and only one - [[#AWS_Service_Role_for_an_EC2_Instance|EC2 service role]], and it is used to pass information about this role to the EC2 instance when it starts. An instance profile can contain only one IAM role, though a role can be included in multiple instance profiles. The existing role can be removed from the instance profile, and a different role can be added to it. This kind of change propagates across all AWS through eventual consistency.
An instance profile is a container for one and only one [[#AWS_Service_Role_for_an_EC2_Instance|EC2 service role]], and it is used to pass information about this role to the EC2 instance when it starts. An instance profile can contain only one IAM role, though a role can be included in multiple instance profiles. The existing role can be removed from the instance profile, and a different role can be added to it. This kind of change propagates across all AWS through eventual consistency:
 
<syntaxhighlight lang='json'>
{
  "Path": "/",
  "InstanceProfileName": "my-instance-profile",
  "InstanceProfileId": "BIPAIOJX2D4X5IJ3RBOZ8",
  "Arn": "arn:aws:iam::000000000000:instance-profile/my-instance-profile",
  "CreateDate": "2018-06-29T12:54:14Z",
  "Roles": [
    {
      "Path": "/",
      "RoleName": "my-ec2-role",
      "RoleId": "BROAIARHQAIPLH2K2UOO8",
      "Arn": "arn:aws:iam::000000000000:role/service-role/my-ec2-role",
      "CreateDate": "2018-06-29T12:54:14Z",
      "AssumeRolePolicyDocument": {
        "Version": "2012-10-17",
        "Statement": [
        {
          "Effect": "Allow",
          "Principal": {
              "Service": "ec2.amazonaws.com"
            },
          "Action": "sts:AssumeRole"
        }
        ]
      }
    }
  ]
}
</syntaxhighlight>


The instance profile mechanism is needed because an application running on an EC2 instance is abstracted from AWS by the virtualized operating system. Because of this extra separation, an additional step is needed to assign an AWS role and its associated permissions, and this step is the creation of the instance profile.
The instance profile mechanism is needed because an application running on an EC2 instance is abstracted from AWS by the virtualized operating system. Because of this extra separation, an additional step is needed to assign an AWS role and its associated permissions, and this step is the creation of the instance profile.


IAM console provides transparent management of the instance profile. However, if CLI or API are involved, the instance profile must be first [[Amazon_EC2_Operations#Associate_an_Instance_Profile_with_an_EC2_Instance|created]], then [[Amazon_EC2_Operations#Create_an_Instance_Profile|associated]] with the EC2 instance in two separate steps.
IAM console provides transparent management of the instance profile. However, if CLI or API are involved, the instance profile must be first [[Amazon_EC2_Operations#Create_an_Instance_Profile|created]], then [[Amazon_EC2_Operations#Associate_an_Instance_Profile_with_an_EC2_Instance|associated]] with the EC2 instance in two separate steps.
 
The instance profile is one of the credential providers in the [[#Credential_Providers|credential provider chain]].
 
An instance profile can be granted [[AWS_Cross-Account_Delegation_Access|cross-account delegation access]] via an IAM policy.


=====Instance Profile Operations=====
======Instance Profile Operations======
* [[Amazon_EC2_Operations#Associate_an_Instance_Profile_with_an_EC2_Instance|Create an Instance Profile]]
* [[Amazon_EC2_Operations#View_Existing_Instance_Profiles|View Existing Instance Profiles]]
* [[Amazon_EC2_Operations#Create_an_Instance_Profile|Associate an Instance Profile with an EC2 Instance]]
* [[Amazon_EC2_Operations#Create_an_Instance_Profile|Create an Instance Profile]]
* [[Amazon_EC2_Operations#Add_a_Role_to_an_Instance_Profile|Add a Role to an Instance Profile]]
* [[Amazon_EC2_Operations#Associate_an_Instance_Profile_with_an_EC2_Instance|Associate an Instance Profile with an EC2 Instance]]
 
===Granting a User Permissions to Pass a Role to an AWS Service===
 
{{External|[https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_passrole.html Granting a User Permissions to Pass a Role to an AWS Service]}}
 
To pass a role and implicitly its permissions to an [[Amazon_AWS_Concepts#AWS_Service|AWS service]], a user must have permissions to pass the role to the service. This helps administrators ensure that only approved users can configure a service with a role that grants permissions. To allow a user to pass a role to an [[Amazon_AWS_Concepts#AWS_Service|AWS service]], the user must be granted the [[#iam:PassRole|iam:PassRole]] permission, either directly, or to one of its roles or groups.


===AWS Service-Linked Role===
===AWS Service-Linked Role===
===Role Session===


===Trust Relationship===
The role session has a maximum duration, which can be configured in the AWS console from the role UI.


===IAM Role Operations===
===IAM Role Operations===


* [[AWS_Security_Operations#List_IAM_Roles|List roles]]
* [[AWS_Security_Operations#Get_Details_about_a_Specific_Role|Get details about a specific IAM Role]]
* [[AWS_Security_Operations#Create_an_IAM_Role|Create an IAM Role]]
* [[AWS_Security_Operations#Create_an_IAM_Role|Create an IAM Role]]
* [[AWS_Security_Operations#Create_an_EC2_Service_Role|Create an EC2 Service Role]]
* [[AWS_Security_Operations#Create_an_EC2_Service_Role|Create an EC2 Service Role]]


=IAM Identifiers=
=<span id='IAM_Policy'></span><span id='IAM_Permission_Policy'></span>Permission Policy=


==Friendly Name==
{{External|[https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html Policies and Permissions]}}


Also see [[#Path|path]], below.
An [[#IAM_Identity|IAM identity]] has a set of permission policies, which specifies what [[#Permission|permissions]] the identity has. In other words, the permission policy specifies what resources can be accessed and what [[#Action|actions]] can be performed on these resources.  


==IAM ARN==
Permission policies can get associated with [[#IAM_Identity|IAM identities]] ([[#IAM_Role|IAM Roles]], [[#IAM_User|IAM Users]], [[#IAM_Group|IAM Groups]]) or with AWS resources.
==IAM Unique ID==


=<span id='IAM_Policy'></span><span id='Permission_Policy'></span>IAM Permission Policy=
The policies control what [[#Action|actions]] an entity can perform, on which resources, and under what conditions.  Most policies are stored in AWS as JSON documents. AWS supports six types of policies:
# [[#Identity-Based_Policies|identity-based policies]]
# [[#Resource-Based_Policies|resource-based policies]]
# [[#IAM_Permissions_Boundaries|permissions boundaries]]
# [[#Service_Control_Policies_.28SCPs.29|organizations service control policies (SCPs)]]
# [[#Access_Control_Policies_.28ACLs.29|access control policies (ACLs)]]
# [[#Session_Policies|session policies]]


{{External|[https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html Policies and Permissions]}}
==Types of Permission Policies==


An [[#IAM_Role|IAM role]] has a permission policy, which specifies what permissions the role has.
===Identity-Based Policies===


==Identity-Based Policies==
Identity-based policies are JSON permissions policy documents that can be attached to an [[#IAM_Identities|identity]] ([[#IAM_User|user]], [[#IAM_Group|group]], [[#IAM_Role|role]]) and grant permissions to that identity, hence the name. Identity-based policies can be:
#[[#Managed_Policies|managed policies]]
#[[#Inline_Policies|inline policies]]


Identity-based policies are JSON permissions policy documents that can be attached to an [[#IAM_Identities|identity]] ([[#IAM_User|user]], [[#IAM_Group|group]], [[#IAM_Role|role]]). These policies control what actions an entity (user or role) can perform, on which resources, and under what conditions. Identity-based policies can be [[#Managed_Policies|managed policies]] and [[#Inline_Policies|inline policies]]:
====<span id='Managed_Policy'></span>Managed Policies====


===<span id='Managed_Policy'></span>Managed Policies===
A managed policy is a standalone identity-based policy that can be attached to multiple [[#IAM_User|users]], [[#IAM_Group|groups]], and [[#IAM_Role|roles]] in an AWS account. There are two types of managed policies:


A managed policy is a standalone identity-based policy that can be attached to multiple [[#IAM_User|users]], [[#IAM_Group|groups]], and [[#IAM_Role|roles]] in an AWS account. There are two types of managed policies:
=====<span id='AWS_Managed_Policies'></span>AWS Managed Policies=====
 
[[#Managed_Policy|Managed policies]] that are created and managed by AWS. They can be quickly visually identified by their icon:


====<span id='AWS_Managed_Policies'></span>AWS Managed Policies====
[[File:AWSManagedPolicy.png]]


[[#Managed_Policy|Managed policies]] that are created and managed by AWS. The [[Amazon AWS Concepts#ARN|ARN]] of a policy that is managed by AWS is:
The [[Amazon AWS Concepts#ARN|ARN]] of a policy that is managed by AWS is:


   arn:aws:iam::aws:policy/<font color=teal>''PolicyName''</font>
   arn:aws:iam::aws:policy/<font color=teal>''PolicyName''</font>
Line 160: Line 368:
[[File:AWSManagedPolicies.png]]
[[File:AWSManagedPolicies.png]]


====Customer Managed Policies====
=====Customer Managed Policies=====


Customer managed policies are [[#Managed_Policy|managed policies]] create and manage by users in an AWS account. Customer managed policies provide more precise control over policies than [[#AWS_Managed_Policy|AWS managed policies]]. IAM policy can be created and edited in a visual editor or by creating the JSON policy document directly.  Once created, policies are referenced by their [[Amazon AWS Concepts#ARN|ARN]]s. The [[Amazon AWS Concepts#ARN|ARN]] of a customer-managed policy is:
Customer managed policies are [[#Managed_Policy|managed policies]] create and manage by users in an AWS account. Customer managed policies provide more precise control over policies than [[#AWS_Managed_Policy|AWS managed policies]]. IAM policy can be created and edited in a visual editor or by creating the JSON policy document directly.  Once created, policies are referenced by their [[Amazon AWS Concepts#ARN|ARN]]s. The [[Amazon AWS Concepts#ARN|ARN]] of a customer-managed policy is:
Line 166: Line 374:
   arn:aws:iam::<font color=teal>''AWS-account-number''</font>:policy/<font color=teal>''PolicyName''</font>
   arn:aws:iam::<font color=teal>''AWS-account-number''</font>:policy/<font color=teal>''PolicyName''</font>


Operations:
======Customer Managed Policy Example======
 
A permission policy is a collection of [[#Permission|permissions]]:
<syntaxhighlight lang='json'>
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": ["ec2:*"],
      "Resource": ["*"]
    },
    {
      "Effect": "Allow",
      "Action": ["elasticloadbalancing:*"],
      "Resource": ["*"]
    },
    {
      "Effect": "Allow",
      "Action": "s3:*",
      "Resource": [
        "arn:aws:s3:::kubernetes-*"
      ]
    }
    ...
  ]
}
</syntaxhighlight>
 
======Customer Managed Policies Operations======
* [[AWS_Security_Operations#Create_an_IAM_Policy|Create an IAM Policy]]
* [[AWS_Security_Operations#Create_an_IAM_Policy|Create an IAM Policy]]
* [[AWS_Security_Operations#Edit_an_IAM_Policy|Edit an IAM Policy]]
* [[AWS_Security_Operations#Edit_an_IAM_Policy|Edit an IAM Policy]]
* [[AWS_Security_Operations#Attaching_a_Policy_to_an_IAM_User|Attach a policy to a IAM User]]
* [[AWS_Security_Operations#Listing_Attached_a_Policies_to_an_IAM_User|Listing attached a policies to an IAM User]]


===<span id='Inline_Policy'></span>Inline Policies===
====<span id='Inline_Policy'></span>Inline Policies====


Policies created by users and that are embedded directly into a single user, group, or role. In most cases, inline policies usage is not recommended:
Policies created by users and that are embedded directly into a single user, group, or role. In most cases, inline policies usage is not recommended:
Line 176: Line 415:
{{External|[https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html Managed Policies and Inline Policies]}}
{{External|[https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html Managed Policies and Inline Policies]}}


==Resource-Based Policies==
===Resource-Based Policies===


==Difference between Identity-Based Policies and Resource-Based Policies==
===Difference between Identity-Based Policies and Resource-Based Policies===


{{External|[https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_identity-vs-resource.html Identity-Based Policies and Resource-Based Policies]}}
{{External|[https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_identity-vs-resource.html Identity-Based Policies and Resource-Based Policies]}}


==IAM Permissions Boundaries==
===IAM Permissions Boundaries===
==Service Control Policies (SCPs)==
===Service Control Policies (SCPs)===
==Access Control Policies (ACLs)==
===Access Control Policies (ACLs)===
==Session Policies==
===Session Policies===
 
==Permission==
 
A permission is a piece of information that specifies what kind of access the bearer of the permission has a specific AWS resource. A permission is associated with an [[#IAM_Identity|IAM identity]], a [[#IAM_Role|role]] for example, via [[#IAM_Permission_Policy|permission policies]]. AWS evaluates the permission present in the policy when a principal entity (user or role) makes a request. Permissions in the policies determine whether the request is allowed or denied. Permissions for an action are valid regardless of the method that is used to perform the operation on a resource. For example, if a policy allows the GetUser action, then a user with that policy can get user information from the AWS Management Console, the AWS CLI, or the AWS API.
 
The JSON rendering of an individual permission is similar to:
 
<syntaxhighlight lang='json'>
{
  "Effect": "Allow",
  "Action": [
    "ec2:AttachVolume",
    "ec2:CreateSnapshot",
    ...
  ],
  "Resource": "*"
}
</syntaxhighlight>
 
The permission consists of an "effect" ("Allow" or "Deny"), an [[#Action|action]], such as "ec2:AttachVolume", and a list of resources permission applies to. Optionally, the permission may include a "condition".


=API Access Keys=
===Action===
Note that the actions are sometimes referred to as "permissions", which implies that the action is part of a formal permission construct associated with the entity requiring it.


Each [[#IAM_User|IAM user]] has a set of API access keys. These keys are needed when the user attempts to make programmatic calls to AWS or EC2, using [[Amazon EC2 CLI]] tools for example. The user can create, modify, view and rotate these access keys.
* <span id='CreateRole'>[https://docs.aws.amazon.com/IAM/latest/APIReference/API_CreateRole.html iam:CreateRole]
* <span id='CreatePolicy'>[https://docs.aws.amazon.com/IAM/latest/APIReference/API_CreatePolicy.html iam:CreatePolicy]
* <span id='iam:PassRole'></span>iam:PassRole. This is often referred to as a "permission", which means "permission that contains this action".
* [[Amazon_EKS_Concepts#EKS_IAM_Permissions|EKS actions]]


There are two types of access keys:
=<span id='API_Access_Keys'></span>API Access Key=
{{External|https://docs.aws.amazon.com/general/latest/gr/aws-sec-cred-types.html#access-keys-and-secret-access-keys}}
{{External|https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html}}


# '''Access key ID''' (example <tt>AKIAIOSFODNN7EXAMPLE)</tt>)
Each [[#IAM_User|IAM user]] has a set of API access keys. These keys are needed when the user attempts to make programmatic calls to the AWS backend, using [[Amazon EC2 CLI]] tools or the [[AWS_SDK_for_Java#Subjects|AWS SDK for Java]]. The keys are used to [[Amazon_AWS_Concepts#Signing_API_Calls|sign the calls]]. The user can create, modify, view and rotate these access keys.
# '''Secret access key''' (example: <tt>wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY</tt>)


When creating an access key, IAM returns the access key id and the secret access key. The secret access key is only accessible at the time it was created. If the secret access key is lost, the corresponding access key must be deleted and recreated.
An access keys consists of two items:


<font color=red>Relationship between Access Key ID and Secret Key?</font>
# <span id='Access_Key_ID'></span>an '''Access Key ID''' (example <tt>AKIAIOSFODNN7EXAMPLE)</tt>)
# a <span id='Secret_Access_Key'></span>'''Secret Access Key''' (example: <tt>wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY</tt>)


The access keys can be managed here: https://console.aws.amazon.com/iam/home?#security_credential by navigating to Users -> username -> Security Credentials -> Access Credentials.
When creating an access key, IAM returns the access key ID and the secret access key. The secret access key is only accessible at the time it was created. If the secret access key is lost, the corresponding access key must be deleted and recreated. <font color=darkgray>What is the relationship between Access Key ID and Secret Key?</font>


More about access keys for IAM users: http://docs.aws.amazon.com/IAM/latest/UserGuide/ManagingCredentials.html
The access keys can be managed here: https://console.aws.amazon.com/iam/home?#security_credential by navigating to Users → username → My security credentials → AWS IAM credentials → Access keys for CLI, SDK, & API access.


For details on how access keys can be set in the local environment, see [[Amazon EC2 CLI Installation#Set_the_Access_Keys|Setting the Access Keys during Amazon EC2 CLI Installation]].
For details on how access keys can be set in the local environment, see [[#Setting_AWS_Credentials|Setting AWS Credentials]] below.


=AWS Credentials=
=AWS Credentials=
==User ID==
The "User ID" associated with the entity that is making the call is returned by:


AWS credentials can be set as explained here: {{Internal|Setting AWS Credentials| Setting AWS Credentials}}
[[AWS_Security_Operations#IAM_Information|aws sts get-caller-identity]]


==Access Key ID==
==Access Key ID==


==Secret Key ID==
==Secret Access Key==
===Secret Key ID===


==Session Token==
==Session Token==
Line 218: Line 486:
==Credentials Profile==
==Credentials Profile==


<font color=darkgray>TODO: https://docs.aws.amazon.com/sdk-for-java/v2/developer-guide/credentials.html</font>
==Credential Providers==
{{External|https://docs.aws.amazon.com/sdk-for-java/v2/developer-guide/credentials.html}}
When an AWS client (CLI, SDK) needs credentials, they use a provider chain to look for credentials in a number of different places, in this order (first matching is used): command-line options, environment variables, AWS credentials file, CLI configuration files and [[#Instance_Profile|instance profiles]].
 
<font color=darkgray>TODO</font>
===Credential Provider Operations===
* [[Setting AWS Credentials|Setting AWS Credentials]]
 
==Setting AWS Credentials==
{{Internal|Setting AWS Credentials| Setting AWS Credentials}}
 
==AWS CLI Configuration Files==
{{Internal|AWS_CLI#Configuration_Files|AWS CLI Configuration Files}}


=MFA Multi Factor Authentication=
=MFA Multi Factor Authentication=
Line 232: Line 512:
=Security Group=
=Security Group=
{{Internal|Amazon_VPC_Concepts#Security_Group|Security Group}}
{{Internal|Amazon_VPC_Concepts#Security_Group|Security Group}}
=Trust Policy=
=Temporary Security Credentials=
<font color=darkgray>To re-map in content.</font>
{{External|[https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp.html Temporary Security Credentials]}}


An [[#IAM_Role|IAM role]] has a trust policy. <font color=darkgray>The trust policy specifies what permissions can the role assume.</font>
AWS provides a mechanism through which temporary credentials are provided to authenticated users with proper permissions. This allows the users to make [[Amazon_AWS_Concepts#API|API calls]] against [[#AWS_Account|AWS accounts]] they do not really have an IAM user for - hence no proper [[Amazon_AWS_Security_Concepts#API_Access_Keys|AWS access key]], provided that the account allows [[AWS_Cross-Account_Delegation_Access|cross-account delegation access]].


=Temporary Security Credentials=
Temporary security credentials is how [[#Assuming_a_Role|IAM roles]] work: assuming a role means issuing temporary security credentials unique to that role, that allow the entity assuming the role to perform the actions and access the resources allowed by the role. This is achieved by making an API call to [[AWS Security Token Service|AWS Security Token Service]]  STS:AssumeRole. The service returns a temporary access key ID, a secret key and a security token that can then be used to sign future API calls. Also see [[AWS_Cross-Account_Delegation_Access|cross-account delegation access]].
{{External|[https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp.html Temporary Security Credentials]}}
 
==Temporary Security Credentials for EC2 Instances==
{{Internal|Amazon_EC2_Concepts#Temporary_Security_Credentials_for_EC2_Instances|Temporary Security Credentials for EC2 Instances}}
 
=AWS Security Token Service (STS)=
{{Internal|AWS Security Token Service|AWS Security Token Service}}
=Instance Metadata Service Version 2 (IMDSv2)=
{{Internal|AWS Instance Metadata Service Version 2|Instance Metadata Service Version 2 (IMDSv2)}}

Latest revision as of 00:18, 14 May 2022

External

Internal

Overview

Read this first:

Understanding and Getting Your Security Credentials

AWS Account

https://docs.aws.amazon.com/IAM/latest/UserGuide/console_account-alias.html

The AWS Account is identified by a 12 digit account ID or an alias. There's no mention of "account name" in AWS documentation. Each AWS account has associated a special sign-in identity that has complete access to all AWS services and resources in the account, called AWS account root user. Each AWS account has its own billing and subscriptions to AWS products. Each AWS account has its own IAM users, groups and roles. To create an AWS account, go to http://aws.amazon.com, and then click Sign Up. For more details see http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/get-set-up-for-amazon-ec2.html. It is a common practice to keep different environments separated from each other by using different AWS accounts, one per environment. This approach helps with resource isolation.

Account ID

https://docs.aws.amazon.com/general/latest/gr/acct-identifiers.html

The AWS Account ID is a 12-digit number, which uniquely identifies an AWS account.

The AWS account ID is reported on command line by:

aws sts get-caller-identity

The sign-in page URL has the following format by default:

https://<Account_ID>.signin.aws.amazon.com/console/

Account Alias

A reason to introduce an account alias is to give a friendly name to the sign-in page. If an alias is created, then the sign-in page can also be accessed at:

https://<Account_Alias>.signin.aws.amazon.com/console/

The AWS account can have only one alias. If a new alias is created, the new alias overwrites the previous alias, and the URL containing the old alias stop working. The account alias must be unique across all AWS products. It must contain only digits, lowercase letters and hyphens.

The account alias can be obtained with list-account-aliases IAM CLI operation.

AWS Account Root User

The AWS Account Root User

The AWS account root user is the special, unique sign-in identity that has complete access to all AWS services and resources in the AWS account.

AWS services require that you provide credentials when you access them. The console requires your password. You can create access keys for your AWS account to access the command line interface or API. However, it is not recommended to access AWS using the credentials for your AWS account root user. Use an IAM user, which is an authenticated identity associated with a person, system, or application who can use AWS products, each with individual security credentials, all controlled by and billed to a single AWS account. The IAM user is provisioned with IAM.

Cross-Account Delegation Access

Cross-Account Delegation Access

IAM (AWS Identity and Access Management)

IAM Concepts

AWS Identity and Access Management is a web service that enables AWS customers to manage users and user permissions in AWS. The service is targeted at organizations with multiple users or systems that use AWS products such as Amazon EC2, Amazon RDS, and the AWS Management Console. With IAM, the AWS account root user can can centrally manage users, security credentials such as access keys, and permissions that control which AWS resources users can access, and delegate these privileges to other IAM users. In fact, it is recommended practice that AWS account root user creates a corresponding IAM user, which is then used for administrative activities, thus making unnecessary logging in as AWS account root user.

Without IAM, organizations with multiple users and systems must either create multiple AWS accounts, or employees must all share the security credentials of a single AWS account. Also, without IAM, you have no control over the tasks a particular user or system can do and what AWS resources they might use. IAM addresses this issue by enabling organizations to create multiple IAM users.

IAM allows granting different permissions to different people for different resources.

IAM allows generation of credentials for applications that run on EC2 instances. These credentials provide permissions for your application to access other AWS resources, such as S3 buckets or DynamoDB tables.

IAM allows multi-factor authentication (MFA) for the AWS account root user and other individual accounts.

IAM, like many other AWS services, is eventually consistent. IAM achieves high availability by replicating data across multiple servers within Amazon's data centers around the world. If a request to change some data is successful, the change is committed and safely stored. However, the change must be replicated across IAM, which can take some time. Such changes include creating or updating users, groups, roles, or policies.

IAM Identifiers

Friendly Name

Also see path, below.

IAM ARN

IAM Unique ID

https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_identifiers.html#identifiers-unique-ids

When IAM creates a user, user group, role, policy, instance profile or server certificate, it assigns to each resource a unique ID, with standard prefixes:

Prefix Resource Type
ABIA AWS STS service bearer token
ACCA Context-specific credential
AGPA IAM Group
AIDA IAM User
AIPA Amazon EC2 instance profile
AKIA Access key
ANPA Managed policy
ANVA Version in a managed policy
APKA Public key
AROA IAM Role
ASCA Certificate
ASIA Temporary (AWS STS) access key IDs

IAM Identities

An IAM identity is a IAM user, a group of users or a role. IAM identities get permission policies attached to them, and the permissions specified in these policy define what kind of access the identity has for a specific AWS resource.

The IAM identity of a user making an AWS CLI call is reported on command line by:

aws sts get-caller-identity
{
    "UserId": "AIXXXXXXXXXXXXXXXXXXX",
    "Account": "999999999999",
    "Arn": "arn:aws:iam::999999999999:user/test-user"
}

IAM User

IAM User

An IAM user is an entity with an authenticated identity associated with a person, system, or application who can use AWS products, each with individual security credentials, all controlled by and billed to a single AWS account. With IAM, each user is allowed to do only what they need to do as part of the user's job.

AWS account root user (ovidiu@acme.com)
 └─ IAM Users
     └─ ofeodorov

When a new user is created, its IAM unique ID is prefixed by "AIDA".

IAM User Operations

IAM Group

IAM Group

An IAM Group is a collection of IAM users, whose main purpose is to define permissions for multiple users. When a new group is created, its IAM unique ID is prefixed by "AGPA".

IAM Group Operations

IAM Role

IAM Roles

An IAM role is an IAM identity that associates specific permission policies, which ultimately translate to specific permissions, for a set duration of time, to another entity. When a new role is created, its IAM unique ID is prefixed by "AROA".

An IAM Role can be conceptually thought of as a set of temporary credentials. It is also important to understand that there can be just one role in effect at a time - a single set of security credentials. There is not such a thing as multiple roles at the same time.

The entities an IAM role can be associated with are IAM users, application code running on an EC2 instance that needs to perform actions on AWS resource, an AWS service that needs to act on a resource on a user's account to provide its features, users from a corporate directory who use identity federation with SAML, etc.

A role works by issuing keys that are valid for short durations, making them a more secure way to grant access. The role does not have standard long-term credentials such as a password or long-lived access keys associated with it. The role provides the entity assuming it temporary security credentials for the role session.

A role contains:

  • one (or more) permission policies, which tell what individual permissions the role has, what resources can be accessed and what actions can be performed on these resources.
  • the "trust relationship", which consists of one and only one trust policy that says what trusted entities can assume this role.

From this perspective, an IAM role is similar to an IAM user, in that it is an IAM identity with permission policies that determine what the identity can and cannot do in AWS and also what trusted entities can assume this identity. However, instead of being uniquely associated with one person, a role is intended to be assumable by anyone who needs it.

Roles can be used to delegate permissions to an AWS service to carry out actions in behalf of the logged in user, to enable application code running in EC2 to access and modify resources, to grant access to users from another AWS account or to enable federated sign-in.

AWSIAMRole.png

Assuming a Role

How do I assume an IAM role using the AWS CLI?
Switching to an IAM Role (AWS CLI)

An entity can assume a role. "Assuming a role" means that the credentials the entity interacts with AWS resources change. When the role is assumed, the role issues temporary security credentials that can be used to access resources or call AWS services. This is a security best practice, which consists in using short term credentials.

The role carries a policy that grants the entity the permission to assume the role.

More practical details on how a role can be assumes are available in the Operations page:

Assuming an IAM Role

Role Attributes

Roles can be created programmatically as part of CloudFormation stacks, by using the resource type AWS::IAM::Role. A role has the following attributes, which can be declared as "Properties":

RoleName

Represents the physical ID of the role. If not specified in the CloudFormation template, a name will be generated: if the role is declared by a "thalarion" stack, then, after successful creation, the role's physical ID will be "thalarion-CodeBuildServiceRole-A479B6WNRHSSG". It is a String between 1 and 6 character, that must match the following pattern: [\w+=,.@-]+

Path

The path to the role, which will become part of the friendly name.

AssumeRolePolicyDocument

Declares the trust policy that grants an entity permission to assume this role. The policy specifies which entities (for example service) are allowed to assume the role.

Policies

The list of permission policies implied by the role.

Trust Policy

An IAM role, and in general an IAM identity, has one, and only one trust policy. The trust policy specifies what entities can assume the identity - a trust relationship defines who can assume a role. This can be visually inspected in the AWS IAM Console, selecting a role shows its Trusted entities in a dedicated column.

When a role is created with AWS Console, the trust policy is created automatically and it can be customized afterwards.

In the trust policy example below, the entity that can assume (sts:AssumeRole) the role with this trust policy is the "ec2.amazonaws.com" service, but the trust policy can contain more than one principals (AWS account, IAM user, IAM role, federated user or assumed-role user). More details about the content of the "Principal" section are available in the Trusted Entity section, below.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "sts:AssumeRole",
      "Principal": { 
          "Service": "ec2.amazonaws.com",
          "AWS": [
             "arn:aws:iam::123456789012:root",
             "arn:aws:iam::999999999999:user/some.user"
          ]
       },
      "Condition": { "Bool": { "aws:MultiFactorAuthPresent": "true" } }
    }
  ]
}

Trusted Entity

AWS JSON Policy Elements: Principal

The trusted entity is defined in the "Principal" section Trusted entities can be:

  • an AWS account, declared as "arn:aws:iam:999999999999:root" in the Principal section of the trust policy.
  • an IAM User, declared as "arn:aws:iam::999999999999:user/example-username" in the Principal section of the trust policy.
  • an identity provider

If the entity that eventually needs to assume the role is different from the entities listed in the "Principal" section, there must be at least one principal there that allows the end recipient to assume the role. For more details, see Creating a Role to Delegate Permissions to an IAM User.

If the Principal element contains the ARN for a specific IAM role or user, then that ARN is transformed to a unique principal ID when the policy is saved. This helps mitigate the risk of someone escalating their permissions by removing and recreating the role or user. The unique principal ID is not normally seen in the console because there is also a reverse transformation back to the ARN when the trust policy is displayed. However, if the the role or user is deleted, then the principal ID appears in the console because AWS can no longer map it back to an ARN. Therefore, if you delete and recreate a user or role referenced in a trust policy's Principal element, you must edit the role to replace the ARN.

Trust Policy Operations

AWS Service Role

An AWS Service Role is a role that a service assumes to perform actions in a user's account, on the user's behalf. The service role must include all permissions required for the service to access the AWS resources it needs. Service roles provide access only within user's account and cannot be used to grant access to services in other accounts. A service role works if the user who attempts to use it has the permissions to pass it (iam:PassRole).

AWS Service Role for an EC2 Instance

Using an IAM Role to Grant Permissions to Applications Running on Amazon EC2 Instances
IAM Roles for Amazon EC2

An application running on an EC2 instance needs AWS credentials to interact with any AWS services via API calls. A crude way to address this problem is to give the application access to AWS credentials (passwords or keys), by storing those credentials directly within the EC2 instance. This poses problems: credential management, secure transmission of those credentials - it's best not to be done that way.

The recommended alternative is to give the EC2 instance a special service role, via a mechanism named instance profile. The service role can then be assumed by the application running on the EC2 instance, allowing it to perform actions. The role is assigned to the EC2 instance when it is launched. Applications running on that instance can retrieve role-supplied temporary security credentials and perform actions that the role allows. The temporary credentials are rotated automatically, so the developers do not have to manage credentials and do not have to worry about long-term security risks.

The sequence of operations required to set up and use an EC2 service role is:

Instance Profile
Using Instance Profiles

An instance profile is a container for one and only one EC2 service role, and it is used to pass information about this role to the EC2 instance when it starts. An instance profile can contain only one IAM role, though a role can be included in multiple instance profiles. The existing role can be removed from the instance profile, and a different role can be added to it. This kind of change propagates across all AWS through eventual consistency:

{
  "Path": "/",
  "InstanceProfileName": "my-instance-profile",
  "InstanceProfileId": "BIPAIOJX2D4X5IJ3RBOZ8",
  "Arn": "arn:aws:iam::000000000000:instance-profile/my-instance-profile",
  "CreateDate": "2018-06-29T12:54:14Z",
  "Roles": [
    {
      "Path": "/",
      "RoleName": "my-ec2-role",
      "RoleId": "BROAIARHQAIPLH2K2UOO8",
      "Arn": "arn:aws:iam::000000000000:role/service-role/my-ec2-role",
      "CreateDate": "2018-06-29T12:54:14Z",
      "AssumeRolePolicyDocument": {
        "Version": "2012-10-17",
        "Statement": [
        {
           "Effect": "Allow",
           "Principal": {
              "Service": "ec2.amazonaws.com"
            },
          "Action": "sts:AssumeRole"
        }
        ]
       }
     }
   ]
}

The instance profile mechanism is needed because an application running on an EC2 instance is abstracted from AWS by the virtualized operating system. Because of this extra separation, an additional step is needed to assign an AWS role and its associated permissions, and this step is the creation of the instance profile.

IAM console provides transparent management of the instance profile. However, if CLI or API are involved, the instance profile must be first created, then associated with the EC2 instance in two separate steps.

The instance profile is one of the credential providers in the credential provider chain.

An instance profile can be granted cross-account delegation access via an IAM policy.

Instance Profile Operations

Granting a User Permissions to Pass a Role to an AWS Service

Granting a User Permissions to Pass a Role to an AWS Service

To pass a role and implicitly its permissions to an AWS service, a user must have permissions to pass the role to the service. This helps administrators ensure that only approved users can configure a service with a role that grants permissions. To allow a user to pass a role to an AWS service, the user must be granted the iam:PassRole permission, either directly, or to one of its roles or groups.

AWS Service-Linked Role

Role Session

The role session has a maximum duration, which can be configured in the AWS console from the role UI.

IAM Role Operations

Permission Policy

Policies and Permissions

An IAM identity has a set of permission policies, which specifies what permissions the identity has. In other words, the permission policy specifies what resources can be accessed and what actions can be performed on these resources.

Permission policies can get associated with IAM identities (IAM Roles, IAM Users, IAM Groups) or with AWS resources.

The policies control what actions an entity can perform, on which resources, and under what conditions. Most policies are stored in AWS as JSON documents. AWS supports six types of policies:

  1. identity-based policies
  2. resource-based policies
  3. permissions boundaries
  4. organizations service control policies (SCPs)
  5. access control policies (ACLs)
  6. session policies

Types of Permission Policies

Identity-Based Policies

Identity-based policies are JSON permissions policy documents that can be attached to an identity (user, group, role) and grant permissions to that identity, hence the name. Identity-based policies can be:

  1. managed policies
  2. inline policies

Managed Policies

A managed policy is a standalone identity-based policy that can be attached to multiple users, groups, and roles in an AWS account. There are two types of managed policies:

AWS Managed Policies

Managed policies that are created and managed by AWS. They can be quickly visually identified by their icon:

AWSManagedPolicy.png

The ARN of a policy that is managed by AWS is:

 arn:aws:iam::aws:policy/PolicyName

AWSManagedPolicies.png

Customer Managed Policies

Customer managed policies are managed policies create and manage by users in an AWS account. Customer managed policies provide more precise control over policies than AWS managed policies. IAM policy can be created and edited in a visual editor or by creating the JSON policy document directly. Once created, policies are referenced by their ARNs. The ARN of a customer-managed policy is:

 arn:aws:iam::AWS-account-number:policy/PolicyName
Customer Managed Policy Example

A permission policy is a collection of permissions:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": ["ec2:*"],
      "Resource": ["*"]
    },
    {
      "Effect": "Allow",
      "Action": ["elasticloadbalancing:*"],
      "Resource": ["*"]
    },
    {
      "Effect": "Allow",
      "Action": "s3:*",
      "Resource": [
        "arn:aws:s3:::kubernetes-*"
      ]
    }
    ...
  ]
}
Customer Managed Policies Operations

Inline Policies

Policies created by users and that are embedded directly into a single user, group, or role. In most cases, inline policies usage is not recommended:

Managed Policies and Inline Policies

Resource-Based Policies

Difference between Identity-Based Policies and Resource-Based Policies

Identity-Based Policies and Resource-Based Policies

IAM Permissions Boundaries

Service Control Policies (SCPs)

Access Control Policies (ACLs)

Session Policies

Permission

A permission is a piece of information that specifies what kind of access the bearer of the permission has a specific AWS resource. A permission is associated with an IAM identity, a role for example, via permission policies. AWS evaluates the permission present in the policy when a principal entity (user or role) makes a request. Permissions in the policies determine whether the request is allowed or denied. Permissions for an action are valid regardless of the method that is used to perform the operation on a resource. For example, if a policy allows the GetUser action, then a user with that policy can get user information from the AWS Management Console, the AWS CLI, or the AWS API.

The JSON rendering of an individual permission is similar to:

{
  "Effect": "Allow",
  "Action": [
    "ec2:AttachVolume",
    "ec2:CreateSnapshot",
    ...
  ],
  "Resource": "*"
}

The permission consists of an "effect" ("Allow" or "Deny"), an action, such as "ec2:AttachVolume", and a list of resources permission applies to. Optionally, the permission may include a "condition".

Action

Note that the actions are sometimes referred to as "permissions", which implies that the action is part of a formal permission construct associated with the entity requiring it.

API Access Key

https://docs.aws.amazon.com/general/latest/gr/aws-sec-cred-types.html#access-keys-and-secret-access-keys
https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html

Each IAM user has a set of API access keys. These keys are needed when the user attempts to make programmatic calls to the AWS backend, using Amazon EC2 CLI tools or the AWS SDK for Java. The keys are used to sign the calls. The user can create, modify, view and rotate these access keys.

An access keys consists of two items:

  1. an Access Key ID (example AKIAIOSFODNN7EXAMPLE))
  2. a Secret Access Key (example: wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY)

When creating an access key, IAM returns the access key ID and the secret access key. The secret access key is only accessible at the time it was created. If the secret access key is lost, the corresponding access key must be deleted and recreated. What is the relationship between Access Key ID and Secret Key?

The access keys can be managed here: https://console.aws.amazon.com/iam/home?#security_credential by navigating to Users → username → My security credentials → AWS IAM credentials → Access keys for CLI, SDK, & API access.

For details on how access keys can be set in the local environment, see Setting AWS Credentials below.

AWS Credentials

User ID

The "User ID" associated with the entity that is making the call is returned by:

aws sts get-caller-identity

Access Key ID

Secret Access Key

Secret Key ID

Session Token

Credentials Profile

Credential Providers

https://docs.aws.amazon.com/sdk-for-java/v2/developer-guide/credentials.html

When an AWS client (CLI, SDK) needs credentials, they use a provider chain to look for credentials in a number of different places, in this order (first matching is used): command-line options, environment variables, AWS credentials file, CLI configuration files and instance profiles.

TODO

Credential Provider Operations

Setting AWS Credentials

Setting AWS Credentials

AWS CLI Configuration Files

AWS CLI Configuration Files

MFA Multi Factor Authentication

Instance Access Key Pairs

Amazon AWS uses public-key cryptography to secure the login to instances. The instance has no password - you use a key pair to access your instance securely. The key pairs are provisioned either via the web interface or with Amazon CLI tools. During the provisioning process, the keys pairs are named. When the instance is created, you need to specify the name of the key pair to use to protect access to it: Amazon will install the public certificate in ~/.ssh/authorized_keys when creating the instance, and then you need to provide the private key of the pair to your ssh client when logging into the instance.

External reference: http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-key-pairs.html

This is the procedure to create a key pair.

Security Group

Security Group

Temporary Security Credentials

Temporary Security Credentials

AWS provides a mechanism through which temporary credentials are provided to authenticated users with proper permissions. This allows the users to make API calls against AWS accounts they do not really have an IAM user for - hence no proper AWS access key, provided that the account allows cross-account delegation access.

Temporary security credentials is how IAM roles work: assuming a role means issuing temporary security credentials unique to that role, that allow the entity assuming the role to perform the actions and access the resources allowed by the role. This is achieved by making an API call to AWS Security Token Service STS:AssumeRole. The service returns a temporary access key ID, a secret key and a security token that can then be used to sign future API calls. Also see cross-account delegation access.

Temporary Security Credentials for EC2 Instances

Temporary Security Credentials for EC2 Instances

AWS Security Token Service (STS)

AWS Security Token Service

Instance Metadata Service Version 2 (IMDSv2)

Instance Metadata Service Version 2 (IMDSv2)