Blog: Using AWS service role in CloudHub 2.0

AWS Service Roles allow services to securely interact with other AWS services on your behalf by assuming roles with the necessary permissions. This simplifies access management and reduces the need to handle long-term credentials.

CloudHub 2.0 works on top of an AWS EKS service, so we can leverage AWS Service Roles to connect our APIs with many other AWS services used by our integrations, such as SQS, S3, DynamoDB, Secret Manager, etc.

In this article, we will see how it works and how to implement it.

Service role & private spaces

Services Roles are available per Private Space. Each one will give you a specific service role to be configured in AWS, e.g:

All Apps deployed in the private space can assume that role and securely connect with the AWS services you allow in your AWS IAM.

Let’s start the configuration by enabling the Service Role feature in the Runtime Manager:

1. From Anypoint Platform, go to Runtime Manager → Private Spaces
2. Select the Private Space desired
3. Click on the Advanced tab and then Enable AWS Service Role
4. Click Save Changes

⚠️ This will take a few minutes to create. Be patient 🙂

Once created, the role will look like this:

Now that the Service Role is enabled in the Anypoint Platform let’s go to the AWS Console to configure it in the IAM.

1. From the AWS Console, go to IAM → Roles
2. Click on Create role and then select Custom trust policy. Add the following policy configuration:
   1. Replace the content of the tag “Principal” with the role created in the previous step.
      
3. Click on Next and skip the permissions for now (We will create a new inline policy for this example).
4. In the final step, define a name for the role and click Create role:
   

With the role created, now let’s give the permissions for the resources:

1. Open the role created and in the Permissions policies section, click on Add permissions and then Create inline policy:
   
2. In this example, I will give permissions to Send, Receive and Delete messages in SQS for a specific queue called notification-queue-dev. So, let’s add the following JSON to the policy editor:
   1. Replace the tag “Resource” with your resource ARN:
      
3. Click on Next, give a name to the inline policy, then click Create policy.

At this stage, the role and permissions are set and ready to go:

Using Service Roles & Project Configuration

Let’s build our example project to play with the service roles. You can build a simple flow to receive messages from SQS. You can find my example on this GitHub repo.

Configure the SQS Connector to use the Role as the connection type and fill these other properties as this:

• Role ARN: The ARN role created in the previous step
• Access Key & Secret Key: The connector requires it. You can use any dummy value.
• Try Default AWS Credentials Provider Chain: True
  • This will force the connector to get credentials from the service role. 
• Region Endpoint: The region where your service is running.
  
  

It’s done. Now, you can deploy your App in the CH2 Private Space and connect with your AWS Services. This approach will not use long-term credentials anymore. You can define and limit the boundaries of what services and resources your applications in CloudHub 2.0 will be able to access, and it’s simple to maintain.

Local environment

You might be asking one question now: How about my local environment? How can a developer access the service from his local environment? 

Well, there are different ways to tackle this; let’s have a look at two options.

The first option would be giving permission to a group (developers) to assume a role and interact with the DEV resources.

The second one is similar, but in this case, you can create programmatic access in IAM and give this user/access the same capability to assume a role and interact only with the DEV resources. Let’s explore a lit bit more this second example: 

1. From the AWS Console, go to IAM → Users
2. Click Create user. Create a new IAM user without access to the console and leave it without any permissions. Then, generate the access keys. Save the keys in a safe place. We will use them later.
   
3. Now, go to IAM → Roles
4. Open the previous Service Role created (We will use the previous one for simplicity)
5. Under Trust relationships, click Edit trust policy
   1. Include the the user ARN in the tag “Principal”:
      
6. Click Update policy

This will now allow the user developers to also assume this role and then connect with the services allowed on it.

⚠️ To reduce de exposure of your resources, considered creating a different service role for developers and restrict it only with the desired resources.

Using in the local environment

Developers can now configure the access key and secret on their local environment using AWS CLI:

Authenticating using IAM user credentials for the AWS CLI - AWS Command Line Interface 

With the credentials configured, run the project locally in Anypoint Studio.

By using the option Try Default AWS Credentials Provider Chain, the connector will try to get credentials locally first and will use the access key configured with AWS CLI. (See this link to check the detailed order the connector uses to extract credentials)

The process for connecting and using the credentials locally is the same whether you use the option to give developers access or create a specific user for this. 

⚠️ If you want to explicitly declare the access key in the connector configuration, you need to set up Try Default AWS Credentials Provider Chain to false. This will later impact the configuration while your app is deployed, so you will need to create two different connector configurations, one for CH2 and the other for local.

Final thoughts

AWS Service Roles offers a secure and scalable way to manage access to AWS services. By leveraging roles, you enhance the security of your integrations, reduce the risk of credential exposure, and simplify access management across different AWS services like SQS, S3, and DynamoDB.