6ed5cb5249
* website/integrations: rename "Create with Provider" to "New Application" The application list page now uses a split-button labeled "New Application" instead of the old "Create with Provider" dropdown. Update all 113 integration guides to match. * website/docs: update flow, stage, and policy button labels - "Create" → "New Flow", "New Stage", "New Policy" for trigger buttons - "Finish" → "Create Flow", "Create Stage", "Create Policy" for submit - "Create and bind stage" → "New Stage" / "Bind Existing Stage" - "Create" (binding submit) → "Create Stage Binding" * website/docs: update provider button labels - "Create" → "New Provider" for trigger buttons - "Create with Provider" → "New Application" in RAC docs - "Create" → "New Property Mapping", "New RAC Endpoint", "New Prompt" for related entity creation * website/docs: update directory button labels - "Create" → "New Source" for federation/social login pages - "Create" → "New Role", submit → "Create Role" - "Create" → "New Invitation" - Policy binding submit → "Create Policy Binding" * website/docs: update endpoint device and system management button labels - "Create" → "New Endpoint Connector", "New Enrollment Token", "New Device Access Group", "New Flow" - Submit → "Create Device Access Group" - "Create" → "New Notification Rule", "New Notification Transport" - Binding submit → "Create Policy Binding" * Reorganize policy documentation * website/docs: address policy docs review feedback * post-rebase * website/docs: Reorganize policy documentation -- Revisions (#21601) * apply suggestions * Fix escaped. * Fix whitespace. * Update button label. * Fix phrasing. * Fix phrasing. * Clean up stragglers. * Format. --------- Co-authored-by: Dominic R <dominic@sdko.org>
4.5 KiB
title, sidebar_label, support_level
| title | sidebar_label | support_level |
|---|---|---|
| Integrate with Headscale | Headscale | community |
What is Headscale
Headscale is an open source alternative to the Tailscale coordination server and can be self-hosted for a single tailnet. Headscale is a re-implemented version of the Tailscale coordination server, developed independently and completely separate from Tailscale, with its own independent community of users and developers.
Preparation
The following placeholders are used in this guide:
headscale.companyis the FQDN of the Headscale installation.authentik.companyis the FQDN of the authentik installation.
:::info This documentation lists only the settings that you need to change from their default values. Be aware that any changes other than those explicitly mentioned in this guide could cause issues accessing your application. :::
authentik configuration
To support the integration of Headscale with authentik, you need to create an application/provider pair in authentik.
Create an application and provider in authentik
-
Log in to authentik as an administrator and open the authentik Admin interface.
-
Navigate to Applications > Applications and click New Application to open the application wizard.
- Application: provide a descriptive name, an optional group for the type of application, the policy engine mode, and optional UI settings.
- Choose a Provider type: select OAuth2/OpenID Connect as the provider type.
- Configure the Provider: provide a name (or accept the auto-provided name), the authorization flow to use for this provider, and the following required configurations.
- Note the Client ID, Client Secret, and slug values because they will be required later.
- Set a
Strictredirect URI tohttps://headscale.company/oidc/callback. - Select any available signing key.
- Configure Bindings (optional): you can create a binding (policy, group, or user) to manage the listing and access to applications on a user's My applications page.
-
Click Submit to save the new application and provider.
Headscale configuration
To support the integration of Headscale with authentik, you'll need to update the config.yaml file of your Headscale deployment:
oidc:
# Do not start Headscale until it can fetch authentik's OIDC configuration
only_start_if_oidc_is_available: true
issuer: "https://authentik.company/application/o/<headscale-slug>/"
client_id: "<Client ID from authentik>"
# There are three ways to configure the client secret (choose one):
#
# 1. Directly in the config file (not recommended for production):
client_secret: "<Client secret from authentik>"
#
# 2. From a file path (supports environment variables, works with systemd's LoadCredential):
# client_secret_path: "${CREDENTIALS_DIRECTORY}/oidc_client_secret"
#
# 3. From an environment variable:
# The HEADSCALE_OIDC_CLIENT_SECRET environment variable will be used automatically if set
# OIDC scopes to request (defaults: "openid", "profile", "email")
# Additional scopes can be added to request extra user information
scope: ["openid", "profile", "email", "custom"]
# Passed on to the browser login request – used to tweak behaviour for the OIDC provider (optional)
extra_params:
domain_hint: acmecorp.net
# Reject authentication if user doesn't match these criteria (optional)
allowed_domains:
- acmecorp.net
# Group-based access control (optional)
allowed_groups:
- /headscale
# Specific user allowlist (optional)
allowed_users:
- dominic@acmecorp.net
pkce:
enabled: true
method: S256
# Email Domain Handling:
# When strip_email_domain is true: "user@acmecorp.net" becomes username "user"
# When strip_email_domain is false: "user@acmecorp.net" becomes username "user.acmecorp.net"
strip_email_domain: true
Configuration verification
To verify the integration with Headscale, log out and attempt to log back in using OIDC. When attempting to log in, you'll be redirected to your Headscale installation, which then forwards you to authentik before returning to Headscale, though the exact flow may vary slightly depending on the client platform.