1
0
Fork 0
kubernetes/authelia
Dustin 759d8f112f ansible: Deploy ARA
[ARA Records Ansible][0] is a results storage system for Ansible.  It
provides a convenient UI for tracking Ansible playbooks and tasks.  The
data are populated by an Ansible callback plugin.

ARA is a fairly simple Python+Django application.  It needs a database
to store Ansible results, so we've connected it to the main PostgreSQL
database and configured it to connect and authenticate using mTLS.

Rather than mess with managing and distributing a static password for
ARA clients, I've configured Autheliad to allow anonymous access to
post data to the ARA API from within the private network or the
Kubernetes cluster.  Access to the web UI does require authentication.

[0]: https://ara.recordsansible.org/
2025-02-01 18:16:10 -06:00
..
README.md authelia: Set up OIDC for k8s API server 2023-04-22 21:37:23 -05:00
authelia.yaml v-m: Scrape metrics from Authelia 2024-02-27 06:41:52 -06:00
configuration.yml ansible: Deploy ARA 2025-02-01 18:16:10 -06:00
kustomization.yaml authelia: Update to 4.38.18 2025-01-11 12:32:12 +00:00
migrate.yaml authelia: Convert to a stateless service 2023-10-19 07:12:02 -05:00
oidc-cluster-admin.yaml authelia: Set up OIDC for k8s API server 2023-04-22 21:37:23 -05:00
postgres-cert.yaml authelia: Point to external PostgreSQL server 2024-07-02 18:16:05 -05:00
postgresql-ca.crt authelia: Convert to a stateless service 2023-10-19 07:12:02 -05:00
redis.yaml authelia: Convert to a stateless service 2023-10-19 07:12:02 -05:00
secrets.yaml authelia: Migrate to Sealed Secrets 2023-10-14 10:35:54 -05:00

README.md

Authelia

Authelia is an open-source authentication and authorization server and portal. It can operate as an OpenID Connect identity provider or as a proxy authorization subrequest handler (e.g. for nginx). It supports a built-in user database as well as LDAP, and various forms of second-factor authentication.

Installation

kubectl apply -k authelia

Configuration

Authelia is configured by the configuration.yml file. It is stored as a Kubernetes ConfigMap and mounted into the Authelia server container. See the Configuration section of the Authelia documentation for details.

Various secrets are used to secure Authelia. These are stored as Kubernetes Secret resources and mounted into the Authelia server container. Their contents originate from files such as jwt.secret, ldap.password, etc.

OpenID Connect

For applications that support it, OpenID Connect is usually a better option than proxy authorization subrequest. Each application needs to be defined in the identity_providers.oidc.clients list. At minimum, clients need an ID, description, and list of redirect URIs. Additionally, a client must either have a defined secret or be marked public.

Proxy Authorization Subrequest

Authellia's original purpose was to support the authorization subrequest feature of nginx and other reverse proxy solutions. When used in this way, Authelia can protect for applications that do not have a built-in authentication/authorization capabilities. For each incoming request, the proxy makes a subrequest to Authelia, passing along cookies, etc. from the original request. Authelia validates the session and indicates whether or not the request is allowed. If it is allowed, the proxy resumes processing the original request, forwarding it to the upstream server. If it is not allowed, the proxy returns a redirect response to the client, instructing the user agent to load the Authelia login page. Authelia then checks the user's credentials, optionally enforcing MFA validation (based on the configured access control policy), and creates a new session. It then redirects the user agent back to the resource requested initially.

Enabling the proxy authorization subrequest for applications hosted in Kubernetes is very straightforward. The ingress-nginx Ingress controller supports configuring it via the nginx.ingress.kubernetes.io/auth-url, et al. annotations. Adding authentication to an Ingress resource is therefore as simple as adding a few annotations:

metadata:
  annotations:
    nginx.ingress.kubernetes.io/auth-method: GET
    nginx.ingress.kubernetes.io/auth-url: http://authelia.authelia.svc.cluster.local:9091/api/verify
    nginx.ingress.kubernetes.io/auth-signin: https://auth.pyrocufflink.blue/?rm=$request_method
    nginx.ingress.kubernetes.io/auth-response-headers: Remote-User,Remote-Name,Remote-Groups,Remote-Email
    nginx.ingress.kubernetes.io/auth-snippet: |
      proxy_set_header X-Forwarded-Method $request_method;      

Note that the value of the auth-url contains the internal URL for Authelia, while the auth-signin value is the external URL.

OpenID Connect for Kubernetes API

The Kubernetes API server can be configured to authorize client requests using OpenID Connect. The relevant settings are provided as command-line arguments to the server process. For clusters managed by kubeadm, the arguments can be added to the ClusterConfiguration setting in the kubeadm-config ConfigMap:

ClusterConfiguration: |
  apiServer:
    extraArgs:
      oidc-client-id: kubernetes
      oidc-groups-claim: '["groups"]'
      oidc-groups-prefix: 'oidc:'
      oidc-issuer-url: https://auth.pyrocufflink.blue
      oidc-username-claim: preferred_username
      oidc-username-prefix: 'oidc:'  

Clients need to be specifically configured to use OIDC. For kubectl, the kubelogin plugin provides the necessary functionality. With the kubelogin binary installed, and a symbolic link to it named kubectl-oidc_login created, the client kubeconfig needs to specify an exec option for obtaining the authorization token:

users:
- name: dustin
  user:
    exec:
      apiVersion: client.authentication.k8s.io/v1beta1
      command: kubectl
      args:
      - oidc-login
      - get-token
      - --oidc-issuer-url=https://auth.pyrocufflink.blue
      - --oidc-client-id=kubernetes
      - --oidc-extra-scope=profile
      - --oidc-extra-scope=groups
      provideClusterInfo: false