Fix complicated and insecure adot installation docs

Author: snarkychef

docs/content/en/docs/getting-started/optional/irsa.md

@@ -14,7 +14,11 @@ IAM Roles for Service Account (IRSA) enables applications running in clusters to
 
 The steps below are based on the [guide for configuring IRSA for DIY Kubernetes,](https://github.com/aws/amazon-eks-pod-identity-webhook/blob/master/SELF_HOSTED_SETUP.md) with modifications specific to EKS Anywhere's cluster provisioning workflow. The main modification is the process of generating the keys.json document. As per the original guide, the user has to create the service account signing keys, and then use that to create the keys.json document prior to cluster creation. This order is reversed for EKS Anywhere clusters, so you will create the cluster first, and then retrieve the service account signing key generated by the cluster, and use it to create the keys.json document. The sections below show how to do this in detail.
 
-### Create an OIDC provider and make its discovery document publicly accessible
+### Set up cluster-wide IRSA infrastructure
+
+This section covers the one-time setup required for IRSA on your EKS Anywhere cluster. Complete these steps once per cluster.
+
+#### 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 used with another cluster. These steps describe the process of using a S3 bucket to host the OIDC `discovery.json` and `keys.json` documents.
 
@@ -54,11 +58,15 @@ You must use a single OIDC provider per EKS Anywhere cluster, which is the best
 
 1. Make a note of the `Provider` field of OIDC provider after it is created.
 
-1. Assign an IAM role to the OIDC provider.
+### Create IAM role for your workload
+
+Each workload (such as ADOT, cert-manager, or custom applications) should have its own dedicated IAM role with only the permissions it needs. Repeat this section for each workload that requires AWS access.
+
+1. Create an IAM role for your workload:
 
     1. Navigate to the AWS IAM Console.
 
-	1. Click on the OIDC provider.
+	1. Click on the OIDC provider created in the previous section.
 
     1. Click _Assign role_.
 
@@ -73,10 +81,10 @@ You must use a single OIDC provider per EKS Anywhere cluster, which is the best
 
 	1. Click _Next_.
 
-	1. Configure your desired _Permissions poilicies_.
+	1. Configure _Permissions policies_ specific to this workload's requirements.
 
-	1. Below is a sample trust policy of IAM role for your pods. Replace `ACCOUNT_ID`, `ISSUER_HOSTPATH`, `NAMESPACE` and `SERVICE_ACCOUNT`.
-        _Example: Scoped to a service account_
+	1. Below is a sample trust policy for a single workload. Replace `ACCOUNT_ID`, `ISSUER_HOSTPATH`, `NAMESPACE` and `SERVICE_ACCOUNT` with values specific to this workload.
+        _Example: Scoped to a single service account_
         ```json
         {
             "Version": "2012-10-17",
@@ -90,7 +98,7 @@ You must use a single OIDC provider per EKS Anywhere cluster, which is the best
                     "Condition": {
                         "StringEquals": {
                             "ISSUER_HOSTPATH:sub": "system:serviceaccount:NAMESPACE:SERVICE_ACCOUNT"
-                        },
+                        }
                     }
                 }
             ]
@@ -99,7 +107,7 @@ You must use a single OIDC provider per EKS Anywhere cluster, which is the best
 
 	1. Create the IAM Role and make a note of the _Role name_.
 
-	1. After the cluster is created you can grant service accounts access to the role by modifying the trust relationship. See the [How to use trust policies with IAM Roles](https://aws.amazon.com/blogs/security/how-to-use-trust-policies-with-iam-roles/) for more information on trust policies. Refer to [Configure the trust relationship for the OIDC provider's IAM Role](#configure-the-trust-relationship-for-the-oidc-providers-iam-role) for a working example.
+	1. See the [How to use trust policies with IAM Roles](https://aws.amazon.com/blogs/security/how-to-use-trust-policies-with-iam-roles/) for more information on trust policies. For advanced trust relationship configurations, refer to [Configure the trust relationship for the IAM role](#configure-the-trust-relationship-for-the-iam-role).
 
 ### Create (or upgrade) the EKS Anywhere cluster
 
@@ -197,24 +205,39 @@ The [Amazon Pod Identity Webhook](https://github.com/aws/amazon-eks-pod-identity
 1. You can validate IRSA by following [IRSA setup and test]({{< relref "../../packages/adot/adot_amp_amg/#irsa-set-up-test" >}}). Ensure the awscli pod is deployed in the same namespace of ServiceAccount `pod-identity-webhook`.
 
 
-### Configure the trust relationship for the OIDC provider's IAM Role
+### Configure the trust relationship for the IAM role
 
-In order to grant certain service accounts access to the desired AWS resources, edit the trust relationship for the OIDC provider's IAM Role (`OIDC_IAM_ROLE`) created in the first section, and add in the desired service accounts.
+This section provides advanced examples for configuring trust relationships. The basic single-ServiceAccount pattern shown above is recommended for most use cases.
 
 1. Choose the role in the console to open it for editing.
 
 1. Choose the **Trust relationships** tab, and then choose **Edit trust relationship**.
 
-1. Find the line that looks similar to the following:
-    ```
-    "$ISSUER_HOSTPATH:aud": "sts.amazonaws.com"
-    ```
+1. Find the existing trust policy condition.
 
-1. Add another condition after that line which looks like the following line. Replace `KUBERNETES_SERVICE_ACCOUNT_NAMESPACE` and `KUBERNETES_SERVICE_ACCOUNT_NAME` with the name of your Kubernetes service account and the Kubernetes namespace that the account exists in.
-    ```
-    "$ISSUER_HOSTPATH:sub": "system:serviceaccount:KUBERNETES_SERVICE_ACCOUNT_NAMESPACE:KUBERNETES_SERVICE_ACCOUNT_NAME"
+1. **Single ServiceAccount pattern (recommended):** For most workloads, use a single ServiceAccount:
+    ```json
+    {
+        "Version": "2012-10-17",
+        "Statement": [
+            {
+                "Effect": "Allow",
+                "Principal": {
+                    "Federated": "arn:aws:iam::$Account_ID:oidc-provider/s3.us-west-2.amazonaws.com/$S3_BUCKET"
+                },
+                "Action": "sts:AssumeRoleWithWebIdentity",
+                "Condition": {
+                    "StringEquals": {
+                        "s3.us-west-2.amazonaws.com/$S3_BUCKET:aud": "sts.amazonaws.com",
+                        "s3.us-west-2.amazonaws.com/$S3_BUCKET:sub": "system:serviceaccount:default:my-serviceaccount"
+                    }
+                }
+            }
+        ]
+    }
     ```
-    The allow list example below applies `my-serviceaccount` service account to the `default` namespace and all service accounts to the `observability` namespace for the `us-west-2` region. Remember to replace `Account_ID` and `S3_BUCKET` with the required values.
+
+1. **Multiple ServiceAccounts pattern (use sparingly):** Only use arrays when the same workload runs in multiple namespaces (e.g., dev/staging/prod environments):
     ```json
     {
         "Version": "2012-10-17",
@@ -226,19 +249,22 @@ In order to grant certain service accounts access to the desired AWS resources,
                 },
                 "Action": "sts:AssumeRoleWithWebIdentity",
                 "Condition": {
-                    "StringLike": {
+                    "StringEquals": {
                         "s3.us-west-2.amazonaws.com/$S3_BUCKET:aud": "sts.amazonaws.com",
                         "s3.us-west-2.amazonaws.com/$S3_BUCKET:sub": [
-                                "system:serviceaccount:default:my-serviceaccount",
-                                "system:serviceaccount:amazon-cloudwatch:*"
-                            ]
-                        }
+                            "system:serviceaccount:dev:my-app",
+                            "system:serviceaccount:staging:my-app",
+                            "system:serviceaccount:prod:my-app"
+                        ]
                     }
                 }
-            ]
-        }
+            }
+        ]
+    }
     ```
 
+    **Important:** Do not share IAM roles across unrelated workloads. Each workload should have its own IAM role with only the permissions it needs.
+
 
 
 1. Refer [this](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition_operators.html) doc for different ways of configuring one or multiple service accounts through the condition operators in the trust relationship.