New post 'Block Authentik admin user access from the Internet'
This commit is contained in:
@@ -1,27 +1,78 @@
|
|||||||
---
|
---
|
||||||
title: "Block Authentik admin user access from the Internet"
|
title: "Block Authentik admin user access from the Internet"
|
||||||
tags: ["authentik", "security"]
|
tags: ["authentik", "sso", "idp", "admin"]
|
||||||
categories: ["recipe", "security"]
|
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"
|
author: "Ettore Dreucci"
|
||||||
draft: true
|
draft: false
|
||||||
---
|
---
|
||||||
|
|
||||||
## How to restrict Authentik admin access from internal networks only
|
## 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.
|
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
|
### 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.
|
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.
|
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
|
#### 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
|
### Limit admin access
|
||||||
|
|
||||||
#### Prevent admin login from outside local networks
|
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!
|
Reference in New Issue
Block a user