- 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 ShoshanPublished Date
Nov 28 2023Read Time
2 minutesIn this Article
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.
In this Article
Like this article?
Sign up for newsletter updates
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.