This actually achieves neither of the 2 objectives I think it's meant to achieve:
Kids will go, "what on earth are you talking about", or enjoy it as a pointless story and
Adults who try to understand kubernetes will go, why is this talking down to me? How do the meerkats keep the pods up, how do the fish talk to the pods, how does the vultures talk to the fish?
You assume it's meant to explain K8s to kids, or teach adults about it. I don't believe it's either, more of a gimmick for the existing Kubernetes community.
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.
I think the objective (at least of the printed version) is for Microsoft to have something unusual to hand out at their conference booths that will drive traffic to them.
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.
'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:
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.
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
Yes, and Microsoft donated the characters and both books to CNCF, which relicensed them all CC-BY. More info and links to HTML, PDF, and source of the books at https://phippy.io.
(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.
21 comments
[ 2.8 ms ] story [ 67.9 ms ] threadIf 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.