Theory
Users must be authenticated before they can access AWS services and Resources. AWS services can be accessed via
- AWS CLI
- AWS SDKs
- AWS Management Console
You can create:
- Individual IAM users: each user can have its own credentials.
- IAM group: It’s better to manage permissions using IAM groups. So, each member has the same permission policy.
By default, your users can’t access anything in your account. You need to granted permissions by creating a policy.
Steps:
- 1. Create an IAM group for each department.
- 2. Create a policy and assign them to a group.
- 3. Create a person for each user in each department.
IAM policies may also be assigned to an IAM Role.
A role does not have any long term defined credentials. With a role, access keys area created dynamically and provided to the user temporarily. IAM roles can be used to delegate access to users, applications or services that don’t normally have access to your AWS resources. A user who assumes a role temporarily gives up his or her own permissions and instead takes on the permissions of the role.
If you user a Federated Identity you can access to the AWS services without an AWS Account. You can access from LDAP, Windows Active Directory, Amazon, Facebook, or Google.
Example 1: Application
You have a custom application hosted on an Amazon EC2 Instance. This application needs to interact with objects stored in an S3 bucket.
The bad option
- You can embed your AWS credentials in your application code.
- If you do so you may compromise your credentials. Also, changing or rotating the credentials would require an update in the code each time.
The secure option
- Create an IAM role to pass temporary security credentials as part of an Instances profile. The application would use the identity assumed by the instance to access the Amazon S3 bucket.
Example 2: Permissions that aren’t usually assigned
You can also use IAM roles is to provide users, groups, or resources with permissions that they would usually have assigned to them.
You have an IAM user who has an IAM Restricted Policy to access to an Amazon S3 Bucket. But this user needs to perform some administrative tasks for what he needs administrative privileges. So
- You create a IAM Admin policy.
- Assign them to a IAM Admin Role when require the user can Assume the IAM Admin Role and gain administrative access to the designated resource.
- After the task is finished the original user permissions are restored.
Conclusion
Leveraging IAM roles removes the need to modify a user’s policy to modify users’ policy each time a change is required.
IAM also enables you to use Identity Federation and allow existing entities in your enterprise to access AWS without the need to create an IAM account for each Identity. An interesting example to use a federated identity is a service where you must sign with the AWS keys. For example GitHub Actions that uses workflows to access Amazon S3 and DynamoDB in that case you don’t add the password to the action. Instead configure your applications to requests temporary AWS security credentials dynamically when needed using OIDC federation. And them you avoided the credential proliferation
Sources: