Phippy Goes to the Zoo
cncf.io
cncf.io
If an adult (or a kid, for that matter) wants to really learn about Kubernetes, its inner workings etc, there's plenty of documentation and literature available which does explain how Pods are scheduled, what Services are and how they're implemented, etc.
Umm. I hope this is because the author of the slides doesn't understand even the basics of encryption and used the wrong words. If they are actually using base64 encoding in place of crypto that would not be good.
Even if it is a mistake and secrets genuinely are encrypted this sort of thing can be harmful, as others may look at this and get the (very wrong) idea that somehow base64 encoding is sufficient to store sensitive data.
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...
I suspect that it doesn't really matter to users at all what form of encoding you use to store data.
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/
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 ;)
(Disclosure: I'm executive director of CNCF and helped arrange the donation and relicensing.)
Unfortunately, this is really annoying to read on mobile as the unhideable “share” widget fixed to the right side obscures the text, so I have to either have the text at the top or the bottom of the screen. This is on an iPhone X in portrait mode.