To get started and practice a few things around K8S, I have setup a K8S cluster on my laptop as shown below using kubeadm. It gives me the utmost flexibility to try different things around K8S. A few days back I have posted a blog on how a K8S cluster gets bootstrapped. This gives an idea on how the different K8S process start and then we would be able to change some of the K8S process startup parameters to try out new features in K8S.
In the above K8S cluster, the default user (kubernetes-admin) created during the cluster setup has admin privileges to the cluster. This time I was curious on how the authentication and authorization work in K8S for this user to have full access to the cluster. This will enable me to be create additional users with different privileges, authentication and authorization mechanisms. It took me some time to get my mind/thoughts around it, but it's all interesting. This blog is all about the same.
Note that the cluster has been setup using kubeadm, for kops and other the below varies a little bit. And also, kubeadm cluster setup default used X509 certificates for authentication. Authentication Providers are not built into K8S and so has to be integrated with external systems like Google Accounts, Active Directory, LDAP etc.
2) The X509 certificate from the .kube/config can be extracted and encoded. Finally the user details can be extracted with the opensll using the below commands. Note the output of the openssl command, the user name (CN) is kubernetes-admin and belongs to the system:masters organization (O).
grep "client-certificate-data" config | sed 's/ client-certificate-data: //g' > encoded.txt
base64 --decode encoded.txt > kubernetes-admin.crt
openssl x509 -noout -subject -in kubernetes-admin.crt
3) Now from a K8S cluster perspective. The cluster-admin (a ClusterRoleBinding object) binds the cluster-admin (a ClusterRole object with admin privilages) to the system:masters group. Any user of this group will have full cluster access.
kubectl describe clusterrolebindings.rbac.authorization.k8s.io cluster-admin
kubectl describe clusterrole cluster-admin
4) So, kubernetes-admin which belongs to the system:masters group as seen in the output of the openssl command has full access to the cluster.
K8S with the different concepts is a bit intimidating and it takes a bit of digging and research into the concepts to get a good understanding of the concepts. So, below is the mindmap for the above concept.
In the above K8S cluster, the default user (kubernetes-admin) created during the cluster setup has admin privileges to the cluster. This time I was curious on how the authentication and authorization work in K8S for this user to have full access to the cluster. This will enable me to be create additional users with different privileges, authentication and authorization mechanisms. It took me some time to get my mind/thoughts around it, but it's all interesting. This blog is all about the same.
Note that the cluster has been setup using kubeadm, for kops and other the below varies a little bit. And also, kubeadm cluster setup default used X509 certificates for authentication. Authentication Providers are not built into K8S and so has to be integrated with external systems like Google Accounts, Active Directory, LDAP etc.
1) By default with kubeadm installation, the user and cluster details are stored in the .kube/config file on the client side. This file helps kubectl command to connect and authenticate to the K8S cluster. The client-certificate-data and client-key-data fields in this file are used for authentication.
2) The X509 certificate from the .kube/config can be extracted and encoded. Finally the user details can be extracted with the opensll using the below commands. Note the output of the openssl command, the user name (CN) is kubernetes-admin and belongs to the system:masters organization (O).
grep "client-certificate-data" config | sed 's/ client-certificate-data: //g' > encoded.txt
base64 --decode encoded.txt > kubernetes-admin.crt
openssl x509 -noout -subject -in kubernetes-admin.crt
3) Now from a K8S cluster perspective. The cluster-admin (a ClusterRoleBinding object) binds the cluster-admin (a ClusterRole object with admin privilages) to the system:masters group. Any user of this group will have full cluster access.
kubectl describe clusterrolebindings.rbac.authorization.k8s.io cluster-admin
kubectl describe clusterrole cluster-admin
4) So, kubernetes-admin which belongs to the system:masters group as seen in the output of the openssl command has full access to the cluster.
Conclusion
K8S with the different concepts is a bit intimidating and it takes a bit of digging and research into the concepts to get a good understanding of the concepts. So, below is the mindmap for the above concept.
Note that (7 in the above diagram) maps the user details the organization name
(system-masters) in the certificate with the group name
(system-masters) in the ClusterRoleBinding. This is what gives the
kubernetes-admin user full access to the K8S cluster.
As mentioned earlier, any user part of the system-masters group will have full access to the cluster.This Bitnami article (1) talks about the adding K8S user called 'employee' with X509 certificates. The same with some tweaks can be used to create another user besides the kubernetes-admin part of the system:master group.
No comments:
Post a Comment