Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[release-0.17] add OIDC provider best practice #6710

Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
10 changes: 6 additions & 4 deletions docs/content/en/docs/getting-started/optional/irsa.md
Original file line number Diff line number Diff line change
Expand Up @@ -5,7 +5,7 @@ weight: 20
aliases:
/docs/reference/clusterspec/optional/irsa/
description: >
EKS Anywhere cluster spec for Pod IAM (IRSA)
EKS Anywhere cluster spec for IAM Roles for Service Accounts (IRSA)
---

### IAM Role for Service Account on EKS Anywhere clusters with self-hosted signing keys
Expand All @@ -16,7 +16,9 @@ The steps below are based on the [guide for configuring IRSA for DIY Kubernetes,

### Create an OIDC provider and make its discovery document publicly accessible

1. Create an s3 bucket to host the public signing keys and OIDC discovery document for your cluster as per [this section.](https://github.com/aws/amazon-eks-pod-identity-webhook/blob/master/SELF_HOSTED_SETUP.md#create-an-s3-bucket) Ensure you follow all the steps and save the `$HOSTNAME` and `$ISSUER_HOSTPATH`.
You must use a single OIDC provider per EKS Anywhere cluster, which is the best practice to prevent a token from one cluster being usable with the API server of another cluster. These steps describe the process of using a S3 bucket to host the OIDC `discovery.json` and `keys.json` documents. You do not have to use S3, as the primary requirement is that AWS STS can access the OIDC documents. If you do use S3, you can have a single bucket or multiple buckets to host the OIDC documents. If you use a single bucket, you can host the OIDC documents in separate paths within the bucket, which can then be used for the `ISSUER_HOSTPATH` in the discovery document for each OIDC provider.

1. Create an S3 bucket to host the public signing keys and OIDC discovery document for your cluster as per [this section.](https://github.com/aws/amazon-eks-pod-identity-webhook/blob/master/SELF_HOSTED_SETUP.md#create-an-s3-bucket) Ensure you follow all the steps and save the `$HOSTNAME` and `$ISSUER_HOSTPATH`.

1. Create the OIDC discovery document as follows:

Expand Down Expand Up @@ -159,7 +161,7 @@ Set the remaining fields in cluster spec as required and create the cluster usin
eks.amazonaws.com/token-expiration: "86400"
```

1. Run the following command to apply the manifests for the amazon-eks-pod-identity-webhook. The image used here will be pulled from docker.io. Optionally, the image can be imported into (or proxied through) your private registry. Change the IMAGE= argument here to your private registry if needed.
1. Run the following command to apply the manifests for the `amazon-eks-pod-identity-webhook`. The image used here will be pulled from docker.io. Optionally, the image can be imported into (or proxied through) your private registry. Change the `IMAGE` argument here to your private registry if needed.

```bash
make cluster-up IMAGE=amazon/amazon-eks-pod-identity-webhook:latest
Expand All @@ -171,7 +173,7 @@ Set the remaining fields in cluster spec as required and create the cluster usin
kubectl apply -f my-service-account.yaml
```

1. You can validate IRSA by using test steps mentioned [here](https://anywhere.eks.amazonaws.com/docs/workshops/packages/adot/adot_amp_amg/#irsa-set-up-test). Ensure awscli pod is deployed in same namespace of ServiceAccount pod-identity-webhook.
1. You can validate IRSA by using test steps mentioned [here](https://anywhere.eks.amazonaws.com/docs/workshops/packages/adot/adot_amp_amg/#irsa-set-up-test). Ensure awscli pod is deployed in same namespace of ServiceAccount `pod-identity-webhook`.


### Configure the trust relationship for the OIDC provider's IAM Role
Expand Down