(Photo by Micah Williams on Unsplash)
The previous post was an overview on Cluster Maintenance - now let's look user maintenance.
To keep our cluster secure, we need to be able to control who can access our cluster and what they should be allowed to do.
Kubernetes allows us to administer our cluster via command-line with the now-familiar kubectl command. As discussed, kubectl is our interface interacting with the kube-apiserver. Thus, to control user access to our server, we have to control who has the ability to interact with the kube-apiserver.
Access to the kube-apiserver can be controlled with the following;
- Cloud Identity Services - AWS, GCloud, Azure Identity Server, ect
- SSL/TLS Certificates
- Static Token Files & Static Password Files
Cloud Identity Services are beyond the scope allowed for and will be conveniently set aside. If you intend to use one of the Cloud Identity Services, my recommendation would be to read their documentation instead.
Static Files
We can save files in disk with lists of allowed usernames and associated passwords, or usernames and associated token files. This approach is not recommended for various reasons(credentials are exposed in a file, any changes would require restarting the kube-apiserver, ect) but we'll have a brief look how it works anyway.
Static files would be in the form of a .csv file with rows of credentials with the following columns;
- password/token
- username
- UID
- Array of user groups(optional)
This csv file can be added to the kube-apiserver service with the flag --basic-auth-file. A token csv file should be added with --token-auth-file.
You would then log in via command line with - in the case of Static Password Files;
curl -u USERNAME:PASSWORD -i -H 'Accept:application/json' --insecure https:// SERVER:6443/api/v1/pods
Connecting with a token would be as follows;
curl -i -H 'Authorization: Bearer {token}" https:// SERVER:6443/api/v1/pods
We can also create accounts for bots or external services to take over certain administrative task by creating service accounts.
SSL/TLS Certificates
A more secure option for users to authenticate to your cluster would be to use TLS certificates.
SSL/TLS certificates does two things; it asymmetrically encrypts the exchange of data between parties and confirms their identities. Asymmetrical encryption means we would use both Private and Public keys, and at least one Certificate Authority(CA) for our cluster communications to be secured.
We will look at signed certificates in more depth in the next post.
Service Accounts
Service accounts are accounts and access points we create for third-party services/bots to access services on our cluster. This would likely be used for things like hook services when you want to tie in things happening on external services with things that should happen in your cluster, for instance payment hook.
You would create a service account like so;
kubectl create serviceaccount {botty1}
But we'll also have a closer look at Service Accounts in a later post.
Conclusion
We had a brief look at the 3 ways entities, whether humans or machines, can get authenticated on your cluster. In the next post we'll look at SSL/TLS certificate authentication in particular, since it is considered one of the safer ways of doing so.
