Software Engineering :: Cloud :: AWS :: AWS IAM
⪼ Made with 💜 by Polyglot.
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.
best practice is to use the root user only to create your first IAM user. Then securely lock away the root user credentials and use them to perform only a few account and service management tasks.
Certain services, such as S3 and SQS, can have policies directly attached to the service components (e.g. an S3 bucket). For example, a bucket can have a policy attached to it that allows any user to retrieve items from the bucket. Other services can have policies attached to them in the form of roles. This can take the form of either a service-linked roles, where the service is granted access to the role, or having a role attached to a component in the service (e.g. an EC2 instance). These roles provide the service the ability to perform AWS actions similar to a standard user, such as a Lambda function being able to start and stop EC2 instances.
The most fundamental component of IAM is the policy, a JSON document that determines which action can be performed by which entities and under what conditions. These policies can be directly attached to users and roles, allowing them to perform the actions contained within. They can also be attached to groups, providing those permissions to all users within the group.
Temporary Security Credentials (consisting of access key id, secret access key and a security token) enables you to have an access to AWS Environment for a specified duration. It solves use cases like cross account access and single sign-on to AWS.
If you are using the IAM API or AWS Command Line Interface (AWS CLI) to create IAM entities, you can also give the entity an optional path. You can use a single path, or nest multiple paths as if they were a folder structure. For example, you could use the nested path /division_abc/subdivision_xyz/product_1234/engineering/ to match your company's organizational structure. You could then create a policy to allow all users in that path to access the policy simulator API. To view this policy, see IAM: Access the Policy Simulator API Based on User Path. For additional examples of how you might use paths, see IAM ARNs. When you use AWS CloudFormation to create resources, you can specify a path for users, groups, and roles, but not policies.
Most resources have a friendly name (for example, a user named Bob or a group named Developers). However, the permissions policy language requires you to specify the resource or resources using the following Amazon Resource Name (ARN) format.
arn:partition:service:region:account:resource
-
partition identifies the partition that the resource is in. For standard AWS Regions, the partition is aws. If you have resources in other partitions, the partition is aws-partitionname. For example, the partition for resources in the China (Beijing) Region is aws-cn. You cannot delegate access between accounts in different partitions.
-
service identifies the AWS product. For IAM resources, this is always iam.
-
region is the Region the resource resides in. For IAM resources, this is always kept blank.
-
account is the AWS account ID with no hyphens (for example, 123456789012).
-
resource is the portion that identifies the specific resource by name.
An instance profile is a container for an IAM role that you can use to pass role information to an EC2 instance when the instance starts. If you manage your roles from the AWS CLI or the AWS API, you create roles and instance profiles as separate actions. Because roles and instance profiles can have different names, you must know the names of your instance profiles as well as the names of roles they contain. That way you can choose the correct instance profile when you launch an EC2 instance. An instance profile can contain only one IAM role, although a role can be included in multiple instance profiles. This limit of one role per instance profile cannot be increased. You can remove the existing role and then add a different role to an instance profile. You must then wait for the change to appear across all of AWS because of eventual consistency. To force the change, you must disassociate the instance profile and then associate the instance profile, or you can stop your instance and then restart it.