Comment by cassianoleal
5 days ago
It probably doesn't. Google Secrets Manager is a cloud API. This runs in Kubernetes and sits between a Kubernetes Secret object and the application calling for it.
Generally speaking, if you're running Kubernetes in GCP (likely via GKE), and you control how your applications retrieve their secrets, you're likely better off with a combination of Workload Identity Federation, tight IAM to Secrets Manager, and a smart secrets retrieval strategy which likely involves lazy loading secrets and attempting a reload in case of a permission denied so it can deal with secrets rotation.
For applications where that's not an option, the state-of-the-art has been ensuring etcd is actually encrypted (as opposed to the default Base64), and relying on Kubernetes Secrets, usually either mounted in the filesystem or passed to environment variables.
Both these approaches have weaknesses since they're immediately available to all processes in the container.
OP seems to solve that by never exposing the secrets to the application, by sitting between the application and the service and replacing the secret on the wire, outside of the application's reach.
That's right, OP is the main maintainer and the idea he has is that nothing should change in the application. The application believe it has the secret, but the secret is injected on the wire AND only for the intended destination.
Please have a look at the demo if you can ; there is a webhook that abstract changing the secret resource name for you. You just "annotate" the secret resource and kloak admission controller will rewrite secrets of your deployment resource for you after that. This means the app never actually see the secret (accidental or not).
Interesting, thanks! I've also forwarded this to our security principal so we can evaluate it.