3 ms·
In priority, 1. Stop using API keys. Configure SSO integration for developers and OIDC for automation. For example, this is very easy to setup with AWS. 2. If
by ali_piccioni 2y ago
In priority,
1. Stop using API keys. Configure SSO integration for developers and OIDC for automation. For example, this is very easy to setup with AWS.
2. If the above is not possible, then store credentials encrypted at rest. Decrypt them only at runtime. For example, SOPS to store encrypted credentials into the repo, then AWS KMS holds the decryption key. The SOPS Readme is very helpful.
- FooBarWidget 2y agoLet's say you're not on a major public cloud. Let's say you're on Hetzner How do you setup something like OIDC for workloads (workload identity)?
- mdaniel 2y agoI was curious about this and went sniffing around and it seems that their instance metadata[1] doesn't include anything that demonstrably associates the instance with Hetzner nor your specific account, making chain of custody ... tricky. The best work-around I could come up with (not having a Hetzner account to actually kick the tires upon) is that you could inject a private key that you control into the instances via cloud-init (or volume attachment) and then sign any subsequent JWT using it. For sure it would not meet all threat models, but wouldn't be nothing either. I was hoping there was some chain of custody through Vault[2] but until Hetzner implements ANY IAM primitives, I'm guessing it's going to be a non-starter since the instances themselves do not have any identity 1: https://docs.hetzner.cloud/#server-metadata https://docs.hetzner.cloud/#server-metadata 2: https://github.com/hashicorp/vault/blob/v1.14.7/website/content/docs/auth/index.mdx https://github.com/hashicorp/vault/blob/v1.14.7/website/cont...