Amazon AWS Security Concepts
External
- Understanding and Getting Your Security Credentials https://docs.aws.amazon.com/general/latest/gr/aws-sec-cred-types.html
- Setting Up with Amazon EC2 http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/get-set-up-for-amazon-ec2.html
Internal
Overview
Read this first:
AWS Account
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. 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.
Cross-Account Delegation Access
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.
IAM (AWS Identity and Access Management)
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 Identities
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@novaordis.com) | +---- IAM Users | +-- ofeodorov
IAM User Operations
IAM Group
An IAM Group is a collection of IAM users, whose main purpose is to define permissions for multiple users.
IAM Group Operations
IAM Role
An IAM role is an IAM identity that has specific permissions. The permissions are associated with the role via 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 also includes a trust policy.
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 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 policies implied by the role.
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).
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 PassRole permission, either directly, or to one of its roles or groups.
AWS Service Role for an EC2 Instance
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:
- Define the service role, via the console or programmatically.
- Create the instance profile.
- Add the created role to the instance profile.
- Associate the instance profile with the EC2 instance.
- Create the EC2 instance.
- Use temporary credentials made available via instance metadata.
Instance Profile
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.
An instance profile can be granted cross-account delegation access via an IAM policy.
Instance Profile Operations
- View Existing Instance Profiles
- Create an Instance Profile
- Add a Role to an Instance Profile
- Associate an Instance Profile with an EC2 Instance
AWS Service-Linked Role
Trust Relationship
IAM Role Operations
IAM Identifiers
Friendly Name
Also see path, below.
IAM ARN
IAM Unique ID
IAM Permission Policy
An IAM role has a permission policy, which specifies what permissions the role has.
Identity-Based Policies
Identity-based policies are JSON permissions policy documents that can be attached to an identity (user, group, 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 and 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. The ARN of a policy that is managed by AWS is:
arn:aws:iam::aws:policy/PolicyName
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
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:
Resource-Based Policies
Difference between Identity-Based Policies and Resource-Based Policies
IAM Permissions Boundaries
Service Control Policies (SCPs)
Access Control Policies (ACLs)
Session Policies
API Access Key
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 for example. 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:
- an Access Key ID (example AKIAIOSFODNN7EXAMPLE))
- 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 -> Security Credentials -> Access Credentials.
More about access keys for IAM users: http://docs.aws.amazon.com/IAM/latest/UserGuide/ManagingCredentials.html
For details on how access keys can be set in the local environment, see Setting the Access Keys during Amazon EC2 CLI Installation.
AWS Credentials
AWS credentials can be set as explained here:
Access Key ID
Secret Key ID
Session Token
Credentials Profile
Credential Providers
TODO
Credential Provider Operations
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
Trust Policy
To re-map in content.
An IAM role has a trust policy. The trust policy specifies what permissions can the role assume.
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 allow a user to assume an arbitrary IAM 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.