Deploying authentik outposts on Kubernetes

Deploying authentik outposts on Kubernetes: when your team needs it

A platform team protecting applications that cannot speak OIDC or SAML needs a way to put authentik in front of them, and an outpost is the authentik component that does this work. An outpost is a separate service that sits next to the application, checks each request against authentik, and passes only authorized traffic through. Running outposts in Kubernetes keeps that enforcement point inside the same cluster as the workloads it protects, so the traffic path, scaling and ingress rules are managed where your team already operates. This page covers four outpost types: the *proxy* outpost for forward auth and header-based access, the *LDAP* outpost for directory binds, the *RADIUS* outpost for network clients, and the *RAC* outpost for remote access control sessions. The authentik server also contains an embedded outpost, which runs inside the server container and serves the same protocols without a separate deployment. A standalone outpost is the better fit when you want its replicas, namespace, ingress and upgrade cadence managed apart from the core server, which is the main reason platform teams split them out. authentik's Kubernetes integration is enabled by default and lets authentik deploy and update outposts itself, with configurable replicas, namespace and ingress settings. If you prefer to own the manifests, outposts can also be deployed manually. Before choosing, confirm which path your change control allows, which namespace the outposts must live in, and whether your ingress controller is the one authentik's settings expect. The authentik outposts documentation describes both paths, and it is the next read for the decision.

Managed integration or manual manifests: which fits your cluster

The Kubernetes integration is enabled by default in authentik. With it, authentik deploys outposts into the cluster, updates them when the server version changes, and exposes settings for replicas, namespace and ingress. Your team configures the integration in authentik and grants the cluster access that authentik needs to create and manage those workloads. This suits teams that want fewer hand-written objects and a shorter path from a new provider to a running outpost.

Upgrades: authentik drives outpost updates, so you still need to check that the outpost version matches the server version after each authentik upgrade.
GitOps fit: outposts are created by authentik, not stored in your Git repository, so pull-based tools such as Argo CD will see them as drift unless you exclude or document them.
RBAC implications: the integration needs permissions to create and modify workloads in its target namespace, so review the scope of the service account and keep it inside that namespace.
Hand-written work: ingress rules, TLS certificates and network policies may still be yours to define, depending on the settings you use.
Settings to confirm: replica counts, namespace, and ingress options should be checked against the authentik outposts documentation for your version.

Before choosing this path, confirm with your platform team whether a controller that changes workloads outside Git is acceptable under your change control rules.

Outpost configuration options and when each fits

This table compares the configuration areas you set for authentik outposts on Kubernetes, from replicas and namespaces to outpost type, image pinning and the embedded outpost. Read each row as a decision: what it changes in your cluster and who needs to own it. Most teams settle the outpost type and image pinning first, because those decide how the rest of the deployment is built.

Option	When it fits	What it changes operationally
Authentik-managed Kubernetes integration	You want authentik to create and update outpost deployments from its own configuration, which is enabled by default.	authentik owns outpost deployments, so changes made by hand in the cluster may be overwritten. Confirm the RBAC it needs in your cluster.
Manual outpost manifests	Your platform team keeps all workloads in GitOps and wants every manifest reviewed before it is applied.	You own image tags, probes, resources and upgrades. Each authentik upgrade needs a matching manifest change.
Proxy outpost	You protect applications that cannot use OIDC or SAML, behind an ingress controller or reverse proxy.	Traffic for protected hosts passes through the outpost, so its replica count and latency affect every protected app.
LDAP outpost	Legacy clients need LDAP bind and search against authentik users and groups.	It needs a reachable LDAP port and a service account for the client. Expose it only to networks that need it.
RADIUS outpost	Network devices, VPN concentrators or Wi-Fi controllers authenticate with RADIUS.	RADIUS uses UDP and a shared secret per client. Confirm your load balancer and service type support UDP.
RAC outpost	You need remote access to internal hosts through authentik's remote access control provider.	It brings a remote access path into the cluster, so network policy and session logging need review before rollout.
Replicas	Proxy traffic is steady and you want rolling updates without downtime for protected apps.	More replicas spread load and reduce single-pod failure impact, but each replica must reach the authentik server. Size against your load tests.
Namespace	You separate outposts from applications, or run one outpost per team or environment.	Namespace choice sets RBAC scope, network policy targets and which pods can read outpost secrets.
Ingress settings	The outpost must be reachable at the path or host your reverse proxy or ingress routes to.	Ingress host and path must match the application's callback and cookie domain. Mismatches are a common cause of login loops.
Image and version pinning	You need a controlled upgrade path that matches the authentik server version.	Outposts should run the same authentik version as the server. Pin tags and plan outpost upgrades in the same change window.
Embedded outpost	A small deployment has few protected apps and you accept the server container handling outpost traffic.	Outpost traffic shares resources with the core server. Many teams disable it when a standalone outpost serves the apps.

Setting up outposts on a Kubernetes cluster

This sequence takes a cluster from a confirmed authentik release line to running proxy outposts that authentik manages in Kubernetes, with a production database, verified sign-in redirects and a tested upgrade path. Each step ends with a check so problems surface before the next layer is added.

Confirm the authentik version and release line
Before any manifest or chart value is written, choose the authentik release line your organization will run and check the security policy for which lines currently receive security fixes. The supported lines listed in the project's security policy are 2026.5.x and 2026.8.x, and the latest release on the GitHub releases page at the time of research was 2026.8.4. Confirm the current list again on the day you start, because the project announces security releases at least 24 hours in advance and the supported lines change over time. Record the chosen version in your change ticket so the Helm chart version, the server image and the outpost image all match it. Done when the version, its support status and the upgrade target are written down and approved by the platform owner.
Provision a production PostgreSQL database
Authentik stores all configuration and data in PostgreSQL, and since the 2025.10 release it also handles caching, tasks, sessions and WebSocket functions that earlier versions delegated to Redis. The Kubernetes guide says the PostgreSQL bundled with the Helm chart is for demonstration and test environments, so a managed or separately operated PostgreSQL instance is needed for production. Ask your database team to provision it with backups, point-in-time recovery, a dedicated database and role for authentik, and TLS between the pods and the database. Plan for roughly 50% more connections after upgrading to 2025.10 or later, as the release notes warn, and size the connection limit or a pooler accordingly. Done when you can connect to the database from a test pod using the authentik credentials and the connection count headroom is documented.
Install authentik with Helm against external PostgreSQL
Install the authentik Helm chart into a dedicated namespace, pinning the chart version and image tags to the release line chosen in the first step. Disable the bundled PostgreSQL and point the chart at the external database, reading the password from a Kubernetes Secret rather than a values file committed to Git. Create the secret key and any external hostname values before the first install, because changing the secret key later can invalidate stored sessions and encrypted values. Install the server and worker components, and make sure the worker deployment is running, since background tasks depend on it. Done when the server and worker pods report Ready, the database migrations complete in the logs, and the initial setup flow loads through the ingress hostname over HTTPS.
Enable the Kubernetes integration in authentik
The authentik Kubernetes integration is enabled by default, which lets authentik deploy and update outposts itself. Confirm in the administration interface that the Kubernetes integration is present and connected to the cluster, and confirm that the authentik service account in the release namespace has the permissions the chart grants to manage outpost deployments. Review those permissions with the cluster team, because the integration creates workloads in the cluster and should be limited to the namespaces you intend it to manage. If your policy requires it, you can instead deploy outposts manually with your own manifests, which the documentation also supports. Done when the integration shows as connected and a test outpost can be listed without errors in the authentik logs.
Create the proxy provider and outpost
In the authentik administration interface, create a proxy provider for the first protected application, choosing single-application or domain-level mode according to your access design. Then create a proxy outpost and assign the provider to it, so authentik knows which applications that outpost should protect. Set the external host that users will reach, and confirm the application and provider appear in the outpost assignments. Keep the outpost token in the authentik interface and do not copy it into manifests in plain text. Done when the outpost is listed with its provider assigned and its status shows as healthy or as deployed, which you can confirm in the outposts view.
Set replicas, namespace and ingress for the outpost
Configure the Kubernetes integration settings for the outpost: the number of replicas, the namespace where the outpost runs, and the ingress settings that route the application hostname to the outpost path. Start with a small replica count to prove the path works, then raise it after you have confirmed that the outposts connect back to the authentik server and stay healthy under normal traffic. Keep the outpost in a namespace separate from the protected application where your policies require it, and confirm that the pod security settings meet the Pod Security Standards level your namespace enforces. Check the ingress resource the integration generates, including the TLS secret and host name. Done when the outpost pods are Ready at the chosen replica count and the generated ingress resolves to the outpost service.
Verify health, redirects and sign-in
Test the protected application from a browser that has no existing session. An unauthenticated request should redirect to the authentik login page on the authentik hostname, and after a successful sign-in the user should return to the application with the expected identity headers passed upstream. Check the outpost logs for connection errors to the authentik server, and check that a second replica can serve the same session when one pod is restarted. Confirm that a user without the right group or policy is denied. Record the results so they can be repeated during the upgrade test. Done when the redirect, sign-in, denial and pod restart checks all pass and are documented.
Rehearse the authentik and outpost upgrade path
Before the environment is treated as production, rehearse an upgrade in a non-production cluster. Authentik upgrades should be applied in order, and the outpost version has to stay aligned with the server version, so review the upgrade documentation for the outposts and the release notes for the target version before changing anything. Update the chart and image tags in a test environment, let the Kubernetes integration roll the outpost to the new version, and repeat the verification checks from the previous step. Note any database migration time and the connection count after the upgrade. Done when the rehearsal ends with the same redirect and sign-in results and a written runbook that the operations team can follow in production.

Security controls for outposts running in your cluster

An outpost in Kubernetes holds credentials to your authentik server, sits on the request path for protected applications, and can create workloads through the integration. The six controls below cover the secret, the workload, the network, the transport, the permissions and the audit trail, and each one needs an owner before the outposts go live.

Outpost token and Secret storage

The outpost token lets a deployed outpost authenticate to authentik, so treat it as a credential. Kubernetes Secrets are stored unencrypted in etcd by default, so confirm that encryption at rest is enabled for the cluster's API server, or pull the token from an external store through the Secrets Store CSI Driver. Ask who can read Secrets in the outpost namespace, and rotate the token if a user with list or watch access leaves.

Pod Security Standards for outpost pods

Outpost pods run a network-facing service in front of your applications, so they should meet the restricted profile of the Pod Security Standards where your cluster allows it. Check that the pods run as non-root, drop Linux capabilities, disallow privilege escalation and use a read-only root filesystem if the image supports it. Confirm this in the namespace labels, because the integration's generated pods must pass the same admission check as manual manifests.

Network policy between ingress, outposts and authentik

Limit traffic so that only the ingress controller reaches the outpost port, and only outpost pods reach the authentik server on the ports the outpost needs. Apply a default-deny policy in the outpost namespace, then add explicit allow rules for each path. Test the policy from a pod outside the allowed set, because a protected application reachable without going through the outpost defeats the access check.

TLS on the outpost path

Decide where TLS terminates for the browser-facing path to the outpost, and where it terminates for the outpost-to-authentik connection. Document both hops, the certificate issuer and the renewal owner. Confirm that session cookies are set only over HTTPS and that the outpost cannot be reached over plain HTTP from another namespace.

RBAC for the integration service account

When authentik manages outposts through its Kubernetes integration, the cluster credential it uses can create and update Deployments, Services and Secrets in the target namespace. Scope that role to the outpost namespace only, avoid cluster-wide bindings, and remove permissions the integration does not need. Review the role after each upgrade, since the set of resources it manages can change with the release.

Logging of outpost events

Forward outpost container logs and Kubernetes audit events for the outpost namespace to your central log store. Keep authentication failures, redirects and changes to outpost Deployments or Secrets in the audit trail, and set a retention period that matches your policy. Confirm which fields identify the user and application in each record, because that is what an investigator will search on.

Running and upgrading outposts with the cluster

Every outpost must run the same authentik version as the server it connects to. Outposts are not independent products with their own release cadence, so an upgrade of the authentik server means upgrading the outposts in the same change window. When authentik manages outposts through its Kubernetes integration, it updates them itself; manual deployments need the new image tag applied by your team. Check the authentik upgrading an outpost guide before each upgrade. The authentik security policy lists 2026.5.x and 2026.8.x as the lines receiving security fixes, and the project announces security releases at least 24 hours in advance. Use that window to schedule the outpost rollout, and confirm with your team which lines you intend to stay on so the cluster plan matches the authentik release you run.

The cluster has its own clock. Kubernetes maintains only its three most recent minor releases, and the version skew policy requires kube-apiserver to be upgraded one minor version at a time, before the controller manager, scheduler and kubelets, with kubelets allowed to lag by up to three minor versions. Plan cluster upgrades as a sequence of single-minor steps, and confirm that the authentik outpost image you run supports each Kubernetes version along the path. Because the support window is short, a cluster that falls behind can reach end of life while the outposts still depend on it, so track the end-of-life dates on the Kubernetes releases page as part of the same calendar.

Outpost availability depends on the control plane underneath it. Running more than one outpost replica only protects the proxy path if the nodes they land on stay schedulable and the API server stays reachable. The kubeadm high availability guide describes a stacked topology with etcd on the control plane nodes or an external etcd cluster, with at least three control plane nodes and a TCP load balancer in front of kube-apiserver on port 6443. etcd should run with an odd number of members, and the documentation recommends five members in production. Confirm which topology your distribution uses, whether etcd snapshots are taken with etcdctl snapshot save on a schedule, and whether you have rehearsed a restore with etcdutl, because a failed etcd quorum affects every workload, including authentication.

Limits to confirm in your environment

The managed Kubernetes integration depends on your authentik version, your ingress controller, your Kubernetes distribution and your database capacity. Each item below is a check to run with authentik or in a test cluster before you commit to a design.

Outpost types the integration supports

authentik's Kubernetes integration is on by default and can deploy and update outposts, but the set of outpost types it manages can differ from what you need. Confirm for your exact authentik version whether the proxy, LDAP, RADIUS and RAC outposts are all managed by the integration, or whether any of them need a manual manifest. Check this against the version you plan to run, not the latest release, because the answer can change between versions.

Ingress controller compatibility

Proxy outposts sit behind an ingress that routes traffic to them, and the annotations and configuration that work for one ingress controller may not carry over to another. Confirm with authentik which ingress controllers and settings the managed integration is designed to configure, and test the forward auth path end to end, including redirects, cookies and the headers passed to protected applications.

CNCF conformance of your distribution

Check whether your Kubernetes distribution is listed as CNCF Certified Kubernetes conformant before assuming the standard APIs behave as authentik expects. Conformance shows the distribution supports the required APIs, but it does not replace testing outposts on that distribution, and a managed or customized distribution may add admission rules or network policies that block outpost traffic.

PostgreSQL connection capacity after upgrades

authentik's 2025.10 release notes warn that upgrading can raise PostgreSQL connection counts by roughly 50 percent, because caching, tasks and sessions moved off Redis. Each additional outpost replica and server pod adds to that load. Ask authentik how many connections each component opens, size your PostgreSQL max_connections and any pooler against your replica counts, and test the figure in staging before scaling outposts in production.

Enterprise features that reach outposts

Some features you need may be Enterprise-only, such as mTLS client certificate authentication, enhanced audit logging or privileged access management. Confirm with authentik whether each feature you rely on applies to outposts that run in your cluster, or only to the core server and its embedded outpost. Record the answer in writing before you design the network and audit paths around it.

Questions teams ask before running outposts on Kubernetes

What drives the cost and effort of running authentik outposts on Kubernetes?

The main drivers are how many applications sit behind outposts, how many outpost types you run (proxy, LDAP, RADIUS or RAC), and how much of the surrounding platform already exists. Each protected application adds provider configuration, routing and policy work, and each outpost type adds its own testing. Cost components include the design and build of the outpost layout, the ingress and certificate work, the test plan, and the handover documentation. One-time work covers the initial build. Recurring work covers upgrades that follow authentik's release cadence and the Kubernetes minor versions your cluster moves through. Ask any provider for a quote that lists these items separately, with the applications and outpost types named in the written scope.

Can our own team run authentik outposts on Kubernetes without a partner?

Yes, many teams do, provided they already operate Kubernetes and understand how their identity provider and reverse proxy interact. authentik's Kubernetes integration is enabled by default and lets authentik deploy and update outposts itself, so a team can start with that path and extend it. The skills that matter most are ingress configuration, TLS, secret handling for outpost tokens, and the ability to test login flows end to end. Teams with limited Kubernetes experience, or with several protected applications across namespaces, often find the verification and upgrade routine takes the most effort. A partner can take on any part of that work under a written scope, while your team keeps ownership of the cluster.

How long does an outpost deployment on Kubernetes usually take?

Duration depends on scope rather than on a standard figure. The size of the estate, the number of applications and outpost types, the state of the ingress and certificate setup, and how many environments need the change (test, staging and production) all shift the schedule. We do not publish a timeline. Ask for a schedule tied to the written scope, with milestones for the first outpost, the rollout to each application, and the verification and cutover steps. Your team's review and change windows can also set the pace, so include them in the plan.

What does the work need from our cluster and identity team?

The work needs both teams in the same planning sessions. From the cluster team, it needs a defined namespace layout, ingress controller details, a certificate process, network policy rules that allow outposts to reach the authentik server, and a place to store outpost tokens securely. Kubernetes stores Secrets unencrypted in etcd by default, so the cluster team should confirm encryption at rest and least-privilege RBAC before tokens are created. From the identity team, it needs the provider and application definitions, the groups and policies that decide access, and agreement on which applications use the proxy. The authentik server, worker and PostgreSQL must be reachable and sized for the added load. Confirm each of these in your own environment before the build starts.

When should we choose managed outposts over manual Kubernetes manifests?

Choose the managed path when you want authentik to create and update outposts through its Kubernetes integration, with replicas, namespace and ingress settings configured in authentik. Choose manual manifests when your platform team needs full control of the Deployment, Service and ingress objects, when a GitOps tool must own every change, or when your policy restricts the service account authentik would use. Managed deployments reduce the number of objects your team maintains, but they still need network and RBAC review. Manual deployments give more visibility and control, and they add a recurring duty to update image tags and configuration with each authentik release. Confirm the choice against your change management process before writing the scope.

Does the open-source edition of authentik cover running outposts on Kubernetes?

The repository places most of authentik's code under the MIT license, and the Open Source edition is listed as free with community Discord support. Code in the authentik/enterprise/ directory falls under a separate enterprise license. Confirm with authentik which features your chosen outpost types depend on, and check the license file for the exact terms before you deploy. The pricing page lists some features as enterprise only, such as ticket-based support and certain integrations, so review that list against your requirements. Support expectations differ by edition, so plan your upgrade and incident process with that in mind.

How do Kubernetes version upgrades affect outposts that authentik manages?

Kubernetes upgrades add a recurring step to the outpost plan. The version skew policy requires the kube-apiserver to be upgraded one minor version at a time, before the controller manager, scheduler and kubelets, and kubelets may be up to three minor versions older than the API server. Kubernetes maintains the three most recent minor releases, so your cluster must move forward within that window. Ask your team to confirm the cluster version, the authentik version and the outpost version together before each change, and to test a protected login after every step. The upgrade plan should name who signs off on each step.

What should we ask for in a written scope for outposts on Kubernetes?

Ask for a list of the applications to protect, the outpost types in use, and the target clusters and namespaces. The scope should also name the ingress controller, certificate process, the secret store for outpost tokens and the verification method. Add a line for documentation, a handover session, and the upgrade steps your team will own afterward. Confirm whether load tests, failover tests and security checks are included or priced separately. Clear written scope is what allows a fixed quote and a schedule your team can hold a provider to.

How the scope of an outpost engagement is set

The scope of an outpost engagement starts with a written inventory of what will run and where. Name each Kubernetes cluster that will host outposts, the outpost types in use (proxy, LDAP, RADIUS or RAC), and the number of protected applications behind each one. Decide whether authentik will manage the outposts through its built-in Kubernetes integration, which is enabled by default, or whether your team will deploy them with its own manifests. That single choice changes who owns replica counts, namespaces, image updates and rollback, so it belongs in the scope before any effort is estimated. Confirm the authentik release line you run, because the security policy lists the supported versions that receive fixes, and the outpost image should match the server version.

Ingress and TLS design is the second block of scope. Record the hostnames each protected application uses, which ingress controller routes traffic to the outpost, where certificates come from, and whether the outpost is reached through a shared domain or one provider per application. Include the Kubernetes ingress settings you intend to set, such as the namespace and the number of replicas, and state how the outposts will reach the authentik server. Ask the partner to name the networking assumptions it has made, including which network policies apply and where LDAPS or RADIUS traffic enters the cluster, since those are the points most often missed when the scope is drawn up loosely.

Upgrade ownership and handover close the scope. The written document should say who applies authentik and outpost version changes, who tests them against each protected application, who approves the change window, and who holds the rollback procedure. Most engagements are fixed-scope, so deliverables, acceptance criteria and dates are agreed in writing before work starts, and any item left out of that document will be a change request later. If you expect continued work after handover, such as version upgrades, monitoring or new applications, ask whether it is covered by a retainer, which is available for ongoing support. Ask for the exact list of deliverables and the handover format before you sign.

How DeployOpen delivers authentik outposts on Kubernetes

DeployOpen runs outpost work as a sequence: agree the scope in writing, build the outposts into your cluster, harden and test them, then document and support them. Each step matches a decision this topic raises, from who manages the outpost lifecycle to how ingress and replicas are set.

Scoping the outpost estate

We start by listing every application an outpost will front and every protocol it needs, including proxy, LDAP, RADIUS and RAC. For each one we record whether authentik's Kubernetes integration manages the deployment or your own manifests do, and which namespace, replica count and ingress route apply. The output is a written scope you can review before any cluster change is made.

Building the deployment in your cluster

We build the outposts in the Kubernetes clusters and cloud accounts you control, using authentik's managed integration or manifests you own. We confirm the outpost connects back to the authentik server, that the token and configuration are stored as Kubernetes Secrets, and that replicas and ingress behave as the scope requires.

Hardening the pods and access paths

We apply Pod Security Standards to outpost namespaces, restrict who can read or change outpost Secrets with least-privilege RBAC, and confirm that encryption at rest is configured for etcd. Network policies limit which workloads can reach each outpost. These controls are the parts most often left at defaults, so we check them explicitly.

Testing authentication and failover

We test each protected route for the expected redirect, login and header behavior, then remove a pod or node to confirm that sessions and access recover. Where security testing is in scope, we also probe the outpost endpoints and the paths that should never bypass authentication. Results are recorded against the agreed scope.

Documentation and handover

You receive runbooks covering the manifests or integration settings, the upgrade order for outposts relative to the authentik server, and the steps to rotate outpost tokens. We walk your platform team through the deployment so they can run changes without us. Documentation reflects the environment as built, not a generic template.

Retainer support and upgrades

After handover, ongoing support is available under a retainer. It covers outpost upgrades when authentik publishes new releases, Kubernetes minor version moves, and periodic retesting after configuration changes. Retainer scope and response expectations are written down before work begins, so you know what is covered and what requires a new scope.

Deploying authentik outposts on Kubernetes