Hi all,
I've learned some things about Kubernetes and Helm while deploying a BinderHub and I think it would be great if they were made more explicit on the Setting up Helm page of the instructions.
Specifically:
The page opens with a nice explanation of the helm and tiller components. While Charts are mentioned, they are not delved into too deeply. I had a conversation with @betatim yesterday where he explained a chart as describing how packages are installed onto a k8s cluster and, when it's deployed, it works as a templating engine to populate multiple yaml files (e.g. populating a chart for each required package with the hostname) and a wraps the kubectl apply command to each of the required packages.
I would like to add a couple of sentences paraphrasing that at the top of the page for context. If I've misunderstood something, please let me know! 馃檪
helm and tillerI would like to add a sentence under this step which makes it explicit that this is the critical step to connecting helm commands executed in your local terminal with tiller on a remote k8s cluster. I think this can be quite conceptually difficult to wrap one's head around, especially when it's a Cloud cluster that you haven't ssh'd into (at least it was for me! 馃槵).
The linked blog post explaining the requirement for this patch is great, but a bit dense. I'd like to add a couple of sentences paraphrasing the blog post and then point to it as e.g. "more information here".
My suggested sentences are:
tillers port is exposed in the cluster without authentication and if you probe this port directly (i.e. by bypassinghelm) thentillers permissions can be exploited. This step forcestillerto listen to commands from localhost (i.e.helm) _only_ so that e.g. other pods inside the cluster cannot asktillerto install a new chart granting them arbitrary, elevated RBAC privileges and exploit them. More details here.
Please let me know if I've understood all of the above correctly and these are changes you'd be happy with. I'm happy to open a PR myself 馃檪
Thanks for this thoughtful treatment of the docs, and the suggestions to improve them!
I am in generally a huge +1 on any documentation improvements, and happy to iterate on a PR with you if you'd like to propose something. I think the biggest challenge we have is avoiding overloading the users with tons of information. I like that you're keeping the suggestions to "a few sentences to provide context and general information", and I think we should work hard to make it clear where people can go if they want to learn more about these things.
Want to open a PR and we can iterate there?
Thanks @choldgraf PR is #1180
@sgibson91 :tada: I'm too tired to process text right now but I realize that this is another excellent contribution of yours and wanted to drop a comment of appreciation for it! :heart: