Role based access gives an entity the right to perform an action based on the role its assigned to. This entity can be a person or a machine. Roles are used for categorizing, authorizing, and authenticating.
Role based access gives us two main advantages:
- There is no need for access keys.
- Role based access can be given temporarily.
The permissions given to a role need not be associated with any User or Group.
This post will focus on role based access in AWS.
Example use case
Suppose you have an application that needs to access Amazon S3 bucket for config. For security reasons, you would not want to store the access key in the application itself. You can create a role that allows this service to access the S3 bucket. At run time, the service assumes the role and AWS returns temporary security credentials to the user.
IAM policy types in AWS
While creating a role, you need to specify two policies:
- Permissions policy. Define what actions and resources the role can use.
- Trust policy. Define who is allowed to assume a role.
You need to define both of these policies.
An example of a role based policy type in AWS is shown below. As you can see, the permissions_policy.json allows all permissions to the s3 bucket. The trust_policy.json allows the ec2 machine to assume the role. So, when you attach this role to an Amazon ec2 instance, that instance will be able to perform operations on the specified s3 bucket.
Security Token Service (STS)
The IAM roles rely on the Security Token Service. The AWS STS acts as the middlemen that validates the user and serves tokens – it provides temporary security credentials. These are short-term credentials that can last anywhere between 15 minutes to 36 hours and are dynamically assigned as requested. Since these credentials are only assigned when requested and are short-term, there is no need to rotate or revoke the password or access keys.
Types of roles
Service role
AWS service assumes this role to perform actions on your behalf. Service roles only work within an AWS account. A type of service role can be for an EC2 instance, where the role is attached to EC2 instance and made available to its applications. Another type of service role is service-linked role, where a role provides all the permissions required by a service.
In the above diagram, we have a webapp that is running in an EC2 instance. Let us say that the webapp needs to access the Amazon S3 bucket; the EC2 instance will then connect to an AWS STS to get temporary security credentials for a role that has permissions to access the S3 bucket. These credentials will be stored into something known as the instance profile on the EC2 instance. The webapp can then connect to this local store to get the credentials at runtime and access the S3 instance.
In the diagram above, you see a scenario where AWS cloud formation gets temporary credentials that allows it to deploy the S3 bucket, the EC2 instance, and the RDS instance.
Delegated role
Permissions are granted to others to access the resources you control. A trust relationship is set up between your account as a trusting account and other trusted accounts. Trusted accounts can either be the same account or other accounts within or outside of your organization.
The above diagram shows an example of delegated roles with two accounts. Account1 has the resources that the user in Account2 wishes to access. A role would be created that allows access to these resources. The user in Account1 does an assume role, and if the user is validated, it gets temporary credentials to access the resources.
Federated role
This allows for single sign-on. Federated role can use a variety of authentication engines like SAML 2.0, OpenID Connect, etc.
The above diagram shows an example of a federated role. The resources are in the AWS. For the sake of this diagram, the web providers or the SAML providers are outside AWS. The user validates with these providers and then calls STS with AssumeRolewithWebIdentity. It then gets temporary credentials to access the Amazon resources.
Best practices
- Always use IAM Roles for applications instead of creating IAM users. These make your applications more secure.
- Use roles for corporate identities instead of creating multiple identities. This allows the user to use their existing credentials for Amazon access.
- Use roles for web identities that require temporary access. This allows you to let the end-users use their existing web accounts to access your resources.
References
https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html
Also published on Educative
Anjana Shankar 
You must be logged in to post a comment.