Reverse Tiller and Dashboard documentation changes

Author: Luke Addison

docs/user-guide.rst

@@ -176,57 +176,6 @@ The current implementation will configure the first instance pool of type worker
 in your cluster configuration to scale between `minCount` and `maxCount`. We
 plan to add support for an arbitrary number of worker instance pools.
 
-Dashboard
-~~~~~~~~~
-
-Tarmak supports deploying `Kubernetes Dashboard
-<https://github.com/kubernetes/dashboard>`_ when spinning up a Kubernetes
-cluster. The following `tarmak.yaml` snippet shows how you would enable
-Kubernetes Dashboard. 
-
-.. code-block:: yaml
-
-    kubernetes:
-      dashboard:
-        enabled: true
-    ...
-
-The above configuration would deploy Kubernetes Dashboard with an image of
-`gcr.io/google_containers/kubernetes-dashboard-amd64` with a fixed tag. The
-configuration block accepts two optional fields of `image` and `version`
-allowing you to change these defaults. The `version` field directly translates
-to the image tag used.
-
-Tiller
-~~~~~~
-
-Tarmak supports deploying Tiller, the server-side component of `Helm
-<https://github.com/kubernetes/helm>`_, when spinning up a Kubernetes cluster.
-Tiller is configured to listen on localhost only which prevents arbitrary Pods
-in the cluster connecting to its unauthenticated endpoint. Helm clients can
-still talk to Tiller by port forwarding through the Kubernetes API Server. The
-following `tarmak.yaml` snippet shows how you would enable Tiller.
-
-.. code-block:: yaml
-
-    kubernetes:
-      tiller:
-        enabled: true
-    ...
-
-The above configuration would deploy Tiller with an image of
-`gcr.io/kubernetes-helm/tiller` with a fixed tag. The configuration block
-accepts two optional fields of `image` and `version` allowing you to change
-these defaults. The `version` field directly translates to the image tag used.
-The version is particularly important when deploying Tiller since its minor
-version must match the minor version of any Helm clients.
-
-.. warning::
-   Tiller is deployed with full ``cluster-admin`` ClusterRole bound to its
-   service account and has therefore has quiet far reaching privileges. Also
-   consider Helm's `security best practices
-   <https://github.com/kubernetes/helm/blob/master/docs/securing_installation.md>`_.
-
 Logging
 ~~~~~~~
 
@@ -413,6 +362,31 @@ certificate is valid for ``jenkins.<environment>.<zone>``.
       type: ssd
   ...
 
+Tiller
+~~~~~~
+
+Another configuration option allows to deploy Tiller the server-side of `Helm
+<https://github.com/kubernetes/helm>`_. Tiller is listening for request on the
+loopback device only. This makes sure that no other Pod in the cluster can
+speak to it, while Helm clients are still able to access it using a port
+forwarding through the API server.
+
+As Helm and Tiller minor version need to match, the tarmak configuration also
+allows to override the deployed version:
+
+.. code-block:: yaml
+
+  kubernetes:
+    tiller:
+      enabled: true
+      version: 2.9.1
+
+.. warning::
+   Tiller is deployed with full ``cluster-admin`` ClusterRole bound to its
+   service account and has therefore quiet far reaching privileges. Also
+   consider Helm's `security best practices
+   <https://github.com/kubernetes/helm/blob/master/docs/securing_installation.md>`_.
+
 Prometheus
 ~~~~~~~~~~