Add a dedicated TinyAuth section to Uptime-Kuma
This commit is contained in:
Djeex
@@ -1,21 +1,10 @@
|
||||
---
|
||||
title: Uptime-Kuma
|
||||
description: Install Uptime-Kuma to monitor your self-hosted services uptime, set up alerts, and optionally protect the dashboard with Authentik.
|
||||
description: Install Uptime-Kuma to monitor your self-hosted services uptime, set up alerts, and optionally protect the dashboard with Tinyauth or Authentik
|
||||
---
|
||||
|
||||
|
||||
:ellipsis{left=0px width=40rem top=10rem blur=140px zIndex=60}
|
||||
# Uptime-Kuma
|
||||
|
||||
::note
|
||||
🎯 __Goals:__
|
||||
|
||||
- Install and deploy Uptime-Kuma
|
||||
- Expose Uptime-Kuma
|
||||
- (Optional) Protect Uptime-Kuma with Authentik
|
||||
::
|
||||
|
||||
[Uptime-Kuma](https://github.com/louislam/uptime-kuma) is a container dedicated to service monitoring. The principle is to regularly send requests to your services to determine if they are online, and alert you if not. Uptime-Kuma is developed by the same developer as Dockge.
|
||||
|
||||
|
||||
|
||||
@@ -30,6 +19,9 @@ root
|
||||
└── compose.yaml
|
||||
```
|
||||
|
||||
::steps{level="3"}
|
||||
### Deploy the stack
|
||||
|
||||
Open Dockge, click on `compose`, name the stack `uptime-kuma`, then copy and paste the following:
|
||||
|
||||
```yaml [compose.yaml]
|
||||
@@ -46,6 +38,7 @@ services:
|
||||
- 3200:3001 # <Host Port>:<Container Port>
|
||||
restart: always
|
||||
```
|
||||
|
||||
::tip{icon=""}
|
||||
✨ __Tip:__ Add the Watchtower label to each container to automate updates
|
||||
|
||||
@@ -56,8 +49,11 @@ services:
|
||||
labels:
|
||||
|
||||
- com.centurylinklabs.watchtower.enable=true
|
||||
```
|
||||
::
|
||||
|
||||
### Access the web UI
|
||||
|
||||
You can now access the tool via `http://yourserverip:3200`.
|
||||
|
||||
::caution
|
||||
@@ -65,9 +61,11 @@ You can now access the tool via `http://yourserverip:3200`.
|
||||
__If it fails:__ check your firewall rules.
|
||||
::
|
||||
|
||||
### Done !
|
||||
::
|
||||
|
||||
## Expose with Swag
|
||||
---
|
||||
::note
|
||||
::note{icon=""}
|
||||
📋 __Before you begin:__
|
||||
<br/><br/>
|
||||
We assume you have the subdomain `stats.mydomain.com` with a `CNAME` pointing to `mydomain.com` in your [DNS zone](/general/networking/dns). And of course, [unless you're using Cloudflare Zero Trust](/serveex/security/cloudflare), port `443` of your router should point to port `443` of your server via [NAT rules](/general/networking/nat).
|
||||
@@ -75,9 +73,12 @@ We assume you have the subdomain `stats.mydomain.com` with a `CNAME` pointing to
|
||||
|
||||
::warning
|
||||
|
||||
Uptime-Kuma does not use multi-factor authentication. Exposing Uptime-Kuma on the internet could compromise the machines it monitors. Only do this if you're using an MFA system like [Authentik](/serveex/advanced/authentik/). Otherwise, don’t expose it with SWAG; use a VPN like [Wireguard](/serveex/security/wireguard) instead.
|
||||
Uptime-Kuma does not use multi-factor authentication. Exposing Uptime-Kuma on the internet could compromise the machines it monitors. Only do this if you're using an MFA system like [TinyAuth](/serveex/security/tinyauth) or [Authentik](/serveex/advanced/authentik/). Otherwise, don’t expose it with SWAG; use a VPN like [Wireguard](/serveex/security/wireguard) instead.
|
||||
::
|
||||
|
||||
::steps{level="3"}
|
||||
### Create the subdomain.conf file
|
||||
|
||||
In the Swag folders, create the `stats.subdomain.conf` file.
|
||||
|
||||
::tip{icon=""}
|
||||
@@ -143,6 +144,8 @@ server {
|
||||
|
||||
Press :kbd{value="Ctrl+O"}, then :kbd{value="Enter"} to save, and :kbd{value="Ctrl+X"} to exit.
|
||||
|
||||
### Add Uptime-Kuma's network to SWAG
|
||||
|
||||
In Dockge, edit the SWAG compose and add the Uptime-Kuma network:
|
||||
|
||||
```yaml [compose.yaml]
|
||||
@@ -169,19 +172,85 @@ Restart the stack and wait until SWAG is fully operational.
|
||||
Here we assume that the network name of Uptime-Kuma is `uptime-kuma_default`. You can verify the connection by visiting SWAG's dashboard at `http://yourserverip:81`.
|
||||
::
|
||||
|
||||
### Done !
|
||||
::
|
||||
|
||||
That's it! Uptime-Kuma is now exposed, and you can access it via `https://stats.mydomain.com`.
|
||||
|
||||
::tip{icon=""}
|
||||
✨ __Tip:__
|
||||
<br/><br>
|
||||
You can protect this app with [TinyAuth](/serveex/security/tinyauth) and [Pocket ID](/serveex/security/pocket-id) using the reverse-proxy pattern from the TinyAuth guide, or with Authentik by opening `stats.subdomain.conf` and uncommenting the lines:
|
||||
`include /config/nginx/authentik-server.conf;`
|
||||
and
|
||||
`include /config/nginx/authentik-location.conf;`.
|
||||
Don’t forget to [create an application and provider in Authentik](/serveex/advanced/authentik#protecting-an-app-via-reverse-proxy). If you want the public stats page to be accessible without authentication:
|
||||
## Protecting Uptime-Kuma with TinyAuth
|
||||
[TinyAuth](/serveex/security/tinyauth) can sit in front of Uptime-Kuma the same way as any other app, but here we also want the public status page (and the assets it needs to render) to stay reachable without logging in. This uses the same `location` regex technique as [Leaving specific paths public](/serveex/security/tinyauth#leaving-specific-paths-public), applied directly to `stats.subdomain.conf`.
|
||||
|
||||
- Edit the Uptime-Kuma provider
|
||||
- In *Advanced Protocol Settings > Authenticated Paths*, enter:
|
||||
::steps{level="3"}
|
||||
### Open the subdomain.conf file
|
||||
|
||||
```bash [Terminal]
|
||||
sudo nano /docker/swag/config/nginx/proxy-confs/stats.subdomain.conf
|
||||
```
|
||||
|
||||
### Add the forward-auth check and public paths
|
||||
|
||||
Replace the file's content with the following. The `location ~ ^/(...)` block matches Uptime-Kuma's public status page and its assets, and is served directly, without ever reaching the `auth_request` check in `location /`:
|
||||
|
||||
```nginx [stats.subdomain.conf]{9-16,32-33}
|
||||
server {
|
||||
listen 443 ssl;
|
||||
listen [::]:443 ssl;
|
||||
|
||||
server_name stats.*;
|
||||
|
||||
include /config/nginx/ssl.conf;
|
||||
|
||||
location ~ ^/(status|assets|icon\.svg|api|upload|metrics) {
|
||||
include /config/nginx/proxy.conf;
|
||||
include /config/nginx/resolver.conf;
|
||||
set $upstream_app uptime-kuma;
|
||||
set $upstream_port 3001;
|
||||
set $upstream_proto http;
|
||||
proxy_pass $upstream_proto://$upstream_app:$upstream_port;
|
||||
}
|
||||
|
||||
location /tinyauth {
|
||||
internal;
|
||||
proxy_pass http://tinyauth:3000/api/auth/nginx;
|
||||
proxy_pass_request_body off;
|
||||
proxy_set_header Content-Length "";
|
||||
proxy_set_header X-Forwarded-Proto $scheme;
|
||||
proxy_set_header X-Forwarded-Host $http_host;
|
||||
proxy_set_header X-Forwarded-Uri $request_uri;
|
||||
}
|
||||
|
||||
location @tinyauth_login {
|
||||
return 302 https://tinyauth.mydomain.com/login?redirect_uri=$scheme://$http_host$request_uri;
|
||||
}
|
||||
|
||||
location / {
|
||||
auth_request /tinyauth;
|
||||
error_page 401 = @tinyauth_login;
|
||||
|
||||
include /config/nginx/proxy.conf;
|
||||
include /config/nginx/resolver.conf;
|
||||
set $upstream_app uptime-kuma;
|
||||
set $upstream_port 3001;
|
||||
set $upstream_proto http;
|
||||
proxy_pass $upstream_proto://$upstream_app:$upstream_port;
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
::note
|
||||
|
||||
The `location /tinyauth` block must be able to reach the TinyAuth container by its Docker name (`tinyauth` here). Add TinyAuth's network to this stack's compose file the same way you did [for Swag](/serveex/security/tinyauth#exposing-tinyauth-with-swag) if it isn't already attached.
|
||||
::
|
||||
|
||||
Press :kbd{value="Ctrl+O"}, then :kbd{value="Enter"} to save, and :kbd{value="Ctrl+X"} to exit.
|
||||
|
||||
### Done !
|
||||
::
|
||||
|
||||
Redeploy the stack. Uptime-Kuma will then be publicly reachable via `https://stats.mydomain.com`, with the status page open and everything else behind TinyAuth.
|
||||
|
||||
::tip{icon=""}
|
||||
✨ __Tip:__ You can also protect this app with [Authentik](/serveex/advanced/authentik) instead: open `stats.subdomain.conf` and uncomment the lines `include /config/nginx/authentik-server.conf;` and `include /config/nginx/authentik-location.conf;`. Don’t forget to [create an application and provider in Authentik](/serveex/advanced/authentik#protecting-an-app-via-reverse-proxy). Then edit the Uptime-Kuma provider, and under *Advanced Protocol Settings > Authenticated Paths*, enter:
|
||||
|
||||
```properties
|
||||
^/$
|
||||
@@ -191,13 +260,10 @@ Don’t forget to [create an application and provider in Authentik](/serveex/adv
|
||||
^/icon.svg
|
||||
^/api/.*
|
||||
^/upload/.*
|
||||
^/metrics
|
||||
^/metrics
|
||||
```
|
||||
::
|
||||
|
||||
Redeploy the stack.
|
||||
|
||||
Uptime-Kuma will then be publicly reachable via `https://stats.mydomain.com`.
|
||||
|
||||
::tip{icon=""}
|
||||
✨ __Tip:__ If you're using Authentik and don't mind exposing the admin panel to your local network, you can disable Uptime-Kuma's native authentication in its settings and rely solely on Authentik.
|
||||
✨ __Tip:__ If you're using [TinyAuth](/serveex/security/tinyauth) or [Authentik](/serveex/advanced/authentik) and don't mind exposing the admin panel to your local network, you can disable Uptime-Kuma's native authentication in its settings and rely solely on whichever one is protecting it.
|
||||
::
|
||||
|
||||
Reference in New Issue
Block a user