IAM Flashcards
Why do IAM Roles exist?
Applications must sign their API requests with AWS credentials.
You need a strategy for managing credentials for your applications that run on EC2 instances.
You can distribute credentials to instances and use them, but there is management overhead and its not as secure. Especially when instances are managed by SPOT etc..
Rotating creds is also a challenge.
IAM Roles exist to make secure API requests from an instance without requiring cred management. Instead of creating and distributing creds, you can delegate permissions with roles.
It also makes permission management easier when services can temporarily assume roles without the policies having to be updated.
What are the two different types of users in AWS and how do they differ in terms of permissions?
Account owner (root user) or AWS Identity and Access Management (IAM) user.
- The root user is created when the AWS account is created.
- IAM users are created by the root user or an IAM administrator for the account. All AWS users have security credentials.
- You cannot use IAM policies to explicitly deny the root user access to resources. You can only use an AWS Organizations service control policy (SCP) to limit the permissions of the root user.
- There are specific tasks that are restricted to the AWS account root user. For example, only the root user can close your account. If you need to perform a task that requires the root user, sign in to the AWS Management Console using the email address and password of the root user.
- With IAM, you can securely control access to AWS services and resources for users in your AWS account. For example, if you require administrator-level permissions, you can create an IAM user, grant that user full access, and then use those credentials to interact with AWS. If you need to modify or revoke your permissions, you can delete or modify the policies that are associated with that IAM user.
- If you have multiple users that require access to your AWS account, you can create unique credentials for each user and define who has access to which resources. You don’t need to share credentials. For example, you can create IAM users with read-only access to resources in your AWS account and distribute those credentials to users.
What type of credentials are required for console access? What is special about the Root user and IAM user?
Email Address and Password.
Root user has the main email address and password.
IAM user
This user needs an account alias or 12-digit AWS account ID, the IAM user name, and the password for the IAM user.
What is IAM?
AWS Identity and Access Management (IAM) is a web service that helps you securely control access to AWS resources. You use IAM to control who is authenticated (signed in) and authorized (has permissions) to use resources.
What is the root user?
When you first create an AWS account, you begin with a single sign-in identity that has complete access to all AWS services and resources in the account. This identity is called the AWS account root user and is accessed by signing in with the email address and password that you used to create the account.
What are IAM Users?
IAM users can be created to correspond with users in your organisation or you can create user groups. Users need to be authenticated to use AWS resources and creating an IAM user is the way to do this.
IAM Groups manage permissions for a group of users.
What is an IAM Policy?
By default users can’t access anything in your accounts. You need to create permissions to AUTHORIZE users using policies.
A policy is a JSON document that explicitly states what permissions a user has.
What does an IAM Policy document contain?
An Policy document is a JSON document that contains:
- the affect
- Actions
- Resources
- Optional contitions
for the API calls that an entity can invoke.
Anything that is not explicitly allowed is denied by default.
The JSON Document contains a:
- SID - Who or what is being authorized, User, Group or Resource within AWS.
- Effect - self explanitory
- Action Valiue - What actions on the API can be performed.
- Condition - The condition to be succesfull. For example, only calls from the listed IP Addresses.
- Finaly the policy describes the resources to which the tasks can be performed.
Typically how would IAM users and groups work with policies?
- Create a user.
- Create a group of users.
- Create a policy.
- Assign the policy to the Group.
- Add users to the group etc.
What is an IAM Role, how does it interact with policies.
IAM Policies my be assigned to an IAM role.
IAM role is similar to a user in that it is an AWS Identity with permissions that say what the identity can do.
A role does not have long term creds, password or access keys or anything associated to it.
The user is assigned to a role and the access keys are temporarily assigned.
IAM roles can be used to give access to users, applications and services that dont normally have access to your resources.
User that assumes role temporarily gives up current permissions and assumes permission of the role.
What are credentials and the different types of long term credentials for an IAM user?
Credentials - This is just the overall term used for the information AWS needs to authenticate and authorize you.
Detail: When you interact with AWS, you specify your AWS security credentials to verify who you are and whether you have permission to access the resources that you are requesting. AWS uses the security credentials to authenticate and authorize your requests.
Long term IAM Creds:
- Passwords – Used to sign in to secure AWS pages, such as the AWS Management Console and the AWS Discussion Forums.
- Access keys – Used to make programmatic calls to AWS from the AWS APIs, AWS CLI, AWS SDKs, or AWS Tools for Windows PowerShell.
- Amazon CloudFront key pairs – Used for CloudFront to create signed URLs.
- SSH public keys – Used to authenticate to AWS CodeCommit repositories.
Explain a real world scenario for an IAM role.
There is a custom app in your EC2 Instance.
You could embed your AWS credentials in the code. But that could compromise credentails.
Changing or rotating credentials require update to code.
Alternative, more secure option is to use an IAM role to pass temporary credentials as part of an instance profile. The service would use the role assumed by the instance to do the action.
Scenario 2
Users also get assigned policies for temporary privilages they dont normally have.
you would create the policy and then the role. The user can then assume the role and temorary gain those permissions. Thus a user policy does not need to change all the time.
What are Credentials for Console Access?
- To sign in to your AWS account as the root user, you provide this email address and password
- IAM users are created by the root user or an IAM administrator within the AWS account. The user who created your IAM user should provide you with either the account alias or 12-digit AWS account ID, the IAM user name, and the password for the IAM user. An IAM user can sign in using either the console sign-in page or the following sign-in URL, replacing account_id_or_alias with either the account alias or AWS account ID provided to you:
https://account_id_or_alias.signin.aws.amazon.com/console/
What are credentials for programattic AWS access?
AWS access keys to make programmatic calls to AWS or to use the AWS Command Line Interface or AWS Tools for PowerShell.
Access Keys consist of an access key ID (for example, AKIAIOSFODNN7EXAMPLE) and secret access key (for example, wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY) as a set.
What are Temporary Security Credentials?
In addition to the access key ID and secret access key, temporary security credentials include a security token that you must send to AWS when you use temporary security credentials. The advantage of temporary security credentials is that they are short term. After they expire, they’re no longer valid.
You can use temporary access keys in less secure environments or distribute them to grant users temporary access to resources in your AWS account. For example, you can grant entities from other AWS accounts access to resources in your AWS account (cross-account access). You can also grant users who don’t have AWS security credentials access to resources in your AWS account (federation). For more information, see aws sts assume-role.
What is assume-role?
TBC
What are the typs of account identifiers?
AWS account ID
A 12-digit number, such as 123456789012, that uniquely identifies an AWS account. Many AWS resources include the account ID in their Amazon Resource Names (ARNs). The account ID portion distinguishes resources in one account from the resources in another account. If you are an IAM user, you can sign in to the AWS Management Console using either the account ID or account alias.
Canonical user ID
An alpha-numeric identifier, such as 79a59df900b949e55d96a1e698fbacedfd6e09d98eacf8f8d5218e7cd47ef2be, that is an obfuscated form of the AWS account ID. You can use this ID to identify an AWS account when granting cross-account access to buckets and objects using Amazon S3. You can retrieve the canonical user ID for your AWS account as either the root user or an IAM user.
What are the four main points for managing access keys for IAM users?
-
Don’t embed access keys directly into code. The AWS SDKs and the AWS Command Line Tools enable you to put access keys in known locations so that you do not have to keep them in code. Put access keys in one of the following locations:
- The AWS credentials file. The AWS SDKs and AWS CLI automatically use the credentials that you store in the AWS credentials file.
- Environment variables. On a multitenant system, choose user environment variables, not system environment variables.
- Rotate access keys periodically. Change access keys on a regular basis. For details
- Remove unused access keys. If a user leaves your organization, remove the corresponding IAM user so that the user can no longer access your resources. To find out when an access key was last used, use the GetAccessKeyLastUsed API (AWS CLI command: aws iam get-access-key-last-used).
- Configure multi-factor authentication for your most sensitive operations. For more information, see Using Multi-Factor Authentication (MFA) in AWS in the IAM User Guide.
What are the options for working with credentials and the SDK?
Use the default credential provider chain (recommended).
Use a specific credential provider or provider chain (or create your own).
Supply the credentials yourself. These can be root account credentials, IAM credentials, or temporary credentials retrieved from AWS STS.
When using the Default Credential Provider Chain with the SDK, what happens if you dont set any arguments?
When you initialize a new service client without supplying any arguments, the AWS SDK for Java attempts to find AWS credentials by using the default credential provider chain implemented by the DefaultAWSCredentialsProviderChain class. The default credential provider chain looks for credentials in this order:
Environment variables-AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY. The AWS SDK for Java uses the EnvironmentVariableCredentialsProvider class to load these credentials.
Java system properties-aws.accessKeyId and aws.secretKey. The AWS SDK for Java uses the SystemPropertiesCredentialsProvider to load these credentials.
Web Identity Token credentials from the environment or container.
The default credential profiles file- typically located at ~/.aws/credentials (location can vary per platform), and shared by many of the AWS SDKs and by the AWS CLI. The AWS SDK for Java uses the ProfileCredentialsProvider to load these credentials.
You can create a credentials file by using the aws configure command provided by the AWS CLI, or you can create it by editing the file with a text editor. For information about the credentials file format, see AWS Credentials File Format.
Amazon ECS container credentials- loaded from the Amazon ECS if the environment variable AWS_CONTAINER_CREDENTIALS_RELATIVE_URI is set. The AWS SDK for Java uses the ContainerCredentialsProvider to load these credentials. You can specify the IP address for this value.
Instance profile credentials- used on EC2 instances, and delivered through the Amazon EC2 metadata service. The AWS SDK for Java uses the InstanceProfileCredentialsProvider to load these credentials. You can specify the IP address for this value.
How do you code the provider chain for credentials in the SDK?
AmazonS3 s3Client = AmazonS3ClientBuilder.standard() .withRegion(Regions.US_WEST_2) .build();
If you want to specify something other than the default?
AmazonS3 s3Client = AmazonS3ClientBuilder.standard() .withCredentials(new EnvironmentVariableCredentialsProvider()) .build();
How would you explicitly specify credentials in the SDK?
Instantiate a class that provides the AWSCredentials interface, such as BasicAWSCredentials, and supply it with the AWS access key and secret key you will use for the connection.
Create an AWSStaticCredentialsProvider with the AWSCredentials object.
Configure the client builder with the AWSStaticCredentialsProvider and build the client.
When using temporary credentials obtained from STS, create a BasicSessionCredentials object, passing it the STS-supplied credentials and session token.
BasicSessionCredentials sessionCredentials = new BasicSessionCredentials( session_creds.getAccessKeyId(), session_creds.getSecretAccessKey(), session_creds.getSessionToken()); AmazonS3 s3 = AmazonS3ClientBuilder.standard() .withCredentials(new AWSStaticCredentialsProvider(sessionCredentials)) .build();
What are temporary credentials in IAM?
You can use the AWS Security Token Service (AWS STS) to create and provide trusted users with temporary security credentials that can control access to your AWS resources. Temporary security credentials work almost identically to the long-term access key credentials that your IAM users can use, with the following differences:
Temporary security credentials are short-term, as the name implies. They can be configured to last for anywhere from a few minutes to several hours. After the credentials expire, AWS no longer recognizes them or allows any kind of access from API requests made with them.
Temporary security credentials are not stored with the user but are generated dynamically and provided to the user when requested. When (or even before) the temporary security credentials expire, the user can request new credentials, as long as the user requesting them still has permissions to do so.
These differences lead to the following advantages for using temporary credentials:
You do not have to distribute or embed long-term AWS security credentials with an application.
You can provide access to your AWS resources to users without having to define an AWS identity for them. Temporary credentials are the basis for roles and identity federation.
The temporary security credentials have a limited lifetime, so you do not have to rotate them or explicitly revoke them when they’re no longer needed. After temporary security credentials expire, they cannot be reused. You can specify how long the credentials are valid, up to a maximum limit.
What are named profiles?
A named profile is a collection of settings and credentials that you can apply to a AWS CLI command. When you specify a profile to run a command, the settings and credentials are used to run that command. Multiple named profiles can be stored in the config and credentials files.
You can configure additional profiles by using aws configure with the –profile option, or by manually adding entries to the config and credentials files. For more information on the config and credentials files, see Configuration and credential file settings.
$ aws ec2 describe-instances –profile user1
