Embedded Outpost

authentik includes an embedded outpost to simplify deployments that use the Proxy provider.

The embedded outpost runs as part of the main authentik server deployment and is managed by authentik itself. It authenticates to the authentik API by using the secret key.

You can access the embedded outpost on the same ports as authentik itself, 9000 and 9443.

When to use the embedded outpost

Use the embedded outpost when you are using the proxy provider and want the simplest deployment model. It is a good fit when authentik is already behind a reverse proxy and you want proxy provider traffic to be handled by the same authentik deployment, without a separate outpost deployment.

Use a managed outpost instead when you want authentik to deploy and update a separate outpost through the Docker or Kubernetes integrations, or when you want the outpost lifecycle to be separate from the core server.

If the embedded outpost does not fit your deployment, you can ignore it and use a managed outpost instead.

Configuration

Because authentik does not know its own primary URL, you might need to configure the embedded outpost after installation.

By default, when you open the Admin interface on a fresh install, authentik automatically configures the outpost to use the same URL that was used to access authentik.

If this is not correct, navigate to Applications > Outposts, edit authentik Embedded Outpost, and set authentik_host to the correct URL.

Make sure that you set a full URL. A hostname or FQDN by itself does not work.

Most other outpost configuration options also apply to the embedded outpost, except for items that are marked as non-embedded.

# Log level that the outpost will set
# Allowed levels: trace, debug, info, warning, error
# Applies to: non-embedded
log_level: debug
# Interval at which the outpost will refresh the providers
# from authentik. For caching outposts (such as LDAP), the
# cache will also be invalidated at that interval.
# (Format: hours=1;minutes=2;seconds=3).
refresh_interval: minutes=5
########################################
# 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
# pathType to use on routes. Defaults to `Prefix`. Some ingress-nginx deployments need this to be set to `ImplementationSpecific`.
# 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
# Disable strict x509 validation for Kubernetes API server.
#
# On some older Kubernetes clusters, the root certificate may have been
# generated without certain x509 extensions. `urllib3`, which is used in
# the official kubernetes client, introduced stricter validation for
# certificates in version 2.4.0 which will cause `certificate verify failed`
# errors to appear in outpost logs. This option disables the stricter
# validation and allows the outpost to connect to the Kubernetes API server
# even with older certificates.
#
# It is recommended to only enable this option if you are experiencing
# certificate validation issues and understand the security implications
# of disabling strict x509 validation.
kubernetes_disable_x509_strict: false

Routing

Requests are routed as follows:

Paths starting with /static, /media, and /help return packaged CSS and JavaScript files, and user-uploaded media files.
Paths starting with /outpost.goauthentik.io are sent to the embedded outpost.
Any hosts configured in the providers assigned to the embedded outpost are sent to the outpost.
Everything remaining is sent to the authentik backend server.

How the embedded outpost differs from managed outposts

There are a few differences between managed outposts and the embedded outpost because authentik cannot fully manage the main authentik server deployment in the same way that it manages a separate outpost deployment.

Docker only: no automatic Traefik labels are added to the server container.

When you deploy a managed outpost on Docker, the container includes labels that can configure Traefik automatically. The embedded outpost does not add those labels to the server container.
Kubernetes only: an additional Service is created.

Because authentik does not know the name of the primary authentik Service, it creates another Service with a common set of labels that is always present.

When to use the embedded outpost​

Configuration​

Routing​

How the embedded outpost differs from managed outposts​

When to use the embedded outpost

Configuration

Routing

How the embedded outpost differs from managed outposts