🩩 Heading to KubeCon in Salt Lake City? Join us at the Otterize booth for live demos, hands-on labs, and exclusive giveaways!
Learn More

Blog
  • Amazon
  • AWS
  • IAM
  • Kubernetes
  • Zero-trust
  • IBAC

Otterize launches open-source, declarative IAM permissions for workloads on AWS EKS clusters

Simplify your AWS IAM role and policy management for Kubernetes ServiceAccounts with the open-source intents-operator and credentials-operator, leveraging the power of IBAC (intents-based access control) to streamline the process and eliminate the tedious manual steps.

Written By
Ori Shoshan
Published Date
Nov 28 2023
Read Time
2 minutes

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.

Screenshot of AWS IAM role with attached policies


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.

Screenshot of access graph

Like this article?

Sign up for newsletter updates

By subscribing you agree to with our Privacy Policy and to receive updates from us.
Share article
Blog & Content

Read things that Otis, our sweet mascot, wrote. Oh, and also the rest of the team. But they aren't otters so whatevs.

    Blog
    Oct 31 2024
    Kubernetes Liveness Probe Failed: Connection Refused

      Blog
      Oct 24 2024
      DNS Resolution Failure in Kubernetes? Network Policies Might Be the Culprit!

        Blog
        Oct 17 2024
        Prometheus Can't Reach Your App? Network Policies Might Be to Blame!