▲ | doesnt_know 6 days ago | ||||||||||||||||||||||
If it’s not a secret that is used to sign something, then the secret has to get from the vault to the application at some point. What mechanism are you suggesting where access to the production system doesn’t let you also access that secret? Like I get in this specific case where you are running some untrusted code, that environment should have been isolated and these keys not passed in, but running untrusted code isn’t usually a common feature of most applications. | |||||||||||||||||||||||
▲ | Nextgrid 6 days ago | parent | next [-] | ||||||||||||||||||||||
If you actually have a business case for defense in depth (hint: nobody does - data breaches aren't actually an issue besides temporarily pissing off some nerds, as Equifax' and various companies stock prices demonstrate), what you'd do is have a proxy service who is entrusted with those keys and can do the operations on behalf of downstream services. It can be as simple as an HTTP proxy that just slaps the "Authorization" header on the requests (and ideally whitelists the URL so someone can't point it to https://httpbin.org/get and get the secret token echoed back). This would make it so that even a compromised downstream service wouldn't actually be able to exfiltrate the authentication token, and all its misdeeds would be logged by the proxy service, making post-incident remediation easier (and being able to definitely prove whether anything bad has actually happened). | |||||||||||||||||||||||
| |||||||||||||||||||||||
▲ | morgante 6 days ago | parent | prev [-] | ||||||||||||||||||||||
A pretty straightforward solution is to have an isolated service that keeps the private key and hands back the temporary per-repo tokens for other libraries to use. Only this isolated service has access to the root key, and it should have fairly strict rate limiting for how often it gives other services temporary keys. |