Edit this page

Configuring authorisation and authentication

The Charmed Distribution of Kubernetes® implements access control based on the Kubernetes model. A complete overview of the Kubernetes authorisation system is given in the Kubernetes Documentation. This page provides summary information on the available modes and how to configure CDK to use them.

The following modes are supported:

  • AlwaysAllow: This is the default mode that CDK will use unless configured otherwise. All calls to the API server are allowed.
  • Node: Grants permissions to kubelets based on the pods they are scheduled to run. When using this mode, CDK will enable NodeRestriction and will issue (and decommission) tokens for kubernetes-workers as you scale your infrastructure. More detailed information can be found in the Kubernetes documentation.
  • ABAC: Using attribute-based access control, access rights are granted to users through the use of policies which combine attributes together. The policies can use any type of attributes (user attributes, resource attributes, object attributes, environment attributes, etc). For more information on ABAC mode, see the Kubernetes ABAC documentation.
  • RBAC: Using role-based access control, access is granted to users based on the roles assigned to them. This mode expects respective roles and bindings to be available for any running services. CDK already has roles and bindings ready for use (see below).
  • Webhook: With this mode set, Kubernetes will query an outside REST service when determining user privileges. This mode requires additional configuration to specify the service being queried. A full explanation of this can be found in the Kubernetes Webhook mode documentation.
  • AlwaysDeny: This mode denies all API requests - it is only really useful for testing.

Determining the current configuration

Juju can be used to query the current configuration setting:

juju config kubernetes-master authorization-mode

The default value is:

AlwaysAllow

For further verification, the runtime arguments for the kube-apiserver can be determined:

juju run --unit kubernetes-master/0 "ps -ef | grep apiserver"

… from which we can see the --authorization-mode=AlwaysAllow argument:

root      2013     1  2 11:18 ?        00:01:25 /snap/kube-apiserver/917/kube-apiserver --advertise-address=10.153.234.96 --min-request-timeout=300 --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://10.154.124.144:2379,https://10.165.213.59:2379,https://10.167.80.201:2379 --storage-backend=etcd3 --tls-cert-file=/root/cdk/server.crt --tls-private-key-file=/root/cdk/server.key --insecure-bind-address=127.0.0.1 --insecure-port=8080 --audit-log-maxbackup=9 --audit-log-maxsize=100 --audit-log-path=/root/cdk/audit/audit.log --audit-policy-file=/root/cdk/audit/audit-policy.yaml --basic-auth-file=/root/cdk/basic_auth.csv --client-ca-file=/root/cdk/ca.crt --requestheader-allowed-names=system:kube-apiserver --requestheader-client-ca-file=/root/cdk/ca.crt --requestheader-extra-headers-prefix=X-Remote-Extra- --requestheader-group-headers=X-Remote-Group --requestheader-username-headers=X-Remote-User --service-account-key-file=/root/cdk/serviceaccount.key --token-auth-file=/root/cdk/known_tokens.csv --authorization-mode=AlwaysAllow --admission-control=NamespaceLifecycle,LimitRanger,ServiceAccount,PersistentVolumeLabel,DefaultStorageClass,DefaultTolerationSeconds,MutatingAdmissionWebhook,ValidatingAdmissionWebhook,ResourceQuota --allow-privileged=false --enable-aggregator-routing --kubelet-certificate-authority=/root/cdk/ca.crt --kubelet-client-certificate=/root/cdk/client.crt --kubelet-client-key=/root/cdk/client.key --kubelet-preferred-address-types=[InternalIP,Hostname,InternalDNS,ExternalDNS,ExternalIP] --proxy-client-cert-file=/root/cdk/client.crt --proxy-client-key-file=/root/cdk/client.key --service-cluster-ip-range=10.152.183.0/24 --logtostderr --v=4
root     18966 18964  0 12:11 ?        00:00:00 grep apiserver

Setting a configuration

The authorisation mode can be set using the same Juju command as above, but this time specifying a value:

juju config kubernetes-master authorization-mode="Node"

It is possible to set more than one mode using a comma-separated list:

juju config kubernetes-master authorization-mode="RBAC, Node"

Note: Using “RBAC,Node” for authorisation is the recommended configuration.

The order matters. Kubernetes will process each API request with each module in sequence. If the current authorising module either allows or denies the request, that decision is made and no further modules are consulted. If the current module has no opinion on the request, then the decision is passed to the next module in the list. If no decision has been returned by the last module in the list, then the request is denied.

Further information on RBAC

Many of the defined roles (those prefixed by ‘system:’ ) for RBAC are really intended for managing access to Kubernetes componenets themselves.

The main cluster roles for additional users are:admin, cluster-admin, edit and view .

You can view the available roles, cluster roles and bindings with the following commands:

kubectl get roles --all-namespaces
kubectl get clusterroles --all-namespaces
kubectl get rolebindings --all-namespaces
kubectl get clusterrolebindings  --all-namespaces

Adding or removing users and editing roles

The recommended method for managing Kubernetes users is through an external authentication service such as LDAP (see the documentation on using LDAP with CDK). You can read more about the Kubernetes approach to authentication in this page of the Kubernetes documentation.

For simple systems, and for the purposes of testing, it can be useful to use the basic file-based system. The instructions below demonstrate how to edit the basic_auth.csv files on the kubernetes-master nodes.

Using basic_auth files

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”.

First establish an SSH connection to the main kubernetes-master:

juju ssh kubernetes-master/0

Then edit the file:

sudo nano /root/cdk/basic_auth.csv
exit

…adding the appropriate details. You can then restart the master for the changes to take effect:

juju run-action kubernetes-master/0 restart

For more detail on the roles and bindings, please see the Kubernetes RBAC documentation.