The Notorious Kube Genius Geoff had a problem.
After saving the company's Kasten setup by doing a DR restore he was told that Junior Joe’s full access to the cluster would be removed but he still needed access to Kasten to perform his duties which involved only certain functions with policies. NKGG referenced the Kasten documentation concerning Authentication and decided it was time to leverage Open ID connect to do this and in that manner limit Junior Joe’s access.
This was going to be no walk in the park. NKGG had never ventured into this area of IT before so he decided to read up on the protocol itself and found a great free resource:
The handbook was offered by Auth0 and they had a free plan to start out with so NKGG decided to give their service a try.
You can sign up for free here:
After signing up it was time to create an application, this application will be our Kasten. For simplicity sake NKGG will named his application K10.
For type, he chose Regular Web application:
Further down on the page are the automatically created Domain name, ClientID and Client Secrets. NKGG needed to write all of these down, or copy them as they will be needed later when Kasten is installed or upgraded:
Also on this page are the Application Login URI and the Allowed Callback URLs. In this case NKGG supplied the values for his Kasten ingress:
When a user surfs to the Kasten login screen, Kasten will send them to Auth0, then Auth0 will check if that user is in it’s user database then check the username/password combo and if all is correct will send back a token which will authenticate the User into Kasten. The application Login URI and Allowed Callback URLs will route back to your application /authorize endpoint.
In the advanced section make sure in Grant Types Authorization code is enabled:
Now NKGG needed to create two users, one for himself and one for Junior Joe. Later on in the Kubernetes cluster NKGG will assign different RBAC roles to both users to ensure Junior Joe has only basic access. Since this is only a test setup we will make up email addresses, and just not enable email verification for the new user account. The authentication will still work without issues.
He did the same for Junior Joe and ended up with two user accounts:
Now the Auth0 side of the equation was ready to go with a very basic setup.
NKGG then installed a new version of Kasten in order to test his setup, all the steps for the Kasten side are clearly described in the Kasten documentation link that was given at the start of the article.
After waiting a few minutes for all the pods and services to deploy, NKGG was ready to test so he typed in the Kasten url and instead of seeing Kasten as he would normally expect he was sent to Auth0 for authentication:
Junior Joe’s login worked but he had no permissions.
So NKGG set him up with the basic user role available by leveraging RBAC:
kubectl create rolebinding juniorrole --namespace=kasten-io --clusterrole=k10-basic --email@example.com
Now Junior Joe would not be able to claim that he had no rights in Kasten:
Next NKGG had to give himself full access:
kubectl create clusterrolebinding adminrolebinding --clusterrole=k10-admin --firstname.lastname@example.org
kubectl create rolebinding adminnsadminrole --role=k10-ns-admin --namespace=kasten-io --email@example.com
NKGG logged in using his account and checked the permissions:
But wait.. Junior Joe’s father is not only friends with the CEO but he is also a Billionaire, if Junior Joe complains his Dad might just try a hostile takeover of AUTH0 and change the permissions!!! NKGG was a bit on the paranoid side but nevertheless he figured it might be better to setup in house his own OIDC provider….
Coming soon NKGG leverages an in house deployment of Keycloak for Kasten Authentication!