From 8dcabcccd4964e35a28bf635fb441565d3e1f3ca Mon Sep 17 00:00:00 2001 From: Ori Shoshan Date: Fri, 17 Nov 2023 21:11:29 +0100 Subject: [PATCH 1/3] Add AWS IAM on EKS tutorial --- docs/intent-based-access-control/README.mdx | 24 +- .../access-control/aws-eks-cni-mini.mdx | 6 +- .../quickstart/access-control/aws-iam-eks.mdx | 330 ++++++++++++++++++ docs/reference/terminology/README.mdx | 2 +- .../aws-iam-eks/client-and-server.yaml | 60 ++++ .../aws-iam-eks/clientintents.yaml | 12 + 6 files changed, 411 insertions(+), 23 deletions(-) create mode 100644 docs/quickstart/access-control/aws-iam-eks.mdx create mode 100644 static/code-examples/aws-iam-eks/client-and-server.yaml create mode 100644 static/code-examples/aws-iam-eks/clientintents.yaml diff --git a/docs/intent-based-access-control/README.mdx b/docs/intent-based-access-control/README.mdx index 765b59d49..721bc2720 100644 --- a/docs/intent-based-access-control/README.mdx +++ b/docs/intent-based-access-control/README.mdx @@ -3,30 +3,17 @@ sidebar_position: 7 title: 'IBAC: Intent-based access control' --- -At Otterize, we believe service-to-service access control should become not only *easy* but actually *transparent* to service developers. We believe that access should not only be self-serve — that it should happen without needing to go through any extra steps beyond what developers are already doing. And we believe that access control enforcement should be completely decoupled from the functional development of the software: that as the organization improves its security and compliance posture, developers should not need to revisit their working code. +At Otterize, we believe workload IAM should become not only *easy* but actually *transparent* to developers. We believe that access should not only be self-serve — that it should happen without needing to go through any extra steps beyond what developers are already doing. And we believe that access control enforcement should be completely decoupled from the functional development of the software: that as the organization improves its security and compliance posture, developers should not need to revisit their working code. -These are the principles of **intent-based access control (IBAC)**, a modern, declarative approach to granting access automatically, responsibly, and scalably. **The developer simply declares, in a *client intents file* alongside their code, what other services the code intends to call.** If the code passes review, so does its intents file, and access is granted automatically to make those calls, regardless of the type of call, the target infrastructure and location, and the enforcement mechanism. Credentials for declared access are automatically managed and supplied to the developer for use in their code, if needed. Any undeclared access is automatically blocked. +These are the principles of **intent-based access control (IBAC)**, a modern, declarative approach to granting access automatically, responsibly, and scalably. **The developer simply declares, in a `ClientIntents` custom resource alongside their code, what other services the code intends to call.** If the code passes review, so does its intents, and access is granted automatically to make those calls, regardless of the type of call, the target infrastructure and location, and the enforcement mechanism. Credentials for declared access are automatically managed and supplied to the service for use in their code, if needed. Any undeclared access is automatically blocked. Here is an example of the client intents file for the `checkoutservice`. It declares that it will call the `emailservice`, the `orderservice`, and the `ecomm-events` Kafka service. -It also provides more granular information for some of the calls: -```yaml -{@include: ../../static/resources/example-intents.yaml} -``` - -
-Intents file as a Kubernetes resource file -
- -Here is the same intents file, now formatted as a Kubernetes custom resource file, -so it can be applied directly via `kubectl apply`: - +It also provides more granular information for some of the calls, which you can optionally specify, like `HTTPResources`: ```yaml {@include: ../../static/resources/example-intents-resource.yaml} ``` -
-
Intent-based access control realizes shift-left for access control. The necessary access is defined by the developer themselves declaring, when the code is created, what calls will be made. Nobody knows better than them what their code needs. And those declarations, living in source control as client intents files along with the code, stay in sync with the code — as opposed to access permissions that live elsewhere, e.g. on a server, where they’re likely to get stale rapidly. Intents are approved along with the code: if it makes sense to approve the code that makes the calls, it should make sense to approve access to what’s being called. @@ -72,8 +59,7 @@ To implement IBAC across heterogeneous environments, IBAC must also solve for th ### IBAC and security -Security controls that don't get implemented don't help. By building service-to-service access -control concerns into the building of the software — capturing the intent at design time, +Security controls that don't get implemented don't help. By shifting-left the access controls - — capturing the intent at design time, *streamlining* for developers the access to secured services, integrating access reviews into existing code review processes, and automating access control configuration at deploy time — IBAC drives adoption of security controls and a zero-trust architecture within the engineering team. @@ -86,7 +72,7 @@ It captures and makes explicit the *intents* of developers and their the code, enables processes for acting on those intents to allow or deny access, and makes explicit the enforcement that's actually put in place. One org might decide that it's best to automatically approve all intents once they undergo code review and apply -them to a staging environment so they can be tested, but require explicit secops approval on any new intent before +them to a staging environment so they can be tested, but require explicit SecOps approval on any new intent before it's applied to production. Another org might decide to require approvals only on some servers (i.e. intents targeted at those servers), and to track them by filing issues against the server teams' ticketing system. And a third org might decide to enforce access controls on certain servers in staging to make sure intents are declared, diff --git a/docs/quickstart/access-control/aws-eks-cni-mini.mdx b/docs/quickstart/access-control/aws-eks-cni-mini.mdx index 154cdfa46..aee0c8d0d 100644 --- a/docs/quickstart/access-control/aws-eks-cni-mini.mdx +++ b/docs/quickstart/access-control/aws-eks-cni-mini.mdx @@ -51,9 +51,9 @@ addons: - name: kube-proxy managedNodeGroups: - - name: x86-al2-on-demand + - name: small-on-demand amiFamily: AmazonLinux2 - instanceTypes: [ "m6i.xlarge", "m6a.xlarge" ] + instanceTypes: [ "t3.large" ] minSize: 0 desiredCapacity: 2 maxSize: 6 @@ -66,7 +66,7 @@ managedNodeGroups: team: "eks" ``` -Then run the following command to create your AWS cluster: +Then run the following command to create your AWS cluster. [Don't have eksctl? Install it now.](https://eksctl.io/installation/) ```shell eksctl create cluster -f cluster-config.yaml diff --git a/docs/quickstart/access-control/aws-iam-eks.mdx b/docs/quickstart/access-control/aws-iam-eks.mdx new file mode 100644 index 000000000..d43d612ee --- /dev/null +++ b/docs/quickstart/access-control/aws-iam-eks.mdx @@ -0,0 +1,330 @@ +--- +sidebar_position: 2 +title: Automate AWS IAM for EKS +--- + +import CodeBlock from "@theme/CodeBlock"; +import Tabs from "@theme/Tabs"; +import TabItem from "@theme/TabItem"; + +Otterize automates AWS IAM roles and policies for your AWS EKS workloads, all in Kubernetes. + +In this tutorial, we will: + +- Optionally, spin up an EKS cluster. +- Deploy a server pod that uploads files to S3, and a client pod that submits files to the server app. +- Label the server pod, telling the credentials operator to link its Kubernetes ServiceAccount with an AWS IAM role created for it, such that AWS IRSA can recognize the pod. +- Create a `ClientIntents` resource allowing the server pod to upload to S3, that tells the intents operator to update the previously-created role's policy. +- See that the files have been uploaded successfully. + +## Prerequisites +Already have Otterize deployed with the IAM integration configured on your cluster? [Skip to the tutorial.](#tutorial) + +#### 1. Create an AWS EKS cluster +Before you start, you'll need an AWS EKS cluster. Any cluster will do; there are no special requirements or setup. + +
+How to set up an AWS EKS cluster using eksctl + + +Save this `yaml` as `cluster-config.yaml`: + +```yaml +apiVersion: eksctl.io/v1alpha5 +kind: ClusterConfig + +metadata: + name: otterize-iam-eks-tutorial + region: us-west-2 + version: "1.27" + +iam: + withOIDC: true + +vpc: + clusterEndpoints: + publicAccess: true + privateAccess: true + +addons: + - name: vpc-cni + version: 1.14.0 + attachPolicyARNs: #optional + - arn:aws:iam::aws:policy/AmazonEKS_CNI_Policy + configurationValues: |- + enableNetworkPolicy: "true" + - name: coredns + - name: kube-proxy + +managedNodeGroups: + - name: small-on-demand + amiFamily: AmazonLinux2 + instanceTypes: [ "t3.large" ] + minSize: 0 + desiredCapacity: 2 + maxSize: 6 + privateNetworking: true + disableIMDSv1: true + volumeSize: 100 + volumeType: gp3 + volumeEncrypted: true + tags: + team: "eks" +``` + +Then run the following command to create your cluster. [Don't have eksctl? Install it now.](https://eksctl.io/installation/) + +```shell +eksctl create cluster -f cluster-config.yaml +``` + +
+ +Don't forget to configure your kubeconfig for your cluster. If using the example cluster above, use this command: +```bash +aws eks update-kubeconfig --region us-west-2 --name otterize-iam-eks-tutorial +``` + +#### 2. Deploy Otterize for AWS IAM +To deploy Otterize, head over to [Otterize Cloud](https://app.otterize.com) and create a Kubernetes cluster on the [Clusters page](https://app.otterize.com/clusters), and follow the instructions. *Make sure to enable enforcement mode for this tutorial.* + +Once you have Otterize deployed, create an AWS IAM integration on the [Integrations page](https://app.otterize.com/integrations). Under "AWS EKS cluster name", fill in the name of your cluster on AWS EKS. In "AWS EKS cluster region", fill in the cluster's region. + +If you are using the cluster from the previous step, the cluster name is `otterize-iam-eks-tutorial` and the region is `us-west-2`. + +Once the AWS integration is configured, you'll be presented with a dialog to launch a CloudFormation template to configure the IAM roles for the Otterize operators. This enables them to manage IAM for the pods in your cluster. +This setup is required once per-cluster, and configures AWS IRSA on your cluster, if it is not yet configured. [This template can be found on GitHub as well](https://github.com/otterize/setup/blob/main/aws-iam-operator-setup-template.yaml). + +After CloudFormation has configured your cluster, redeploy Otterize with the new Helm configuration provided by Otterize Cloud. Since you now have the AWS integration enabled, you need to redeploy Otterize with the credentials operator enabled, and with configuration telling the operators which AWS roles they will AssumeRole to in order to operate. + +
+See how to manually configure AWS IRSA on your cluster for Otterize + + +You may also manually configure your cluster. +1. [Configure AWS IRSA on your cluster according to the official instructions from AWS.](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/setting-up-enable-IAM.html) +2. Create IAM roles for the intents operator and credentials operator. + + 1. Create two roles, named '[your-cluster-name]-otterize-intents-operator' and '[your-cluster-name]-otterize-credentials-operator'. + 2. Each of them should have a trust relationship with the intents-operator and credentials-operator service accounts on your cluster, and federated with your OpenIDConnect provider for the cluster. + Here's an example: + ```json + { + "Version": "2012-10-17", + "Statement": [ + { + "Effect": "Allow", + "Principal": { + "Federated": "arn:aws:iam::353146681200:oidc-provider/oidc.eks.us-west-2.amazonaws.com/id/C90DC306FCDDFFD362B58B0D28D844CB" + }, + "Action": "sts:AssumeRoleWithWebIdentity", + "Condition": { + "StringEquals": { + "oidc.eks.us-west-2.amazonaws.com/id/C90DC306FCDDFFD362B58B0D28D844CB:sub": "system:serviceaccount:otterize-system:intents-operator-controller-manager" + } + } + } + ] + } + ``` + +In this example, `C90DC306FCDDFFD362B58B0D28D844CB` is your OpenIDConnect provider ID. +For the `credentials-operator`, substitute `system:serviceaccount:otterize-system:intents-operator-controller-manager` with `system:serviceaccount:otterize-system:credentials-operator-controller-manager. + + +3. Create IAM policies for these two roles. +They should grant access to all `iam` permissions in the account, and a subset of `organizations` permissions. Here's an example: +```yaml + Statement: + - Effect: Allow + Action: + - "iam:*" + - "organizations:DescribeAccount" + - "organizations:DescribeOrganization" + - "organizations:DescribeOrganizationalUnit" + - "organizations:DescribePolicy" + - "organizations:ListChildren" + - "organizations:ListParents" + - "organizations:ListPoliciesForTarget" + - "organizations:ListRoots" + - "organizations:ListPolicies" + - "organizations:ListTargetsForPolicy" + Resource: "*" +``` + + +
+ +## Tutorial + +### Create an S3 bucket for the server to use + +First, we need to pick an S3 bucket name. Because S3 buckets are globally unique, we will save the bucket name in an environment variable for use later. + +```bash +export BUCKET_NAME=otterize-tutorial-bucket-`date +%s` +echo $BUCKET_NAME +``` + +```bash +aws s3api create-bucket --bucket $BUCKET_NAME --region us-west-2 --create-bucket-configuration LocationConstraint=us-west-2 +``` + +### Deploy the sample server and client + +```shell +kubectl create namespace otterize-tutorial-iam +kubectl apply -n otterize-tutorial-iam -f ${ABSOLUTE_URL}/code-examples/aws-iam-eks/client-and-server.yaml +kubectl patch deployment -n otterize-tutorial-iam server --type='json' -p="[{\"op\": \"replace\", \"path\": \"/spec/template/spec/containers/0/env\", \"value\": [{\"name\": \"BUCKET_NAME\", \"value\": \"$BUCKET_NAME\"}]}]" +``` + +
+Expand to see the deployment YAML + +```yaml +{@include: ../../../static/code-examples/aws-iam-eks/client-and-server.yaml} +``` + +
+ +### View logs for the server - access denied +The server logs will show that it fails to upload files to the S3 bucket. + +```bash +kubectl logs -f -n otterize-tutorial-iam deploy/server +``` + +```bash +2023/11/17 19:08:30 Couldn't upload file testfile.0.txt to otterize-tutorial-bucket-1700247949:testfile.0.txt. +Here's why: operation error S3: PutObject, https response error StatusCode: 403, RequestID: W9ZBNWPDFEMTBBS5, HostID: gsOlyxAmcUqFiYKzB7IwBoPia/Z2TDHEoaJjXT/qAxdduD4H17XDoGu21Pb7zeMms/YeThv2mJk=, +# highlight-next-line +api error AccessDenied: Access Denied +``` + +### Annotate the server pod to create an AWS IAM role +Annotate the server `Pod` so that the Otterize credentials operator creates an AWS IAM role for it and binds its Kubernetes ServiceAccount to the newly created role. + +To do this, we won't be annotating the `Pod` directly, but instead patching the `Deployment` we created earlier so that it updates the `Pod`. + +```bash +kubectl patch deployment -n otterize-tutorial-iam server -p '{"spec": {"template":{"metadata":{"annotations":{"credentials-operator.otterize.com/create-aws-role":"true"}}}} }' +``` + +#### An AWS IAM role was created +Let's inspect the created role: +```bash +aws iam get-role --role-name otterize-sa-otterize-tutorial-iam-server +``` + +In the output, you should see that a role was created, with an `AssumeRolePolicyDocument` that enables the server's ServiceAccount to AssumeRole. +```json +{ + "Role": { + "Path": "/", + "RoleName": "otterize-sa-otterize-tutorial-iam-server", + "Arn": "arn:aws:iam::353146681200:role/otterize-sa-otterize-tutorial-iam-server", + "AssumeRolePolicyDocument": { + "Statement": [ + { + // [...] + "Principal": { + "Federated": "arn:aws:iam::353146681200:oidc-provider/oidc.eks.us-west-2.amazonaws.com/id/3EF68E9F04B82DB73FC1A6563AC423A6" + }, + "Action": "sts:AssumeRoleWithWebIdentity", + "Condition": { + "StringEquals": { + # highlight-next-line + "oidc.eks.us-west-2.amazonaws.com/id/[...]:sub": + # highlight-next-line + "system:serviceaccount:default:service1", + "oidc.eks.us-west-2.amazonaws.com/id/[...]:aud": "sts.amazonaws.com" + } + } + } + ] + }, + // [...] + } +} +``` + +#### The Kubernetes ServiceAccount was annotated with the role ARN +The credentials operator automatically annotated the Kubernetes ServiceAccount for the server pod with the newly created role ARN. + +Let's look at the service account: +```bash +kubectl get serviceaccount -n otterize-tutorial-iam server -o yaml +``` + +```yaml +apiVersion: v1 +kind: ServiceAccount +metadata: + annotations: + # highlight-next-line + eks.amazonaws.com/role-arn: + # highlight-next-line + arn:aws:iam::353146681200:role/otterize-sa-otterize-tutorial-iam-server + name: server + namespace: otterize-tutorial-iam +``` + + +### Apply intents to create the necessary IAM policy + +By annotating the pod, we've created an IAM role. We now need to specify what we need to access, and the intents operator will create an IAM policy accordingly. + +We will specify the following ClientIntents, granting the PutObject permission to the `otterize-tutorial-bucket` S3 bucket. +```yaml +{@include: ../../../static/code-examples/aws-iam-eks/clientintents.yaml} +``` + +To apply these intents, run the following command: +```bash +kubectl apply -n otterize-tutorial-iam -f ${ABSOLUTE_URL}/code-examples/aws-iam-eks/clientintents.yaml +``` + +### The server can now upload files to S3! + +But first, let's restart the server. This is necessary so that [AWS IRSA](https://docs.aws.amazon.com/eks/latest/userguide/iam-roles-for-service-accounts.html) will be able to inject the AWS access key and secret as environment variables. + +```bash +kubectl rollout restart -n otterize-tutorial-iam deployment/server +``` + +Let's look at the server logs again to see that no more errors are being reported: + +Let's list the contents of the S3 bucket: +```bash +aws s3 ls $BUCKET_NAME +``` + +```bash +2023-11-17 20:43:05 19 testfile.0.txt +2023-11-17 20:42:35 19 testfile.1.txt +2023-11-17 20:42:45 19 testfile.2.txt +2023-11-17 20:42:55 19 testfile.3.txt +``` + +## What's next? + +Try out some of the other quick tutorials to learn about how to use ClientIntents to manage network policies, Istio policies, PostgreSQL access, and more. You can use a single ClientIntents resource to specify all the access required for a pod. + +## Teardown + +To remove the deployed examples run: + +```bash +kubectl delete namespace otterize-tutorial-iam +``` + +To delete the cluster, if you created the one in this tutorial: +```bash +eksctl delete cluster -f cluster-config.yaml +``` + +To empty and delete the S3 bucket created for this tutorial: +```bash +aws s3 rm s3://otterize-tutorial-bucket --recursive +aws s3 rb s3://otterize-tutorial-bucket +``` diff --git a/docs/reference/terminology/README.mdx b/docs/reference/terminology/README.mdx index 0d2d1484f..ae2f48b00 100644 --- a/docs/reference/terminology/README.mdx +++ b/docs/reference/terminology/README.mdx @@ -34,7 +34,7 @@ but google.com does not authenticate you, as the client, with a certificate, so ### SPIRE An open-source implementation of the [SPIFFE](https://github.com/spiffe/spire) specification. It's used for workload attestation and credential management. [Read more about SPIRE in the official documentation](https://spiffe.io/docs/latest/spire-about/). -### credentials operator +### CCKETredentials operator The Otterize [credentials operator](/reference/configuration/credentials-operator) automatically resolves pods to dev-friendly service names, registers them with a SPIRE server or with the Otterize Cloud-managed credentials service, and provisions credentials as Kubernetes Secrets. ## Enforcement diff --git a/static/code-examples/aws-iam-eks/client-and-server.yaml b/static/code-examples/aws-iam-eks/client-and-server.yaml new file mode 100644 index 000000000..129bf8e68 --- /dev/null +++ b/static/code-examples/aws-iam-eks/client-and-server.yaml @@ -0,0 +1,60 @@ +apiVersion: apps/v1 +kind: Deployment +metadata: + name: server +spec: + replicas: 1 + selector: + matchLabels: + app: server + template: + metadata: + labels: + app: server + spec: + serviceAccountName: server + containers: + - name: server + imagePullPolicy: Always + image: 'public.ecr.aws/e3b4k2v5/ekstutorial:server' + ports: + - containerPort: 80 +--- +apiVersion: v1 +kind: Service +metadata: + name: server +spec: + type: ClusterIP + selector: + app: server + ports: + - name: http + port: 80 + targetPort: 80 +--- +apiVersion: v1 +kind: ServiceAccount +metadata: + name: server +--- +apiVersion: apps/v1 +kind: Deployment +metadata: + name: client +spec: + replicas: 1 + selector: + matchLabels: + app: client + template: + metadata: + labels: + app: client + spec: + containers: + - name: client + imagePullPolicy: Always + image: 'public.ecr.aws/e3b4k2v5/ekstutorial:client' + ports: + - containerPort: 80 diff --git a/static/code-examples/aws-iam-eks/clientintents.yaml b/static/code-examples/aws-iam-eks/clientintents.yaml new file mode 100644 index 000000000..27a18dd2a --- /dev/null +++ b/static/code-examples/aws-iam-eks/clientintents.yaml @@ -0,0 +1,12 @@ +apiVersion: k8s.otterize.com/v1alpha3 +kind: ClientIntents +metadata: + name: server +spec: + service: + name: server + calls: + - name: arn:aws:s3:::otterize-tutorial-bucket-*/* + type: aws + awsActions: + - "s3:PutObject" \ No newline at end of file From e713ff3f4bfa71f9cc08aab5b7147107a594bbe0 Mon Sep 17 00:00:00 2001 From: Ori Shoshan Date: Sat, 18 Nov 2023 19:50:36 +0100 Subject: [PATCH 2/3] Update instructions --- .../quickstart/access-control/aws-iam-eks.mdx | 23 +++++++++++-------- 1 file changed, 14 insertions(+), 9 deletions(-) diff --git a/docs/quickstart/access-control/aws-iam-eks.mdx b/docs/quickstart/access-control/aws-iam-eks.mdx index d43d612ee..1eaf681cc 100644 --- a/docs/quickstart/access-control/aws-iam-eks.mdx +++ b/docs/quickstart/access-control/aws-iam-eks.mdx @@ -149,6 +149,8 @@ They should grant access to all `iam` permissions in the account, and a subset o - "organizations:ListRoots" - "organizations:ListPolicies" - "organizations:ListTargetsForPolicy" + - "ec2:DescribeInstances" + - "eks:DescribeCluster" Resource: "*" ``` @@ -201,13 +203,13 @@ Here's why: operation error S3: PutObject, https response error StatusCode: 403, api error AccessDenied: Access Denied ``` -### Annotate the server pod to create an AWS IAM role -Annotate the server `Pod` so that the Otterize credentials operator creates an AWS IAM role for it and binds its Kubernetes ServiceAccount to the newly created role. +### Label the server pod to create an AWS IAM role +Label the server `Pod` so that the Otterize credentials operator creates an AWS IAM role for it and binds its Kubernetes ServiceAccount to the newly created role. To do this, we won't be annotating the `Pod` directly, but instead patching the `Deployment` we created earlier so that it updates the `Pod`. ```bash -kubectl patch deployment -n otterize-tutorial-iam server -p '{"spec": {"template":{"metadata":{"annotations":{"credentials-operator.otterize.com/create-aws-role":"true"}}}} }' +kubectl patch deployment -n otterize-tutorial-iam server -p '{"spec": {"template":{"metadata":{"labels":{"credentials-operator.otterize.com/create-aws-role":"true"}}}} }' ``` #### An AWS IAM role was created @@ -286,13 +288,16 @@ kubectl apply -n otterize-tutorial-iam -f ${ABSOLUTE_URL}/code-examples/aws-iam- ### The server can now upload files to S3! -But first, let's restart the server. This is necessary so that [AWS IRSA](https://docs.aws.amazon.com/eks/latest/userguide/iam-roles-for-service-accounts.html) will be able to inject the AWS access key and secret as environment variables. - -```bash -kubectl rollout restart -n otterize-tutorial-iam deployment/server -``` - Let's look at the server logs again to see that no more errors are being reported: +```json +{ + # highlight-next-line + "status":200, + "host":"server", + "method":"POST", + "uri":"/upload" +} +``` Let's list the contents of the S3 bucket: ```bash From 2f6d872cf980e01b9ab4eb3a6d5bdaaa73258c50 Mon Sep 17 00:00:00 2001 From: Ori Shoshan Date: Sun, 19 Nov 2023 22:24:39 +0100 Subject: [PATCH 3/3] CR comments --- docs/quickstart/access-control/aws-iam-eks.mdx | 12 +++++++----- 1 file changed, 7 insertions(+), 5 deletions(-) diff --git a/docs/quickstart/access-control/aws-iam-eks.mdx b/docs/quickstart/access-control/aws-iam-eks.mdx index 1eaf681cc..a1da4ec78 100644 --- a/docs/quickstart/access-control/aws-iam-eks.mdx +++ b/docs/quickstart/access-control/aws-iam-eks.mdx @@ -86,16 +86,18 @@ aws eks update-kubeconfig --region us-west-2 --name otterize-iam-eks-tutorial ``` #### 2. Deploy Otterize for AWS IAM -To deploy Otterize, head over to [Otterize Cloud](https://app.otterize.com) and create a Kubernetes cluster on the [Clusters page](https://app.otterize.com/clusters), and follow the instructions. *Make sure to enable enforcement mode for this tutorial.* +To deploy Otterize, head over to [Otterize Cloud](https://app.otterize.com) and: -Once you have Otterize deployed, create an AWS IAM integration on the [Integrations page](https://app.otterize.com/integrations). Under "AWS EKS cluster name", fill in the name of your cluster on AWS EKS. In "AWS EKS cluster region", fill in the cluster's region. +1. Create a Kubernetes cluster on the [Clusters page](https://app.otterize.com/clusters), and follow the instructions. *Make sure to enable enforcement mode for this tutorial.* If you already have a Kubernetes cluster connected, skip this step. + +2. Create an AWS IAM integration on the [Integrations page](https://app.otterize.com/integrations). If you are using the cluster from the previous step, the cluster name is `otterize-iam-eks-tutorial` and the region is `us-west-2`. -Once the AWS integration is configured, you'll be presented with a dialog to launch a CloudFormation template to configure the IAM roles for the Otterize operators. This enables them to manage IAM for the pods in your cluster. +Once the AWS integration is configured, you'll be presented with a dialog to launch a CloudFormation template to configure the IAM roles for the Otterize operators. This enables the operators to manage IAM for the pods in your cluster. This setup is required once per-cluster, and configures AWS IRSA on your cluster, if it is not yet configured. [This template can be found on GitHub as well](https://github.com/otterize/setup/blob/main/aws-iam-operator-setup-template.yaml). -After CloudFormation has configured your cluster, redeploy Otterize with the new Helm configuration provided by Otterize Cloud. Since you now have the AWS integration enabled, you need to redeploy Otterize with the credentials operator enabled, and with configuration telling the operators which AWS roles they will AssumeRole to in order to operate. +After CloudFormation has configured your cluster, click Next and you'll be presented with the configuration for deploying Otterize. Since you now have the AWS integration enabled, you need to redeploy Otterize with the credentials operator enabled, and with configuration telling the operators which AWS roles they will AssumeRole to in order to operate.
See how to manually configure AWS IRSA on your cluster for Otterize @@ -206,7 +208,7 @@ api error AccessDenied: Access Denied ### Label the server pod to create an AWS IAM role Label the server `Pod` so that the Otterize credentials operator creates an AWS IAM role for it and binds its Kubernetes ServiceAccount to the newly created role. -To do this, we won't be annotating the `Pod` directly, but instead patching the `Deployment` we created earlier so that it updates the `Pod`. +To do this, we won't be annotating the `Pod` directly, but instead patching the `template` attribute of the `Deployment` we created earlier so that it updates the `Pod`. ```bash kubectl patch deployment -n otterize-tutorial-iam server -p '{"spec": {"template":{"metadata":{"labels":{"credentials-operator.otterize.com/create-aws-role":"true"}}}} }'