From 8e5e44a5e9ac7e1fb09f5dedcffb32e0905ab6d4 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 0c709ca01b66..640c80577440 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 9fbd88427699263dd58a7e21608d3a4d9dafd505 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 640c80577440..8b872f9c192b 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 681951301b0a0607c61ec4b29a7ab8591d1ff6b9 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 8b872f9c192b..73948491c7b1 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 3e809e30dd788158c5a84e87d9d7801e7a2ca969 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 73948491c7b1..d3661b72e3d3 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`.