Skip to content

Authorization Mode and RBAC

Mike Wilson edited this page Aug 13, 2018 · 4 revisions

Lots of work has gone into the 1.8 release of CDK towards enabling Kubernetes admin to switch between authorisation modes and enabling Role-Based Access Control (RBAC). We have introduced a new Juju configuration parameter with which you can select the authorisation mode used by your infrastructure. The new config variable is authorization-mode and is available through kubernetes-master by:

juju config kubernetes-master authorization-mode=<Your_Desired_mode>

The allowed values map directly to the authorization modules available in Kubernetes (https://kubernetes.io/docs/admin/authorization/#authorization-modules). You should provide a comma separated list of any of the following "RBAC", "Node", "Webhook", "ABAC", "AlwaysDeny" and "AlwaysAllow".

By default a new Kubernetes cluster will come up with the "AlwaysAllow" mode. This ensures maximum compatibility with what you already know about Kubernetes as this is the mode used by CDK so far.

We recommend you always enable "Node" authorization mode. As described in https://kubernetes.io/docs/admin/authorization/node/ this special-purpose mode specifically authorizes API requests made by kubelets. This mode ensures kubelets have the minimal set of permissions required to operate correctly. Under the hood CDK will enable 'NodeRestriction' and will issue (and decommision) tokens for kubernetes-workers as you scale your infrastructure.

In this release special care has gone in to the RBAC authorization mode (https://kubernetes.io/docs/admin/authorization/rbac/). This mode expects respective roles and bindings to be available for any running services. The approach we have taken for frictionless RBAC is to have all roles and bindings already created for you so that the only action you need to take is to select RBAC as one of the authorization-modes. When RBAC is not selected the roles continue to exist without having any effect.

Lets see some action.

Deploy a cluster and get the kubeconfig:

> juju deploy cs:~containers/bundle/canonical-kubernetes
> juju scp kubernetes-master/0:config ~/.kube/

If you look at the 'authorization-mode' command line param you will see it is initially set to "AlwaysAllow"

> juju run --unit kubernetes-master/0 "ps -ef | grep apiserver"
root      2177  2175  0 11:09 ?        00:00:00 grep apiserver
root     28921     1  2 10:52 ?        00:00:30 /snap/kube-apiserver/200/kube-apiserver --admission-control Initializers,NamespaceLifecycle,LimitRanger,ServiceAccount,ResourceQuota,DefaultTolerationSeconds --allow-privileged=false --authorization-mode AlwaysAllow --basic-auth-file /root/cdk/basic_auth.csv --etcd-cafile /root/cdk/etcd/client-ca.pem --etcd-certfile /root/cdk/etcd/client-cert.pem --etcd-keyfile /root/cdk/etcd/client-key.pem --etcd-servers https://172.31.0.159:2379,https://172.31.23.99:2379,https://172.31.59.6:2379 --insecure-bind-address 127.0.0.1 --insecure-port 8080 --kubelet-certificate-authority /root/cdk/ca.crt --kubelet-client-certificate /root/cdk/client.crt --kubelet-client-key /root/cdk/client.key --logtostderr --min-request-timeout 300 --service-account-key-file /root/cdk/serviceaccount.key --service-cluster-ip-range 10.152.183.0/24 --storage-backend etcd2 --tls-cert-file /root/cdk/server.crt --tls-private-key-file /root/cdk/server.key --token-auth-file /root/cdk/known_tokens.csv --v 4

Changing the mode to "RBAC,Node" is reflected to both authorization-mode and admission-control parameters.

> juju config kubernetes-master authorization-mode="RBAC,Node"
> juju run --unit kubernetes-master/0 "ps -ef | grep apiserver"
root      4398     1 44 11:16 ?        00:00:12 /snap/kube-apiserver/200/kube-apiserver --admission-control Initializers,NamespaceLifecycle,LimitRanger,ServiceAccount,ResourceQuota,DefaultTolerationSeconds,NodeRestriction --allow-privileged=false --authorization-mode RBAC,Node --basic-auth-file /root/cdk/basic_auth.csv --etcd-cafile /root/cdk/etcd/client-ca.pem --etcd-certfile /root/cdk/etcd/client-cert.pem --etcd-keyfile /root/cdk/etcd/client-key.pem --etcd-servers https://172.31.0.159:2379,https://172.31.23.99:2379,https://172.31.59.6:2379 --insecure-bind-address 127.0.0.1 --insecure-port 8080 --kubelet-certificate-authority /root/cdk/ca.crt --kubelet-client-certificate /root/cdk/client.crt --kubelet-client-key /root/cdk/client.key --logtostderr --min-request-timeout 300 --service-account-key-file /root/cdk/serviceaccount.key --service-cluster-ip-range 10.152.183.0/24 --storage-backend etcd2 --tls-cert-file /root/cdk/server.crt --tls-private-key-file /root/cdk/server.key --token-auth-file /root/cdk/known_tokens.csv --v 4
root      4786  4784  0 11:16 ?        00:00:00 grep apiserver

And here are the roles we have already set for you:

> kubectl --kubeconfig ~/.kube/config get roles --all-namespaces
NAMESPACE     NAME                 AGE
default       nginx-ingress-role   20m
kube-system   system:pod-nanny     21m
> kubectl --kubeconfig ~/.kube/config get clusterroles --all-namespaces
NAMESPACE   NAME                        AGE
            nginx-ingress-clusterrole   20m

User management

(We intend to add charm actions for managing users, but until then, the process is entirely manual.)

To add a user you will need to edit the /root/cdk/basic_auth.csv. Note that the format for this file is password,user,uid,"group1,group2,group3".

> juju ssh kubernetes-master/0
$ sudo nano /root/cdk/basic_auth.csv

And restart the master

> juju run-action kubernetes-master/0 restart

Afer that you can create a kubeconfig file based on the config you already have for the master under ~/.kube/config