ettore.dreucci/ettore.dreucci.it
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

New post 'Block Authentik admin user access from the Internet'

Browse Source
This commit is contained in:
Ettore Dreucci
2025-10-13 00:03:19 +02:00
parent f738cd3812
commit 01b12cac22
1 changed files with 57 additions and 6 deletions
Download Patch File Download Diff File Expand all files Collapse all files

61
content/blog/authentik-block-akadmin-internet.md
View File

@@ -1,27 +1,78 @@
---
title: "Block Authentik admin user access from the Internet"
tags: ["authentik", "security"]
tags: ["authentik", "sso", "idp", "admin"]
categories: ["recipe", "security"]
date: 2025-03-01T01:06:12+01:00
description: How to restrict Authentik admin access from internal networks only
date: 2025-10-13T00:00:00+02:00
author: "Ettore Dreucci"
draft: true
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.
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 preventing sunday morning phone calls.
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!