Enabling customers starts with trusted access

One of the first challenges in assisting AWS customers who have engaged a partner from the AWS Partner Network, like Hestio, is providing secure access to their AWS accounts with minimal permissions that align with good security practice.

Solution partners in the AWS Partner Network are often involved in shorter projects and ad-hoc activities such as security audits, well architected reviews, AWS migrations, and workload provisioning.

So, how can we make it easier for all AWS partners, not just Hestio, to help AWS customers?

Different needs, Same goal.

This is a common issue in the AWS ecosystem that cannot be solved by modern OpenID Connect (OIDC), better suited to longer-term identity federation and access controls and now the preferred means of connecting SaaS securely to your AWS accounts. Given the shorter-term nature of what is required, we need a solution that will help with both sides of this challenge;

AWS Service Provider	AWS Customer
Should be easy to scale to securing thousands of customers for a Managed Service Partner	Access should be easy to add and remove
Should be compatible with the Service Provider's own AWS access controls	Securing access via a 2nd factor ensures access is only granted when permitted by customer

We start with a trusted 3rd party all Service Providers and Customers share; AWS. By taking advantage of the shared trust, we can provide a secure method of managing sensitive information and granting temporary access. That should be easy, right?

What should be a simple task is clearly not. It's around now that the suggestion will be made to add a new IAM User, generate some API credentials and share those with the Service Provider by;

• emailing them
• emailing half of them
• sharing them via the chat feature in a video meeting

And so the list goes on. These are all terrible options. Even the options that might seem viable for the customer are not going to be viable for the Service Provider when scaled to hundreds of customers. The Service Provider now has hundreds of credentials for hundreds of customers and no good way to map the duties of one of their own employees to only the list of customers they should have access to.

Let's not do that. Instead let's solve this challenge by using our shared trust of AWS to build a flexible approach that can handle many customers, making it easy for both service provider and customer to enable and automate.

Two sides, two patterns, one solution

Within worX, our low-code patterns library for AWS, we have two patterns that solve this exact challenge;

• Service Provider Access (for customers)
• Customer Access (for service providers)

Figure: worX Access Patterns Workflow

Customer Flow

1. The customer uses the Service Provider Access pattern to create a cross-account trust from the Service Providers' account to their own, assigning permissions via existing policies in their account or using a custom IAM Policy if required.
2. An optional 2nd factor can be added (external-id) as a means to limit when this access is available (more on that below)
3. When provisioned, the pattern will generate ARNs that represent the roles the Service Provider can assume only from their designated Service Provider account.
4. These ARNs can then be safely shared via email as they contain no credentials and can only be made use of when combined with a 2nd factor provided by the customer

Service Provider Flow

1. Using a designated customer or security AWS account, the service provider makes the customer IAM Roles available to their own engineers
2. Additional granularity can be added by creating separate Roles or permission sets for each customer, allowing only specific team members to access specific customers
3. When needed, the customer permissions can only be accessed by assuming these cross-account IAM Roles using the 2nd factor provided by the customer

Show me already!

AWS Customer

Customer adding access for a Service Provider

Figure: Customer Side

To make it easy, we have prepared everything for you, you only need to grab a copy of the Git repo and follow the steps below:

Clone or download the demo repo from GitLab worx-service-provider-repository

git clone https://gitlab.com/hestio-community/worx-demo-patterns/worx-demo-control-service-provider.git

Update the example.yml according to your reference the

• AWS Account of your Service Provider
• The permissions you would like to assign the Service Provider
• An optional 2nd factor that will be required by the Service Provider when assuming the permissions

Let Terraform take care of the rest

terraform init
terraform plan -out=customer.plan
terraform apply customer.plan

That's it! We have successfully provisioned the worX Service Provider Access pattern. Let's confirm our new roles are in place using AWS CLI or using our AWSH and BLOX toolset containers

AWS CLI❯

aws iam list-roles \
  --query 'Roles[?contains(RoleName, `ServiceProvider`)].Arn' \
  --output text

BLOX❯

awsh list iam-role | grep "ServiceProvider"

AWS Service Provider

Service Provider assigning access to Customer to their Engineers

Figure: Service Provider Side

To make it easy, we have prepared everything for you, you only need to grab a copy of the Git repo and follow the steps below:

Clone or download the demo repo from GitLab worx-customer-access-repository

git clone https://gitlab.com/hestio-community/worx-demo-patterns/worx-demo-control-service-customer.git

Update the example.yml according to your reference the

• ARNs of the Customer roles you have been assigned
• The IAM Roles within the Service Provider that have permissions to assume the customer roles

Let Terraform take care of the rest

terraform init
terraform plan -out=provider.plan
terraform apply provider.plan

That's it! We have successfully provisioned the worX Customer Access pattern.

Access in action

Now that we have successfully provisioned both patterns we can follow the entire flow from the Service Provider perspective. Let's do that from within our BLOX shell on a secure cloud workspace, which is where all of Hestio's engineers work from.

Service Provider AWS Account

Login as a Service Provider user that has been allocated permissions to access the Customer AWS account

BLOX❯

awsh creds load
<follow the instructions on-screen>

Display our active identity and role within the Service Provider account

BLOX❯

awsh whoami

Access our customer by assuming the provisioned Service Provider they created for us, providing the 2nd factor token (external-id) if enabled by the customer

BLOX❯

awsh sudo <ARN>
awsh sudo <ARN> <external-id-token>

Now that we have securely authenticated access to the customer AWS Account we can use the restricted permissions we have been assigned by the customer

Customer AWS Account

Display our active identity and role within the Customer account

BLOX❯

awsh whoami

For our demo, in this customer account we have been assigned S3 full access and EC2 read access, let's confirm it's working as expected.

BLOX❯

awsh list s3bucket

Name                                                 CreationDate
---------------------------------------------------  ------------------------
hio-sbx-cloudtrail                                   2022-06-07T14:20:34.000Z
cf-templates-test2ko-eu-west-1                       2022-08-05T11:34:00.000Z
cf-templates-skwo20z-us-east-1                       2022-04-07T14:24:48.000Z
hestio-newfeature-tutorial-test-bucket               2023-03-10T11:02:32.000Z
hhsio-prod-environment                               2023-07-25T10:48:10.000Z
hhsio-test-env-log                                   2023-07-26T15:14:41.000Z

Let's test our permissions boundary by testing access to EKS, which we shouldn't have access to at present.

BLOX❯

awsh list eks-clusters

INFO: This filter uses a generator. Please be patient while we collect data

An error occurred (AccessDeniedException) when calling the ListClusters operation:
User: arn:aws:iam::123456789123:role/HIO-DEV-EUW1-ServiceProvider-Role/CustomerAccount
is not authorized to perform: eks:ListClusters on resource:
arn:aws:eks:eu-west-1:123456789123:cluster/*

Excellent! Easy to go from Service Provider to Customer AWS accounts securely and with useful indicators to help us identify when we're in a Service Provider or Customer account.

But wait, there's more...

While we have simplified the entire process of setting up both sides for secure access, there's more we can do. We want to enable fellow AWS Partners and customers alike, and how better to do that than making it available to everyone.

Yes. That's right, these patterns are available for free in the our Hestio Community area on GitLab

So why not level up our access controls and combine these patterns with some awesome automation to take advantage of rotating our 2nd factor token (you forgot about that, didn't you!?)

Orchestrate worX with Scalr

What is Scalr?

Scalr is a Terraform automation and collaboration platform that helps businesses automate and manage their infrastructure across multiple cloud providers. Scalr helps technical teams of all sizes deploy IT resources using infrastructure as code while maintaining policies around cost, security, and compliance. Find out more at https://www.scalr.com/

All we have to do is to add a new workspace using either the Customer (Service Provider Access) or Provider (Customer Access) side demo repos we have provided for you. If you already have the GitLab VCS provider connected to Scalr you can option to Enter the ID manually to use one of the Git repos below to try it out for yourself

• Customer adding access for their Service Provider:
  hestio-community/worx-demo-patterns/worx-demo-control-service-provider
• Service Provider assigning access to a customer for their Engineers:
  hestio-community/worx-demo-patterns/worx-demo-control-service-customer

Add Workspace

Figure: Adding a workspace using a manual GitLab ID

Setup Workspace

Figure: Scalr workspace setup

Plan & Review

Figure: Terraform Init and Plan

Apply Changes

Figure: Terraform Apply

This is how we added access for Scalr to our own AWS accounts. We used the Service Provider Access pattern to provision managed access to our own AWS account for this demo!

Connect Scalr to AWS

Figure: Adding an AWS account to integrate Scalr

Using worX

Figure: Using the Service Provider Access IAM Role

So whether you are an AWS Partner looking to enable your customers to provide the access needed for a project or a Solution provider looking to simplify the experience for onboarding new customers these paired Control Patterns from the worX catalog are here to help.

Documentation for both the Service Provider Access and Customer Access patterns are available in our Learn section, where you can read more about each pattern and find reference examples.

Want to find out more?

At Hestio, we have taken our experience with designing and building on cloud to codify these patterns and made them available as a low-code pattern library for AWS. Why spend time and effort on reinventing the wheel when it's already a solved problem? Would you start developing office productivity software in a world where Microsoft Office already exists?

If you'd like to find out about worX, our low-code patterns library for AWS you can read more here or get in touch today to schedule a demo.

If you'd like to find out more about the products and services Hestio has to offer, select one of the options below.

Products

worX
Low-Code Patterns for AWS

Services

fleXpertise
AWS Expertise-as-a-Service