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

docs: Added examples for alternate EKS cluster authentication methods #17270

Merged
merged 3 commits into from
Feb 22, 2024
Merged
Changes from 1 commit
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
134 changes: 134 additions & 0 deletions docs/operator-manual/declarative-setup.md
Original file line number Diff line number Diff line change
Expand Up @@ -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
todaywasawesome marked this conversation as resolved.
Show resolved Hide resolved
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):
Expand Down
Loading