docs: Added examples for alternate EKS cluster authentication methods (…

…#17270) * Added examples for alternate EKS cluster authentication methods Signed-off-by: Damon Edstrom <[email protected]> * Update docs/operator-manual/declarative-setup.md Signed-off-by: Dan Garfield <[email protected]> Signed-off-by: Dan Garfield <[email protected]> --------- Signed-off-by: Dan Garfield <[email protected]> Co-authored-by: Dan Garfield <[email protected]>
argoproj · May 21, 2024 · 124f80b · 124f80b
1 parent da9e8cb
commit 124f80b
Showing 1 changed file with 134 additions and 0 deletions.
diff --git a/docs/operator-manual/declarative-setup.md b/docs/operator-manual/declarative-setup.md
@@ -732,6 +732,140 @@ data:
       "rolearn": "<arn:aws:iam::<AWS_ACCOUNT_ID>:role/<IAM_ROLE_NAME>"
       "username": "<some-username>"
 ```
+
+#### Alternative EKS Authentication Methods
+In some scenarios it may not be possible to use IRSA, such as when the Argo CD cluster is running on a different cloud
+provider's platform. In this case, there are two options:
+1. Use `execProviderConfig` to call the AWS authentication mechanism which enables the injection of environment variables to supply credentials
+2. Leverage the new AWS profile option available in Argo CD release 2.10
+
+Both of these options will require the steps involving IAM and the `aws-auth` config map (defined above) to provide the 
+principal with access to the cluster.
+
+##### Using execProviderConfig with Environment Variables
+```yaml
+---
+apiVersion: v1
+kind: Secret
+metadata:
+  name: mycluster-secret
+  labels:
+    argocd.argoproj.io/secret-type: cluster
+type: Opaque
+stringData:
+  name: mycluster
+  server: https://mycluster.example.com
+  namespaces: "my,managed,namespaces"
+  clusterResources: "true"
+  config: |
+    {
+      "execProviderConfig": {
+        "command": "argocd-k8s-auth",
+        "args": ["aws", "--cluster-name", "my-eks-cluster"],
+        "apiVersion": "client.authentication.k8s.io/v1beta1",
+        "env": {
+          "AWS_REGION": "xx-east-1",
+          "AWS_ACCESS_KEY_ID": "{{ .aws_key_id }}",
+          "AWS_SECRET_ACCESS_KEY": "{{ .aws_key_secret }}",
+          "AWS_SESSION_TOKEN": "{{ .aws_token }}"
+        }
+      },
+      "tlsClientConfig": {
+        "insecure": false,
+        "caData": "{{ .cluster_cert }}"
+      }
+    }
+```
+
+This example assumes that the role being attached to the credentials that have been supplied, if this is not the case
+the role can be appended to the `args` section like so:
+
+```yaml
+...
+    "args": ["aws", "--cluster-name", "my-eks-cluster", "--roleARN", "arn:aws:iam::<AWS_ACCOUNT_ID>:role/<IAM_ROLE_NAME>"],
+...
+```
+This construct can be used in conjunction with something like the External Secrets Operator to avoid storing the keys in
+plain text and additionally helps to provide a foundation for key rotation.
+
+##### Using An AWS Profile For Authentication
+The option to use profiles, added in release 2.10, provides a method for supplying credentials while still using the
+standard Argo CD EKS cluster declaration with an additional command flag that points to an AWS credentials file:
+```yaml
+apiVersion: v1
+kind: Secret
+metadata:
+  name: mycluster-secret
+  labels:
+    argocd.argoproj.io/secret-type: cluster
+type: Opaque
+stringData:
+  name: "mycluster.com"
+  server: "https://mycluster.com"
+  config: |
+    {
+      "awsAuthConfig": {
+        "clusterName": "my-eks-cluster-name",
+        "roleARN": "arn:aws:iam::<AWS_ACCOUNT_ID>:role/<IAM_ROLE_NAME>",
+        "profile": "/mount/path/to/my-profile-file"
+      },
+      "tlsClientConfig": {
+        "insecure": false,
+        "caData": "<base64 encoded certificate>"
+      }        
+    }
+```
+This will instruct ArgoCD to read the file at the provided path and use the credentials defined within to authenticate to
+AWS. The profile must be mounted in order for this to work. For example, the following values can be defined in a Helm
+based ArgoCD deployment:
+
+```yaml
+controller:
+  extraVolumes:
+    - name: my-profile-volume
+      secret:
+        secretName: my-aws-profile
+        items:
+          - key: my-profile-file
+            path: my-profile-file
+  extraVolumeMounts:
+    - name: my-profile-mount
+      mountPath: /mount/path/to
+      readOnly: true
+
+server:
+  extraVolumes:
+    - name: my-profile-volume
+      secret:
+        secretName: my-aws-profile
+        items:
+          - key: my-profile-file
+            path: my-profile-file
+  extraVolumeMounts:
+    - name: my-profile-mount
+      mountPath: /mount/path/to
+      readOnly: true
+```
+
+Where the secret is defined as follows:
+```yaml
+apiVersion: v1
+kind: Secret
+metadata:
+  name: my-aws-profile
+type: Opaque
+stringData:
+  my-profile-file: |
+    [default]
+    region = <aws_region>
+    aws_access_key_id = <aws_access_key_id>
+    aws_secret_access_key = <aws_secret_access_key>
+    aws_session_token = <aws_session_token>
+```
+
+> ⚠️ Secret mounts are updated on an interval, not real time. If rotation is a requirement ensure the token lifetime outlives the mount update interval and the rotation process doesn't immediately invalidate the existing token
+
+
 ### GKE
 
 GKE cluster secret example using argocd-k8s-auth and [Workload Identity](https://cloud.google.com/kubernetes-engine/docs/how-to/workload-identity):