container.training/slides/k8s/dashboard.md

The Kubernetes dashboard

• Kubernetes resources can also be viewed with a web dashboard

• Dashboard users need to authenticate

  (typically with a token)

• The dashboard should be exposed over HTTPS

  (to prevent interception of the aforementioned token)

• Ideally, this requires obtaining a proper TLS certificate

  (for instance, with Let's Encrypt)

---

Three ways to install the dashboard

• Our k8s directory has no less than three manifests!

• dashboard-recommended.yaml

  (purely internal dashboard; user must be created manually)

• dashboard-with-token.yaml

  (dashboard exposed with NodePort; creates an admin user for us)

• dashboard-insecure.yaml aka YOLO

  (dashboard exposed over HTTP; gives root access to anonymous users)

---

dashboard-insecure.yaml

• This will allow anyone to deploy anything on your cluster

  (without any authentication whatsoever)

• Do not use this, except maybe on a local cluster

  (or a cluster that you will destroy a few minutes later)

• On "normal" clusters, use dashboard-with-token.yaml instead!

---

What's in the manifest?

• The dashboard itself

• An HTTP/HTTPS unwrapper (using socat)

• The guest/admin account

.lab[

• Create all the dashboard resources, with the following command:

  kubectl apply -f ~/container.training/k8s/dashboard-insecure.yaml
  

]

---

Connecting to the dashboard

.lab[

• Check which port the dashboard is on:

  kubectl get svc dashboard
  

]

You'll want the 3xxxx port.

.lab[

• Connect to http://oneofournodes:3xxxx/

]

The dashboard will then ask you which authentication you want to use.

---

Dashboard authentication

• We have three authentication options at this point:

  • token (associated with a role that has appropriate permissions)

  • kubeconfig (e.g. using the ~/.kube/config file from node1)

  • "skip" (use the dashboard "service account")

• Let's use "skip": we're logged in!

--

.warning[Remember, we just added a backdoor to our Kubernetes cluster!]

---

Closing the backdoor

• Seriously, don't leave that thing running!

.lab[

• Remove what we just created:

    kubectl delete -f ~/container.training/k8s/dashboard-insecure.yaml
  

]

---

The risks

• The steps that we just showed you are for educational purposes only!

• If you do that on your production cluster, people can and will abuse it

• For an in-depth discussion about securing the dashboard,
  check this excellent post on Heptio's blog

---

dashboard-with-token.yaml

• This is a less risky way to deploy the dashboard

• It's not completely secure, either:

  • we're using a self-signed certificate

  • this is subject to eavesdropping attacks

• Using kubectl port-forward or kubectl proxy is even better

---

What's in the manifest?

• The dashboard itself (but exposed with a NodePort)

• A ServiceAccount with cluster-admin privileges

  (named kubernetes-dashboard:cluster-admin)

.lab[

• Create all the dashboard resources, with the following command:

  kubectl apply -f ~/container.training/k8s/dashboard-with-token.yaml
  

]

---

Obtaining the token

• The manifest creates a ServiceAccount

• Kubernetes will automatically generate a token for that ServiceAccount

.lab[

• Display the token:

    kubectl --namespace=kubernetes-dashboard \
      describe secret cluster-admin-token
  

]

The token should start with eyJ... (it's a JSON Web Token).

Note that the secret name will actually be cluster-admin-token-xxxxx.
(But kubectl prefix matches are great!)

---

Connecting to the dashboard

.lab[

• Check which port the dashboard is on:

  kubectl get svc --namespace=kubernetes-dashboard
  

]

You'll want the 3xxxx port.

.lab[

• Connect to http://oneofournodes:3xxxx/

]

The dashboard will then ask you which authentication you want to use.

---

Dashboard authentication

• Select "token" authentication

• Copy paste the token (starting with eyJ...) obtained earlier

• We're logged in!

---

Other dashboards

• Kube Web View

  • read-only dashboard

  • optimized for "troubleshooting and incident response"

  • see vision and goals for details

• Kube Ops View

  • "provides a common operational picture for multiple Kubernetes clusters"

---

Security implications of kubectl apply

• When we do kubectl apply -f <URL>, we create arbitrary resources

• Resources can be evil; imagine a deployment that ...

--

• starts bitcoin miners on the whole cluster

--

• hides in a non-default namespace

--

• bind-mounts our nodes' filesystem

--

• inserts SSH keys in the root account (on the node)

--

• encrypts our data and ransoms it

--

• ☠️☠️☠️

---

kubectl apply is the new curl | sh

• curl | sh is convenient

• It's safe if you use HTTPS URLs from trusted sources

--

• kubectl apply -f is convenient

• It's safe if you use HTTPS URLs from trusted sources

• Example: the official setup instructions for most pod networks

--

• It introduces new failure modes

  (for instance, if you try to apply YAML from a link that's no longer valid)

???

:EN:- The Kubernetes dashboard :FR:- Le dashboard Kubernetes