Making Helm 2 Secure and Scalable August 16th, 2018

Transcript

1. Making Helm 2 Secure and Scalable August 16th 2018
2. About Me My name is Rimantas Mocevicius, you can call me - Rimas Founder of Helm, Author of CoreOS Essentials book, CKA Earlier adopter of containers (Docker) in production in early 2014 Built PaaS in $bash to orchestrate containers on CoreOS clusters Senior Frogger Developer at Jfrog @rimusz
3. Kubernetes
4. What is Kubernetes? Greek for “Helmsman”; also the root of the words “governor” and “cybernetic” • Runs and manages containers • Inspired and informed by Google’s experiences and internal systems • Supports multiple cloud and bare-metal environments • Supports multiple container runtimes • 100% Open source, written in Go • Manages applications, not machines
5. kubelet UI kubelet CLI API users master nodes etcd kubelet scheduler controllers apiserver The 10,000 Foot View
6. Should be easy to… • Get up and running with common workloads • Define new workloads • Collaborate on workload definitions I have Kubernetes, now what?
7. Google Cloud Platform UI API Container Cluster As All You Really Care About is But it is not like that!!!
8. Kubernetes Package Manager https://helm.sh
9. Helm is the best way to find, share and use software built for Kubernetes Why Helm?
10. What is Helm? • Helm lets you and your team manage apps running on Kubernetes • Helm Charts let you define, install, and upgrade even the most complex Kubernetes application, e.g. take a look to Istio chart!
11. What is Helm?
12. What is Helm?
13. What is Helm? That's true and sounds very cool, right?
14. Helm v2 Since Helm v2, Helm got a server part called The Tiller Server which is an in-cluster server that interacts with the helm client, and interfaces with the Kubernetes API server: • Listening for incoming requests from the Helm client • Combining a chart and configuration to build a release • Installing charts into Kubernetes, and then tracking the subsequent release • Upgrading and uninstalling charts by interacting with Kubernetes Sounds as amazing setup, right?
16. In a nutshell, the client is responsible for managing charts, and the server is responsible for managing releases. It looks as a nice setup. Which of course works very well, but has some security issues, and the main one is that tiller runs in your Kubernetes cluster with full administrative rights - which is a risk is somebody gets unauthorised access to the cluster. If we bring multitenancy tiller setup e.g. tiller for each team then it gets even worse with TLS and etc issues. Helm v2
17. Install Helm v2 with RBAC support! Create a service account for Tiller: $ kubectl -n kube-system create sa tiller Create a cluster role binding for Tiller: $ kubectl create clusterrolebinding tiller-cluster-rule \ --clusterrole=cluster-admin \ --serviceaccount=kube-system:tiller Deploy Tiller to kube-system namespace: $ helm init --service-account tiller
19. “Workarounds” of Tiller security issues It became quite popular to use pipe helm template output to kubectl to avoid using tiller: • helm template chart-name > kube.yaml; kubectl create -f kube.yaml Using it instead of “helm install ...” it totally makes helm upgrades/rollback/releases history features absent.
20. Tillerless Helm v2 It looks like it is not so hard to have Tillerless Helm v2. So let me go to more details and explain how to make it work. Apparently is so easy to run helm and tiller on your workstation or in CI/CD pipelines without installing tiller to your Kubernetes cluster: $ export TILLER_NAMESPACE=my-team-namespace $ export HELM_HOST=localhost:44134 $ tiller --storage=secret [main] 2018/07/23 15:52:29 Starting Tiller v2.9.1 (tls=false) [main] 2018/07/23 15:52:29 GRPC listening on :44134 [main] 2018/07/23 15:52:29 Probes listening on :44135 [main] 2018/07/23 15:52:29 Storage driver is Secret [main] 2018/07/23 15:52:29 Max history per release is 0
22. Tillerless Helm security considerations Tillerless Helm v2 well aligns with Helm v3 security considerations: • Helm now runs with the ID and permissions of the Kubernetes UserAccount or ServiceAccount executing the commands. • RBAC can now be applied to each user • On-the-wire security is as secure as the cluster is configured to be (e.g. if KUBECONFIG is set up for mTLS, that's what used then) • Auditability is now a feature of the cluster, as each chart is "created by" the user who runs the request
23. Tillerless Helm cons Running Tillerless Helm v2 has one con: • Running e.g. multiple Tillerless Helm instances and doing release for the same app, they could end up using the same release version. • Use serial release approach e.g. in CI/CD systems to avoid release version issue to happen there • That will not be problem with Helm v3 as it will use different atomic commit approach
24. Tillerless Helm plugin So how to make it even easier to install? I have made a simple Helm plugin. It is easy to install as running: It has three simple commands start, stop and run the tiller.
25. Helm v3 • Tiller is gone, and there is only one functional component (helm) • Charts are updated with libraries, schematized values, and the ext directory • Helm will use a "lifecycle events" emitter/handler model • Helm has an embedded Lua engine for scripting some event handlers. Scripts are stored in charts • State is maintained with two types of object: Release and a release version Secret • Resources created by hooks will now be managed • For pull-based DevOps workflow, a new Helm Controller project is planned • Cross platform plugins in Lua that only have a runtime dependency on Helm • A complementary command to helm fetch to push packages to a repository
26. Questions?
27. Useful URLs • My blog post about Tillerless Helm v2 https://rimusz.net/tillerless-helm/ • Tillerless Helm v2 plugin https://github.com/rimusz/helm-tiller • Helm v3 https://github.com/helm/community/blob/master/helm-v3/000-helm-v3.md • How to convert Tiller ConfigMaps to Secrets https://github.com/dragonsmith/tiller-releases-converter
28. Thanks!