Support aws auth with already set environment variables

[consideRatio]

I'm going AWS native with AWS for KMS, ECR, and EKS.

By doing so, I use the environment variables AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY to use SOPS. But of course I could use these directly for ECR as well (assuming ~/.docker/config.json is configured for me), and EKS access also (assuming aws eks update-kubeconfig is called).

Currently though, if I specify aws.service_key in hubploy, I end up using SOPS to decrypt the same key already used. I ended up creating a AWS Role to assume so I can use role_arn to take on that role with permissions ^^.

I suggest we support omitting both service_key and role_arn by inspecting these AWS environment variables as well, and if they exist we try to use them directly.

[yuvipanda]

Hello @consideRatio!

One of the things I've wanted to do is to keep the deployment repository 'self-contained' - that all you need to deploy is the decryption key (sops or otherwise), and all other credentials are inside. This way, you can control access via the KMS key (or git-crypt key elsewhere), without having to give users individual access. By setting up the role arn, you can also give the deployed user the minimum required privileges, and rotate that as needed without relying on external factors like env keys setup.

I hope this makes sense?

[consideRatio]

Hi @yuvipanda! :)

Ah I see your point, but would you agree that current role_arn implementation currently require us to provide credentials directly that are beyond the KMS credentials?

https://github.com/yuvipanda/hubploy/blob/406508144f45044d547fb643e6a6edc44f62d9f7/hubploy%2Fauth.py#L123-L141

I'm reading this like:

1. We arrive to the above code if role_ref was specified.
2. We make use of the environment variables or credentials on disk to work with boto3, the aws cli for python, to assume the role.

[yuvipanda]

Ah yes, that's correct. The idea there is that you'd mostly run this from an EC2 instance that can assume that role, or have set AWS_* env vars that can assume that role. I had totally forgotten about this, and yeah this violates the rule around being self-contained :| Ideally I'd like to not have this, but unfortunately there are cases when policy prohibits generating ACCESS_SECRETs, and only roles can be used. See https://github.com/yuvipanda/aws-codecommit-secret for how I had set up to use this.

So in the local deployment case, this means you either:

1. Need to create an AWS IAM user, and put their creds encrypted with sops in the repo
2. Create a role with appropriate permissions, and somehow be able to already assume that role (via env vars / config file as a user, but ideally as an EC2 instance)

If doing (2), your EC2 instance (or user) only needs to have permissions to assume that role, and nothing else.

I'll admit I had totally forgotten about this :|

[consideRatio]

Thanks for the confirmation! I think I understand what you aim for quite well now so hopefully I can contribute moving this repo towards that direction. Thank you for your work on this project @yuvipanda ❤️ 🎉

I'll not close this issue yet as I hope we can make it lead to some documentation or similar at least.