As developers and software engineers, we’ve all encountered the cloud in some form or another. AWS is a major player when it comes to cloud computing with 31% of the market share, followed by Microsoft Azure at 20%. If you haven’t personally played with AWS, then there’s a high chance that you might have encountered other developers talking about it in some form.
AWS stands for Amazon Web Services and runs a large suite of tools that range from automated serverless monitoring to simple instance machines that let you put whatever you want on them. While there are 117 distinct services available on AWS, there is one functionality that governs them all.
This functionality is called IAM roles.
What are IAM Roles
IAM stands for Identity and Access Management. It is the entry point for external and third-party apps to access the various services available on AWS.
An IAM role is more than just the ability to create new users and reset passwords, it is the central control panel that gives users, applications, and even AWS services access to other AWS services.
The way IAM roles work is that it delegates access with defined permissions without having to share access keys. This delegation allows for automated processes to boot up new instances, servers, and watchers if required and orchestrate entire infrastructure setups with minimal developer intervention.
While this may sound simple and great for automated processes like pipeline and environment developments, it also poses a sizable security risk.
Security and Application Considerations for IAM Roles
When engaging in the creation of IAM roles, here are the top 4 security considerations you need to make before granting access to the resources and services available on AWS.
1. You cannot set usage quotas on IAM users
When granting permissions and accessibility through an IAM role, it means that the developer has access to the entire quote on the AWS account.
For example, you cannot limit access to EC2 instances to only a particular region or maximum instance size. The only limitation is what AWS has on the account as a whole. This means that if a malicious user gets access to your IAM role keys, they can potentially rack up a massive bill on your behalf through instance orchestration and spinning up new EC2 machines in regions that you don’t normally operate in.
2. Cross-linkage of AWS accounts can create a cascade access effect
It is possible to delegate access through IAM roles between AWS accounts through ACLs. This can be handy for organizations that run separate AWS accounts for different production levels or different types of applications.
However, giving admin access can lead to a cascade access effect where a particular user has the ability to programmatically access services that they do not actually need. The lack of transparency between linked accounts can also create blind spots for administrators who may not have access to all the AWS accounts in order to detect this kind of permission-based access.
When it comes to IAM roles, there is often a lack of visibility on who has access to what. While an admin can go in and navigate each IAM role, this can be time-consuming and cannot be easily managed in the long run.
3. The type of access policy implemented can differ depending on the user type
Different policy types are suited to different IAM roles. There are six different kinds of policy types available for IAM roles, and they are as follows:
- Identity-based policies
Identity-based policies are granted to specific users or particular groups. These permissions are given to the user based on their identity and can limit access to certain services on the AWS console.
- Resource-based policies
Resource-based policies are often attached to a specific type of service on AWS and are similar to identity-based policies, but the root limitations are set at the actual resource rather than on the user.
- Permission boundaries
A permission boundary is more of a meta policy that lets you define the maximum amount of permissions allowed against a particular entity. However, it doesn’t actually grant access to anything. For example, a permission boundary might be set against an IAM role for a maximum number of services attached. This is good for managing resource scope creep for users.
- Organizations SCPs
An organization service control policy (SCP) is another meta policy tool that lets you define the maximum permissions for an organization. While permission boundaries limit the number of services an IAM role can access, organization SCPs limit the number of policies granted in general against the account, or organization.
- Access control lists (ACLs)
Access control lists or ACLs, are policies that let users of other AWS accounts access your account. It is a way to create cross-account permissions, giving access to services within this account to another account.
- Session policies
Session policies are time-based policies that give access to federated users whose identity has been verified and confirmed. Session policies do not actually grant any permission, but rather access to the permissions available against the IAM role. This can add an extra layer of security through validation rather than just being open session keys that can be easily duplicated and passed around.
4. Excessive permissions can lead to vulnerabilities
If you’ve ever tried to orchestrate resources on AWS, you will quickly find that one resource often requires another to function properly. If the user is unclear about their needs, it is easy to default to excessive permissions granted, or even the root user, in order to perform the tasks required.
This is a common practice that shouldn’t be and is one of the top emerging IAM security risks. Sometimes, what was meant to only be a temporary admin privilege never gets revoked, or a user is unaware of the implications of their access and how it can cost the company big money if not resource access is monitored.
Setting Up Custom Policies for IAM roles
In this section, we’re going to set up a custom policy that gives specific access to certain AWS services. You can then use these policies to ensure users only have access to the services they need rather than being entrusted with full admin access.
Setting up the custom policy in AWS
At the base of every is the policy. The policy is the central place where access and permissions can be managed. To do this, search up IAM in your AWS console search bar. Select IAM, located under services.
AWS service search screen.
Once you’ve done this, you will be directed to the admin screen. Select Policies and then click on the Create policy button.
Creating a new AWS security policy in the console.
Click on Create policy will take you through the policy setup wizard. From this screen, you can select the services you want your developers to have access to. To select the services you want, click on choose a service, which will toggle to a search filter list for you to select from. When you select a service, AWS will give you a list of dependencies based on permissions.
For example, if Lambda was selected, you can also define the access permission based on read, write, list, and permissions management. Each of these will also come with the ability to fine-tune accessibility based on blanket admin access or ARNs (Amazon Resource Names). ARNs give the resource a specific id that can be programmatically targetted and limit accessibility to only that particular related instance created. For example, if a developer is assigned to this policy, they can only access the authorized resources with the attached ARNs. If a blanket default is used, then the user has access to all the instances relating to the authorized resource.
Selecting the policy’s target resource.
In this example, we selected Lambda as our policy’s service and we are only giving the user read permissions. This means that whatever has access to this Lambda service can call it but cannot make any modifications to the instance.
Setting up your resource’s access permissions.
Once you’ve done that, you can now attach a specific resource to it based on the ARN. To do this, click on the resource toggle, which will give you a list of all the different functionalities that comes with the service’s selected access level. Click on Add ARN to attach the resource to this specific policy. This is the part where a lot of DevOps and admins tend to just click on All resources or Any in this account because it’s easy. However, doing so can lead to security vulnerabilities because it gives access to all instance resources under the selected service.
Adding ARNs to restrict access to specific resources only.
When you click on Add ARN, a popup will appear where you can configure the resource. In the example below, the region has been limited to Sydney only with access to everything inside that region. The account will be automatically filled in for you, so there’s no need to worry about that.
Example ARN setup.
Once you’ve clicked Add, it will add the resource signing config to your policy. When you’ve completed adding all the specific resources, you can click on the Add: Tags button to proceed to the next screen.
Resource permissions overview.
You don’t have to add tags to your policy but it can help you organize and make searching for specific policies faster. To add a tag, click on Add Tag. In the example below, I’ve already added a tag with team as the key and serverless as the search value.
Once done, you can click on Next: Review to go to the review screen.
Adding tags for easy search and future access.
In the review screen, you’ll have the opportunity to set up the policy name and description for it. In this screen, you can also review the different permissions and double-check that the resources allocated are correct. Once completed, you can click on the Create Policy button to finalize it.
Giving your policy a name and description.
Once completed, you’ll be directed back to the policy list screen with a success alert.
A successful AWS custom policy has been created.
Where To From Here?
From here, you can attach your custom policies to specific users or roles, depending on what your team needs are. While setting and assigning ARNs to policies can be time-consuming, especially if you have a lot of infrastructure resources to deal with, it is worth the time investment. This is important for resources that only need read permissions or limited write permissions.
Creating policies that limit the ability to access all the resources in your accounts is good practice, especially if that accessibility includes the ability to programmatically take control of all your cloud infrastructure.
