Know that pesky workflow of creating AWS IAM roles and policies, and binding them to Kubernetes ServiceAccounts, just for your pods to be able to access resources on AWS?

Using AWS IRSA, supported on EKS since version 1.14, it is possible to bind service accounts to AWS IAM roles. But that leaves a lot to be desired: managing these resources and their lifecycle, outside of Kubernetes can be a pain.

You’ve gotta create an AWS role, establish a trust relationship with a Kubernetes ServiceAccount through an OIDC provider, grab the role’s ARN and annotate the ServiceAccount, then finally create an IAM policy. Need to have multiple deployments, versions, upgrades, rollbacks? Better get to work.

No more! The open-source intents-operator and credentials-operator enable you to achieve the same, except without all that work: do it all from Kubernetes, declaratively, and just-in-time, through the magic of IBAC (intent-based access control).

How does it work?

Step 1: Label a pod, requesting an AWS IAM role to be created and bound to the ServiceAccount.

Label a pod with this label:

"credentials-operator.otterize.com/create-aws-role": "true"

This creates a matching IAM role, for this specific workload in this namespace in this cluster, that is not shared with other workloads, with the trust relationship set up for your cluster’s OIDC provider.

Step 2: Declare your workload’s ClientIntents, specifying desired permissions.

apiVersion: k8s.otterize.com/v1alpha3
kind: ClientIntents
metadata:
  name: workload
spec:
  service:
    name: workload
  calls:
    - name: arn:aws:s3:::otterize-tutorial-bucket-*/*
      type: aws
      awsActions:
        - 's3:PutObject'

This creates an IAM policy and associates it with the previously created role.

Step 3: Done! Your workload can access AWS resources. AWS will be kept in sync with the cluster state, as you update your Pods and ClientIntents.

Wanna try it out for real? Check out the AWS IAM tutorial.

Wondering what are ClientIntents? Read more about IBAC, intents-based access control.

Can I also map my cluster’s traffic and AWS API calls?

Yep! When you deploy Otterize, you get a map of your cluster’s traffic, with zero-configuration, through the open-source network-mapper.

Coming soon: capture AWS API calls for pods in your cluster, automatically generating the required least-privilege permissions, or ClientIntents, for each workload. Zero-friction in development, zero-trust in production. It’s coming.