Authelia is now available on Kube in order to protect your most critical applications using 2-factor authentication and Single Sign-On.
This example leverages ingress-nginx v0.13.0 to delegate authentications and authorizations to Authelia within the cluster.
In order to deploy Authelia on Kube, you must have a cluster at hand. If you don't, please follow the next section otherwise skip it and go to the next.
Hopefully, spawning a development cluster from scratch has become very easy lately with the use of minikube. This project creates a VM on your computer and start a Kube cluster inside it. It also configure a CLI called kubectl so that you can deploy applications in the cluster right away.
Basically, you need to follow the instruction from the repository. It should be a matter of downloading the binary and start the cluster with two commands:
curl -Lo minikube https://storage.googleapis.com/minikube/releases/latest/minikube-linux-amd64 && chmod +x minikube && sudo mv minikube /usr/local/bin/
minikube start # you can use --vm-driver flag for selecting your hypervisor (virtualbox by default otherwise)
After few seconds, your cluster should be working and you should be able to get access to the cluster by creating a proxy with
kubectl proxy
and visiting http://localhost:8001/ui
Once the cluster is ready and you can access it, run the following command to deploy Authelia:
./bootstrap.sh
In order to visit the test applications that have been deployed to test Authelia, edit your /etc/hosts and add the following lines replacing the IP with the IP of your VM given by minikube:
192.168.39.26 login.kube.example.com
192.168.39.26 app1.kube.example.com
192.168.39.26 app2.kube.example.com
192.168.39.26 mail.kube.example.com
192.168.39.26 home.kube.example.com
# The domain of the private docker registry holding dev version of Authelia
192.168.39.26 registry.kube.example.com
Once done, you can visit http://home.kube.example.com and follow the instructions written in the page.
In a Kube clusters, the routing logic of requests is handled by ingress controllers following rules provided by ingress configurations.
In this example, ingress-nginx controller has been installed to handle the incoming requests. Some of them (specified in the ingress configuration) are forwarded to Authelia so that it can verify whether they are allowed and should reach the protected endpoint.
The authentication is provided at the ingress level by an annotation called
nginx.ingress.kubernetes.io/auth-url that is filled with the URL of
Authelia's verification endpoint.
The ingress controller also requires the URL to the
authentication portal so that the user can be redirected in case she is not
yet authenticated.
Those annotations can be seen in apps/secure-ingress.yml configuration.
What is great with using ingress-nginx is that it is compatible with kube-lego which removes the usual pain of manual SSL certificate renewals. It uses letsencrypt to issue and renew certificates every three month without any manual intervention.
Given your cluster is already made of an LDAP server, a Redis cluster, a Mongo
cluster and a SMTP server, you'll only need to install the ingress-controller
and Authelia whose kubernetes deployment configurations are respectively in
ingress-controller and authelia directories. A template configuration
is provided there, you just need to create the configmap to use it within
the cluster.
If you're already using ingress-nginx as your ingress controller, you only need to install Authelia with its configuration and that's it!
If you have questions about the implementation, please post them on
