authelia/internal/suites/example/kube
James Elliott 29a900226d
[FEATURE] Enhance LDAP/SMTP TLS Configuration and Unify Them (#1557)
* add new directive in the global scope `certificates_directory` which is used to bulk load certs and trust them in Authelia
* this is in ADDITION to system certs and are trusted by both LDAP and SMTP
* added a shared TLSConfig struct to be used by both SMTP and LDAP, and anything else in the future that requires tuning the TLS
* remove usage of deprecated LDAP funcs Dial and DialTLS in favor of DialURL which is also easier to use
* use the server name from LDAP URL or SMTP host when validating the certificate unless otherwise defined in the TLS section
* added temporary translations from the old names to the new ones for all deprecated options
* added docs
* updated example configuration
* final deprecations to be done in 4.28.0
* doc updates
* fix misc linting issues
* uniform deprecation notices for ease of final removal
* added additional tests covering previously uncovered areas and the new configuration options
* add non-fatal to certificate loading when system certs could not be loaded
* adjust timeout of Suite ShortTimeouts
* add warnings pusher for the StructValidator
* make the schema suites uninform
* utilize the warnings in the StructValidator
* fix test suite usage for skip_verify
* extract LDAP filter parsing into it's own function to make it possible to test
* test LDAP filter parsing
* update ErrorContainer interface
* add tests to the StructValidator
* add NewTLSConfig test
* move baseDN for users/groups into parsed values
* add tests to cover many of the outstanding areas in LDAP
* add explicit deferred LDAP conn close to UpdatePassword
* add some basic testing to SMTP notifier
* suggestions from code review
2021-01-04 21:28:55 +11:00
..
apps [MISC] Remove executable permission of nginx backend files. (#1040) 2020-05-25 10:54:21 +10:00
authelia [FEATURE] Enhance LDAP/SMTP TLS Configuration and Unify Them (#1557) 2021-01-04 21:28:55 +11:00
ingress-controller [MISC] Restructure repo folder layout (#628) 2020-02-09 18:04:27 +01:00
ldap [BUGFIX] [BREAKING] Set username retrieved from authentication backend in session. (#687) 2020-03-15 18:10:25 +11:00
mail [MISC] Restructure repo folder layout (#628) 2020-02-09 18:04:27 +01:00
storage [MISC] Restructure repo folder layout (#628) 2020-02-09 18:04:27 +01:00
bootstrap-authelia.sh [FEATURE] Make Authelia serve over TLS in all suites (#864) 2020-04-14 09:57:28 +10:00
bootstrap-dashboard.sh do not hardcode /bin/bash (#1122) 2020-06-18 09:49:13 +02:00
bootstrap.sh [DEV] Fix permission issue with dev workflow. (#1033) 2020-05-21 14:35:22 +10:00
dashboard.yml [MISC] Restructure repo folder layout (#628) 2020-02-09 18:04:27 +01:00
namespace.yml [MISC] Restructure repo folder layout (#628) 2020-02-09 18:04:27 +01:00
README.md [MISC] Restructure repo folder layout (#628) 2020-02-09 18:04:27 +01:00
test.yml [MISC] Restructure repo folder layout (#628) 2020-02-09 18:04:27 +01:00

Authelia on Kubernetes

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 to delegate authentication and authorization to Authelia within the cluster.

Getting started

You can either try to install Authelia on your running instance of Kubernetes or deploy the dedicated suite called kubernetes.

Set up a Kube cluster

The simplest way to start a Kubernetes cluster is to deploy the kubernetes suite with

authelia-scripts suites setup kubernetes

This will take a few seconds (or minutes) to deploy the cluster.

How does it work?

Authentication via Authelia

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 if he is not yet authenticated. This annotation is as follows: nginx.ingress.kubernetes.io/auth-signin: "https://login.example.com:8080/"

Those annotations can be seen in apps/apps.yml configuration.

Production grade infrastructure

What is great with using ingress-nginx is that it is compatible with kube-lego which removes the usual pain of manually renewing SSL certificates. It uses letsencrypt to issue and renew certificates every three month without any manual intervention.

What do I need to know to deploy it in my cluster?

Given your cluster already runs a LDAP server, a Redis, a SQL database, a SMTP server and a nginx ingress-controller, you can deploy Authelia and update your ingress configurations. An example is provided here.

Questions

If you have questions about the implementation, please post them on Gitter