From 7b9b9f527d9d6392683abfaea2ea595e3b6ce2e2 Mon Sep 17 00:00:00 2001 From: Jerome Petazzoni Date: Wed, 5 Dec 2018 18:31:12 -0600 Subject: [PATCH] Explain system:masters Add a couple of extra-details slides showing how our client certificate gives us all the privileges on the cluster (through the system:masters group). --- slides/k8s/authn-authz.md | 44 +++++++++++++++++++++++++++++++++++++++ 1 file changed, 44 insertions(+) diff --git a/slides/k8s/authn-authz.md b/slides/k8s/authn-authz.md index def0212f..e93b9d62 100644 --- a/slides/k8s/authn-authz.md +++ b/slides/k8s/authn-authz.md @@ -133,6 +133,8 @@ class: extra-details → We are user `kubernetes-admin`, in group `system:masters`. +(We will see later how and why this gives us the permissions that we have.) + --- ## User certificates in practice @@ -567,3 +569,45 @@ It's important to note a couple of details in these flags ... kubectl auth can-i list nodes \ --as system:serviceaccount:: ``` + +--- + +class: extra-details + +## Where do our permissions come from? + +- When interacting with the Kubernetes API, we are using a client certificate + +- We saw previously that this client certificate contained: + + `CN=kubernetes-admin` and `O=system:masters` + +- Let's look for these in existing ClusterRoleBindings: + ```bash + kubectl get clusterrolebindings -o yaml | + grep -e kubernetes-admin -e system:masters + ``` + + (`system:masters` should show up, but not `kubernetes-admin`.) + +- Where does this match come from? + +--- + +class: extra-details + +## The `system:masters` group + +- If we eyeball the output of `kubectl get clusterrolebindings -o yaml`, we'll find out! + +- It is in the `cluster-admin` binding: + ```bash + kubectl describe clusterrolebinding cluster-admin + ``` + +- This binding associates `system:masters` to the cluster role `cluster-admin` + +- And the `cluster-admin` is, basically, `root`: + ```bash + kubectl describe clusterrole cluster-admin + ```