78 lines
4.2 KiB
Markdown
78 lines
4.2 KiB
Markdown
---
|
|
title: "Block Authentik admin user access from the Internet"
|
|
tags: ["authentik", "sso", "idp", "admin"]
|
|
categories: ["recipe", "security"]
|
|
description: How to restrict Authentik admin access from internal networks only
|
|
date: 2025-10-13T00:00:00+02:00
|
|
author: "Ettore Dreucci"
|
|
draft: false
|
|
---
|
|
|
|
## How to restrict Authentik admin access from internal networks only
|
|
|
|
I've recently set up an [Authentik](https://goauthentik.io/) instance in my homelab for SSO authentication. I really like it, and I've set it up for authentication with several services that I'm self-hosting, including some that are internet-facing. That required exposing Authentik too, as I need to be able to reach it from outside my network when authenticating to these services.
|
|
|
|
Exposing to the Internet a core service like an identity provider is not a light-hearted job and even if Authentik is suggesting [some ways](https://docs.goauthentik.io/docs/security/security-hardening) to harden a deployment, I wanted to make sure that admin access is strictly restricted to internal networks only.
|
|
|
|
### Expose Authentik
|
|
|
|
You may argue that the best way to access such a sensitive service like one that provides authentication and authorization would be by using a VPN tunnel, so that you don't have to expose it to the outside world at all. However, VPN adds a layer of complexity, and when hosting services used also by non tech-savy relatives, limiting the degree of difficulty in accessing those surely helps to prevent sunday morning phone calls.
|
|
|
|
In exposing internal services to the Internet I'm currently using [NGINX](https://nginx.org/) as a reverse proxy. That is the case as well for exposing my Authentik instance.
|
|
Using a reverse proxy I'm also able to manage the SSL context, and therefore certificates, in a single place: this makes possible enabling (and forcing) HTTPS encryption without having to configure public, trusted, SSL certificates on every service.
|
|
|
|
#### Restrict admin interface
|
|
|
|
As a first layer of security, a simple yet effective action could be restricting access to the Authentik admin interface from internal network only.
|
|
|
|
Doing such a think is extremely easy using NGINX: in the server block I've defined a separate location for the `/if/admin/` path, allowing connections from the local network CIDR and denying the rests.
|
|
|
|
```
|
|
location /if/admin/ {
|
|
...
|
|
allow 192.168.0.0/24;
|
|
deny all;
|
|
...
|
|
}
|
|
```
|
|
|
|
That two simple instructions will prevent access to any sub-path of `/if/admin/` coming from IP addresses outside `192.168.0.0/24` subnet.
|
|
|
|
### Limit admin access
|
|
|
|
The above method could be further extended to additional paths, however that is just preventing access to the WEB admin interface, while leaving admin API still open.
|
|
|
|
Another approach that would further strengthen the security posture could be preventing the admin user(s) from logging in from external networks.
|
|
|
|
#### Prevent admin login from outside local networks
|
|
|
|
In order to deny login to admin user(s) from external networks we must:
|
|
1. **Create a policy to deny the login:**
|
|
1. On Authentik admin interface go to `Customization -> Policies`
|
|
2. Click on `Create`
|
|
3. Select `Expression Policy`
|
|
4. Under `Policy-specific settings` paste the following content in the `Expression` box:
|
|
```python
|
|
user = context['pending_user']
|
|
groups = [group.name for group in user.ak_groups.all()]
|
|
admin_group = "authentik Admins"
|
|
|
|
if admin_group in groups and not ak_client_ip.is_private:
|
|
return False
|
|
return True
|
|
```
|
|
2. Assign the policy to the authentication flow's login stage:
|
|
1. Go to `Flows and Stages -> Flows`
|
|
2. Click on the authentication flow you're using (i.e. `default-authentication-flow`)
|
|
3. Go to `Stage Bindings`
|
|
4. Expand the `User Login Stage`
|
|
5. Click on `Bind existing Policy / Group / User`
|
|
6. Select `Policy` and choose the one created before
|
|
7. Ensure the failure result is set as `Don't pass`
|
|
8. Click on `Create`
|
|
|
|
### End
|
|
|
|
Now, if you've managed to not lock you out of your own Authentik instance, admin interface and admin login should be allowed from internal network only.
|
|
|
|
Would that suffice for feeling safe? Not at all. But it should at least be a valid starting point! |