Outposts

An outpost is a single deployment of an authentik component, essentially a service, that can be deployed anywhere that allows for a connection to the authentik API.

An outpost is required if you use any of the following types of providers with your application:

• LDAP Provider
• Proxy Provider
• RADIUS Provider
• RAC Provider

These types of providers use an outpost for increased flexibility and speed. Instead of the provider logic being implemented in authentik Core, these providers use an outpost to handle the logic, which provides improved performance.

An additional advantage of using an outpost is that outposts, like authentik itself, do not require access to the wider internet. Transactions between the application, the provider, and the outpost occur via the authentik API, and support single sign-on operations in firewalled or airgapped deployments and offline connections to remote machines that are not on the internet.

An outpost is given permissions to access the authentik API using a service account and token, both of which are auto-generated when you create a new outpost. The outpost is granted rights to only the application/provider pairs configured (and other necessary related objects such as certificates).

Any change made to the outpost's associated app or provider immediately triggers an event to update the configuration data stored on the outpost, via websockets. Websockets are used also by the outpost to send healthchecks to the authentik Core.

Create and configure an outpost

1. To create a new outpost, log in to authentik as an administrator, and open to the Admin interface.

2. Navigate to Applications --> Outposts and then click Create.

3. Define the following values:

• Name: a name for the new outpost
• Type: select the provider type (Proxy, LDAP, Radius, RAC)
• Integration (optional): select either your Docker or Kubernetes connection
• Applications: select the applications that you want the outpost to serve
• Advanced settings (optional): For further optional configuration settings, refer to Configuration below.

4. Click Create to save your new outpost settings and close the modal.

Upon creation, a service account and a token is generated. The service account only has permissions to read the outpost and provider configuration. This token is used by the outpost to connect to authentik.

More about outpost integrations

authentik can manage the deployment, updating, and general lifecycle of an outpost. To communicate with the underlying platforms on which the outpost is deployed, authentik has several built-in integrations.

• If you've deployed authentik on Docker Compose, authentik automatically creates an integration for the local docker socket (See Docker).
• If you've deployed authentik on Kubernetes, with kubernetesIntegration set to true (default), authentik automatically creates an integrations for the local Kubernetes Cluster (see Kubernetes).

To deploy an outpost with these integrations, select them during the creation of an outpost. A background task is started, which creates the container/deployment. The outpost deployment can be monitored from the Dashboards -> System Tasks page in the Admin interface.

To deploy an outpost manually, see:

• Kubernetes
• Docker Compose

Configuration

Outposts fetch their configuration from authentik. Below are all the options you can set, and how they influence the outpost.

# Log level that the outpost will set
# Allowed levels: trace, debug, info, warning, error
# Applies to: non-embedded
log_level: debug
########################################
# The settings below are only relevant when using a managed outpost
########################################
# URL that the outpost uses to connect back to authentik
authentik_host: https://authentik.tld/
# Disable SSL Validation for the authentik connection
authentik_host_insecure: false
# Optionally specify a different URL used for user-facing interactions
# Applies to: proxy outposts
authentik_host_browser:
# Template used for objects created (deployments/containers, services, secrets, etc)
object_naming_template: ak-outpost-%(name)s
# Use a specific docker image for this outpost rather than the default. This also applies to Kubernetes
# outposts.
# Applies to: non-embedded
container_image:
########################################
# Docker outpost specific settings
########################################
# Network the outpost container should be connected to
# Applies to: non-embedded
docker_network: null
# Optionally disable mapping of ports to outpost container, may be useful when using docker networks
# (Available with 2021.9.4+)
# Applies to: non-embedded
docker_map_ports: true
# Optionally additional labels for docker containers
# (Available with 2022.1.2)
# Applies to: non-embedded
docker_labels: null
########################################
# Kubernetes outpost specific settings
########################################
# Replica count for the deployment of the outpost
# Applies to: non-embedded
kubernetes_replicas: 1
# Namespace to deploy in, defaults to the same namespace authentik is deployed in (if available)
kubernetes_namespace: authentik
# Any additional annotations to add to the ingress object, for example cert-manager
kubernetes_ingress_annotations: {}
# Name of the secret that is used for TLS connections, leave empty to disable TLS
kubernetes_ingress_secret_name: authentik-outpost-tls
# Service kind created, can be set to LoadBalancer for LDAP outposts for example
kubernetes_service_type: ClusterIP
# Disable any components of the kubernetes integration, can be any of
# - 'secret'
# - 'deployment'
# - 'service'
# - 'prometheus servicemonitor'
# - 'ingress'
# - 'traefik middleware'
kubernetes_disabled_components: []
# If the above docker image is in a private repository, use these secrets to pull.
# NOTE: The secret must be created manually in the namespace first.
# Applies to: non-embedded
kubernetes_image_pull_secrets: []
# Optionally configure an ingress class name. If not set, the ingress will use the cluster's
# default ingress class
# (Available with 2022.11.0+)
# Applies to: proxy outposts
kubernetes_ingress_class_name: null
# Optionally apply an RFC 6902 compliant patch to the Kubernetes objects.
# For an understanding of how this works, refer to the link below:
# https://github.com/kubernetes-sigs/kustomize/blob/master/examples/jsonpatch.md
#
# This value expects a mapping where the key represents
# the Kubernetes component that shall be patched.
# It can be any of the same values supported by `kubernetes_disabled_components`.
#
# For example use this patch to add custom resource requests and limits
# to the outpost deployment:
#
# deployment:
#   - op: add
#     path: "/spec/template/spec/containers/0/resources"
#     value:
#       requests:
#         cpu: 2000m
#         memory: 2000Mi
#       limits:
#         cpu: 4000m
#         memory: 8000Mi
kubernetes_json_patches: null

Prometheus Metrics

Each authentik outpost has a Prometheus metrics endpoint accessible under port :9300/metrics. This endpoint is not mapped via Docker, as the endpoint doesn't have any authentication.

For the embedded outpost, the metrics of the outpost and the metrics of the core authentik server are both returned under the same endpoint.