etok icon indicating copy to clipboard operation
etok copied to clipboard

AWS Credentials

Open zmarouf opened this issue 4 years ago • 2 comments

In the Readme you specify

Etok looks for credentials in a secret named etok. If found, the credentials contained within are made available to terraform as environment variables.

AWS has IRSA to avoid rotating credentials https://docs.aws.amazon.com/eks/latest/userguide/iam-roles-for-service-accounts.html

Is the Etok KSA assigned to the run Pods? If yes then in theory, if etok used the aws sdk IRSA should work out of the box.

What are your thoughts on this?

zmarouf avatar Feb 01 '21 05:02 zmarouf

Hello @zmarouf, yes, IRSA will almost certainly work.

Does IRSA require an EKS cluster? If so, would you be willing to test etok and IRSA on an EKS cluster? I currently only have access to a GKE cluster (and a Kind cluster on my laptop).

I've documented Workload Identity on GKE in the Readme - Workload Identity is the GCP equivalent of IRSA, and it works very similarly, i.e. set an annotation on a KSA.

Maybe it's not clear in the Readme, etok has at least two KSAs:

(a) The operator's KSA, etok/etok. You give the operator privileges in order to back up the terraform state to a cloud bucket. (b) A KSA named etok in each namespace where you create a workspace. So if you run etok workspace new --namespace=dev foo, that creates the KSA dev/etok. And that KSA is assigned to its run pods.

Currently the operator in (a) only supports the backup of state to GCS, so we need a PR to update the operator to support backups to S3 as well. Only then will it make sense to enable IRSA on the operator KSA.

But for (b), IRSA should work straight away, because the terraform aws provider supports IRSA.

So please try this out and let me know if it works ok and we can update the Readme.

If you need any further help with this, feel free to talk to me in the slack channel.

leg100 avatar Feb 01 '21 09:02 leg100

S3 persistence/backup: #88

leg100 avatar Feb 01 '21 09:02 leg100