Is it me, or does it seem weird to encrypt your secrets by uploading the secret key to GCP (contained in the config .yaml file)? I assume the controller instances are operated by Google in this[1] example.

Moreover, is there any sensible way at all to encrypt secrets without baking the secret key into your image? I can’t think of any.

I want to deploy an app that makes use of one or more fairly important secrets, but I haven’t found a sensible way to make it auto-scale while keeping the secrets on-premise.

As far as I can see, the only sensible solution is to create in-cloud/off-premise secret keys that can only be accessed by images signed with an on-premise secret key.

So,

1. Create secret key on an offline, on-premise machine

2. Produce application image, transfer to offline machine, sign with on-premise secret key

3. Create off-premise (in-cloud) secret, which can only be accessed by images signed with the on-premise secret key

4. Upload app image and signature to the cloud, allowing only this image access to the in-cloud secret

[1] https://github.com/kelseyhightower/kubernetes-the-hard-way/b...

We are working on a solution to this problem in the Clevis project[0]. It is a basic FUSE filesystem that will transparently decrypt your secrets/configuration. It will evaluate your decryption policy on each open and log the attempt.

You can see the initial proof of concept[1]. It isn't secure yet, for a variety of reasons. But it is enough to play around with. Moving to a better encryption scheme will give us the ability to do locks and per-block validation.

[0]: https://github.com/latchset/clevis [1]: https://github.com/npmccallum/clevis/blob/fuse/src/clevis-fu...