Komiser EKS cluster deployment with multiple AWS account access

Have you tested Komiser locally and would like to take the next step and deploy it to a Kubernetes cluster?

Follow the steps below to launch a Komiser deployment that authenticates to various AWS accounts in a safe and compliant way by leveraging the EKS authentication method via OIDC identity providers.

In this tutorial we will take steps to deploy Komiser to an EKS cluster and allow it to access resources in another AWS account (as well as in the resources of the AWS account where the Komiser is running in).

The two example clusters are ADMIN (Komiser will be deployed here) and DEV.

Note: all code snippets in the article can be found here.

Solution diagram:

1 — Create an IAM OIDC provider for your ADMIN cluster

• Open the Amazon EKS console.
• Select the name of your cluster.
• In the Details section on the Overview tab, note the value of the OpenID Connect provider URL.
• Open the IAM console.
• In the left navigation pane, choose Identity Providers under Access management. If a Provider is listed that matches the URL for your cluster, then you already have a provider for your cluster. If a provider isn’t listed that matches the URL for your cluster, then you must create one.

• To create a provider, choose Add Provider.
• For Provider Type, choose OpenID Connect.
• For the Provider URL, paste the OIDC issuer URL for your cluster, and then choose Get thumbprint.
• For Audience, enter sts.amazonaws.com and choose Add provider.

2 — Register the ADMIN OIDC provider in the DEV cluster

• Grab the OpenID Connect provider URL from the ADMIN account.
• Open the IAM console.
• In the left navigation pane, choose Identity Providers under Access management.
• To create a provider, choose Add Provider.
• For Provider Type, choose OpenID Connect.
• For Provider URL, paste the ADMIN OIDC issuer URL, and then choose Get thumbprint.
• For Audience, enter sts.amazonaws.com and choose Add provider.

3 — Create an ADMIN IAM roleOpen the IAM console.

1. Open the IAM console
2. In the left navigation pane, choose Policies and then choose Create policy.
3. Choose the JSON tab.
4. In the Policy Document field, paste the Komiser recommended policy.
5. Choose Review policy.
6. Enter a name and description for your policy and then choose Create policy.
7. Record the Amazon Resource Name (ARN) of the policy to use later when you create your role.
8. Generate the trust relationship with the Dev Account
9. We will need to have a trust policy to attach to the role so in your terminal run the following script

NOTE: Make sure to substitute ${NAMESPACE} for the namespace you will deploy the helm chart in. If deployed in any other namespace, you will see sts:AssumeRoleWithWebIdentity failure messages in the pod logs.

• Run the modified code block from the previous step to create a file named trust.json.
• Run the following AWS CLI command to create the role. Replace “my-iam-role” with a name for your IAM role, and “my-role-description” with a description for your role.

• Run the following command to attach an IAM policy to your role. Replace “my-iam-role” with the name of your IAM role, 111122223333 with your account ID (or with aws, if you’re attaching an AWS managed policy), and my-iam-policy with the name of an existing policy that you created or an IAM AWS managed policy.

4 — CREATE A DEV IAM role

• Same as in step 3 but in the Dev account.
• Add the recommended Komiser policy
• Create a Trust Relationship with the ADMIN role

5 — Add the ADMIN role to the ServiceAccount

6 — Add a ConfigMap to the /templates folder

• Create a ConfigMap manifest file with the profile credentials data for each account.
• Add the configmap.yaml file to the /templates folder in the root of the repository.

7- Mount the ConfigMap to the Deployment manifest

• Mount the ConfigMap onto the deployment in order to be able to load the pod with the requisite AWS credentials
• Make sure not to change the mount path or internal volume path, paths should match the example below.
• Add the command: [“ — multiple”] to the container to allow a multi account setup

Deploy the helm chart:

You should be good to go! Try accessing the endpoint which is exposed by the service.

Check out the tutorial video below which goes through each step:

https://www.youtube.com/watch?v=pYfjHKM1gzw

Regardless if you are a Developer, DevOps, or Cloud engineer. Dealing with the cloud can be tough at times, especially on your own. If you are using Tailwarden or Komiser and want to share your thoughts doubts and insights with other cloud practitioners feel free to join our Tailwarden discord server. Where you will find tips, community calls, and much more.