Day 13/#30daysofK8s

There are 4 types of users that access the k8s cluster — 1) Administrator, 2) Developers, 3) End users and 4) Bots.

End users accessing applications are handled by the applications itself, so k8s does not need to worry about it’s authentication. For e.g. if an application hosted by k8s cluster is a webpage like facebook, the process of user authentication will be handled by the webpage’s code.

Admin and developer are treated as user, while bots are treated as service accounts.

Admins and developer authentication will be managed by external authentication systems such as file with user details or certificates or third party identity service like kerberos or ldap. K8s does not support user creation, so we cannot create users like kubectl create user or kubectl list users .

Service accounts can be managed by k8s like k8s create service-account .

To use a file with user-details, we add a --basic-auth-file=path_to_file.csv to kube-apiserver.service and restart the service. We do so, because every request passes through kube-apiserver. If using kubeadm tool, updating the kube-apiserver manifest file with this flag should be enough, kubeadm automatically restarts the service after this change.

User detail file can contain password, username, group or token,username, group . In case of token, use --token-auth-file=user-details.csv

The above user-detail file with static username and password is not secure and is not recommended.



Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store