From de4a41ccdbee34525e7472e562791addc50f22b0 Mon Sep 17 00:00:00 2001 From: csplinter Date: Tue, 29 Aug 2023 10:30:35 -0500 Subject: [PATCH 1/4] add OIDC provider best practice --- docs/content/en/docs/getting-started/optional/irsa.md | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/docs/content/en/docs/getting-started/optional/irsa.md b/docs/content/en/docs/getting-started/optional/irsa.md index ff76106be752..9deebe208557 100644 --- a/docs/content/en/docs/getting-started/optional/irsa.md +++ b/docs/content/en/docs/getting-started/optional/irsa.md @@ -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 @@ -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 useable with the API server of another cluster. These steps describe the process of using an S3 bucket to host the OIDC discovery 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: @@ -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 @@ -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 From ae530759319c4c42e7b63f63f4444c21c27f6e88 Mon Sep 17 00:00:00 2001 From: Chris Splinter Date: Tue, 29 Aug 2023 14:17:00 -0500 Subject: [PATCH 2/4] Update docs/content/en/docs/getting-started/optional/irsa.md Co-authored-by: Drew Flower --- docs/content/en/docs/getting-started/optional/irsa.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/content/en/docs/getting-started/optional/irsa.md b/docs/content/en/docs/getting-started/optional/irsa.md index 9deebe208557..c06aa1b10cf9 100644 --- a/docs/content/en/docs/getting-started/optional/irsa.md +++ b/docs/content/en/docs/getting-started/optional/irsa.md @@ -173,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 From ebb9d20f2ee42a284a6dfcadfe6c9140a3f62694 Mon Sep 17 00:00:00 2001 From: Chris Splinter Date: Tue, 29 Aug 2023 14:20:53 -0500 Subject: [PATCH 3/4] clarify OIDC documents --- docs/content/en/docs/getting-started/optional/irsa.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/content/en/docs/getting-started/optional/irsa.md b/docs/content/en/docs/getting-started/optional/irsa.md index c06aa1b10cf9..87092cbf039c 100644 --- a/docs/content/en/docs/getting-started/optional/irsa.md +++ b/docs/content/en/docs/getting-started/optional/irsa.md @@ -16,7 +16,7 @@ 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 -You must use a single OIDC provider per EKS Anywhere cluster, which is the best practice to prevent a token from one cluster being useable with the API server of another cluster. These steps describe the process of using an S3 bucket to host the OIDC discovery 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. +You must use a single OIDC provider per EKS Anywhere cluster, which is the best practice to prevent a token from one cluster being useable with the API server of another cluster. These steps describe the process of using an 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`. From 77f0ccee81de3b46145c0ff110f454523d2293f1 Mon Sep 17 00:00:00 2001 From: Chris Splinter Date: Mon, 11 Sep 2023 12:49:49 -0500 Subject: [PATCH 4/4] Update docs/content/en/docs/getting-started/optional/irsa.md Co-authored-by: Mitali Paygude --- docs/content/en/docs/getting-started/optional/irsa.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/content/en/docs/getting-started/optional/irsa.md b/docs/content/en/docs/getting-started/optional/irsa.md index 87092cbf039c..0ae99b099707 100644 --- a/docs/content/en/docs/getting-started/optional/irsa.md +++ b/docs/content/en/docs/getting-started/optional/irsa.md @@ -16,7 +16,7 @@ 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 -You must use a single OIDC provider per EKS Anywhere cluster, which is the best practice to prevent a token from one cluster being useable with the API server of another cluster. These steps describe the process of using an 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. +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`.