-
Notifications
You must be signed in to change notification settings - Fork 53
Authorization Mode and RBAC
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.
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
(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