Hacker News Reader

Comment by nicolast | Hacker News Reader

'secrets are base64 encoded at rest' means exactly what it says: a secret value is encoded using base64 in the Secret object 'document' that's stored in etcd. It doesn't say anything about at-rest encryption, and the Kubernetes community is well aware base64 doesn't provide any such guarantees.

However, if you want at-rest encryption (of data stored in etcd), we got you covered, if wanted way beyond only encrypting Secret objects! Some pointers:

- https://kubernetes.io/docs/tasks/administer-cluster/encrypt-...

- https://kubernetes.io/docs/tasks/administer-cluster/kms-prov...

View on HN

Thanks! I'm not sure if you're involved in the Phippy project at all, but the way it's worded sounds to me a lot like the author believes that encoding == encryption, and I'd maybe consider just dropping that line entirely.

I suspect that it doesn't really matter to users at all what form of encoding you use to store data.

I'm not involved in the Phippy 'project' in any way (only got a copy of the books and some plastic version of the animals as a speaker here at KubeCon :-D).

I agree the wording may be a bit 'off' and providing a detail which doesn't necessarily add value or can cause confusion, so that would've been good feedback before the whole thing went to 'print' :)

As for the end user who shouldn't know about encoding: that's not entirely true. Thing is, when sending a Secret object into the API (as YAML or JSON), you need to pre-encode the secret value using base64 in this document (so it's not K8s doing this for you, indeed another source of confusion given the current wording). The reason being that the API being YAML/JSON-based could otherwise not be used to store non-UTF8 secret values (e.g. binary ones).

However, if you use 'kubectl create secret' instead of interacting with the API directly (or using 'kubectl create -f ...' with a YAML document as input, which is also 'interacting with the API directly' with some extras) then I believe the CLI will take care of this encoding for you, where required.

See https://kubernetes.io/docs/concepts/configuration/secret/

I think if you consider the audience of this book might actually be 7 years old, it's fair to leave the line in.

Something something, "today's lucky 10,000" https://xkcd.com/1053/

The reason for the base64 encoding as I understand it, is so that it is clear whether and how the entry needs to be quoted and escaped in your yaml file. A base64 entry contains only alphanumeric(ish) characters. Writing Helm charts is about the hardest mandatory part of managing Kubernetes clusters, and understanding how your secrets are meant to enter the cluster is definitely part of that confusion.

It's an important detail, especially if you know what that means. You are right to ask about the hippo-headed giraffe, "wait, isn't there supposed to be something else here?"

There is! The seven or eight year old reader is not expected to get this on the first read-through though ;)

Since you seem to know a lot about this topic, can you outline what the main advantages are of using vault over standard kubernetes secrets? what are the main benefits or drawbacks I would see from using it?

The primary differentiators are likely the fact that encryption of those secrets is still fairly new for k8s, and vault has a much more rich way to define access to the secrets. Vault makes sense when it is more than just k8s you need to interact with

Reply on news.ycombinator.com