|
|
|
|
|
by jfindley
2741 days ago
|
|
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 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/