Djeex/docudjeex
1
1
Fork 0
Code Issues Pull Requests Projects Wiki Activity

Fully translated + good linking

Browse Source
This commit is contained in:
Djeex
2025-07-04 13:37:55 +00:00
parent e9ccda2e14
commit 5c207add10
32 changed files with 435 additions and 469 deletions
Download Patch File Download Diff File Expand all files Collapse all files

20
content/3.serveex/3.securite/2.authentik.md
View File

@ -197,7 +197,7 @@ To use Authentik outside your local network, you must expose it.
::alert{type="info"}
📋 __Prerequisites:__ <br/><br/>
We assume you have already created a subdomain like `auth.mydomain.com` in your [DNS zone](/generalites/dns), with a CNAME pointing to `mydomain.com`. Also, unless you're using [Cloudflare Zero Trust](/serveex/securite/cloudflare), you must have already forwarded port `443` from your router to port `443` of your server in your [NAT rules](/generalites/nat).
We assume you have already created a subdomain like `auth.mydomain.com` in your [DNS zone](/general/dns), with a CNAME pointing to `mydomain.com`. Also, unless you're using [Cloudflare Zero Trust](/serveex/securite/cloudflare), you must have already forwarded port `443` from your router to port `443` of your server in your [NAT rules](/general/nat).
::
Open the `authentik-server.conf` file:
@ -363,14 +363,14 @@ Your new architecture looks like this:
## Protecting a Remote Server Service
---
For a [native application](/serveex/securite/authentik#protéger-une-app-native) (via OAuth 2.0 or other), nothing changes.
For a [native application](/serveex/securite/authentik/#protecting-a-native-app) (via OAuth 2.0 or other), nothing changes.
For a non-native app behind a reverse proxy, you must deploy an __Outpost__. An Outpost is a container acting as a local proxy — it's the target of your app's auth requests and the only one authorized to communicate with your Authentik API.
::alert{type="info"}
Prerequisites:
- Install [Docker](/serveex/coeur/docker) on the remote server hosting the service.
- If the app has no native integration, use a compatible reverse proxy. We will use [SWAG](/serveex/coeur/swag) here.
- Install [Docker](/serveex/core/docker) on the remote server hosting the service.
- If the app has no native integration, use a compatible reverse proxy. We will use [SWAG](/serveex/core/swag) here.
::
This container will forward requests to your main [Authentik](/serveex/securite/authentik#authentik) instance over the internet (or your local network). The server will perform checks and respond to the Outpost, which will allow or block access accordingly.
@ -379,7 +379,7 @@ This container will forward requests to your main [Authentik](/serveex/securite/
### Configuring Authentik
Create your [providers and applications](/serveex/securite/authentik#protéger-une-app-native) as shown earlier.
Create your [providers and applications](/serveex/securite/authentik/#protecting-a-native-app) as shown earlier.
Then, in the admin panel, go to _Applications > Outposts_, and create a new outpost.
@ -413,11 +413,11 @@ On the list of created outposts, locate the new one and click _Show details_ at
### Configuring the Remote Machine
We assume you’ve already installed [Docker](/serveex/coeur/docker) and [SWAG](/serveex/coeur/swag) on this remote machine.
We assume you’ve already installed [Docker](/serveex/core/docker) and [SWAG](/serveex/core/swag) on this remote machine.
On your remote machine, use [Dockge](/serveex/coeur/docker/#installer-dockge-pour-gérer-et-déployer-les-conteneurs) to create a stack named `authentik-outpost`.
On your remote machine, use [Dockge](/serveex/core/docker/#installer-dockge-pour-gérer-et-déployer-les-conteneurs) to create a stack named `authentik-outpost`.
If you haven’t installed [Dockge](/serveex/coeur/docker/#installer-dockge-pour-gérer-et-déployer-les-conteneurs), create a folder `/docker/authentik-outpost`, or directly via command line:
If you haven’t installed [Dockge](/serveex/core/docker/#installer-dockge-pour-gérer-et-déployer-les-conteneurs), create a folder `/docker/authentik-outpost`, or directly via command line:
```shell
sudo mkdir -P /docker/authentik-outpost
@ -486,7 +486,7 @@ Press `Esc`, then type `:x` and press `Enter` to save and exit.
:::
::
If using [Dockge](/serveex/coeur/docker/#installer-dockge-pour-gérer-et-déployer-les-conteneurs), restart SWAG.
If using [Dockge](/serveex/core/docker/#installer-dockge-pour-gérer-et-déployer-les-conteneurs), restart SWAG.
Otherwise, via terminal:
@ -547,7 +547,7 @@ proxy_pass http://$upstream_authentik:9000;
Save and exit with `Esc`, then `:x` and `Enter`.
Then configure the applications to protect as you did on your main server, whether they are [native](/serveex/securite/authentik#protéger-une-app-native) or protected via [reverse proxy](/serveex/securite/authentik#protéger-une-app-par-reverse-proxy).
Then configure the applications to protect as you did on your main server, whether they are [native](/serveex/securite/authentik/#protecting-a-native-app) or protected via [reverse proxy](/serveex/securite/authentik#protecting-an-app-via-reverse-proxy).
## Migrating an Authentik Database
---

8
content/3.serveex/3.securite/3.cloudflare.md
View File

@ -21,7 +21,7 @@ main:
---
The _Zero Trust_ architecture is the practice of designing systems based on the principle of __"never trust, always verify"__, as opposed to the traditional principle of __"trust, but verify"__. This concept has become increasingly popular recently due to the growing number of attacks targeting user data. It’s a broad concept, but we’ll focus on how to apply _Zero Trust_ to the web services we host.
_Cloudflare tunnels_ offer a simple way to implement _Zero Trust_, using [SWAG](/serveex/coeur/swag) and [Authentik](/serveex/securite/authentik).
_Cloudflare tunnels_ offer a simple way to implement _Zero Trust_, using [SWAG](/serveex/core/swag) and [Authentik](/serveex/securite/authentik).
Simply put, Cloudflare Tunnels allow you to:
@ -46,7 +46,7 @@ Here we’ll explain how to integrate SWAG with Cloudflare tunnels.
---
### DNS Zone
First, you need to set Cloudflare as your [DNS zone](/generalites/dns) manager. If you bought your domain from Cloudflare, that’s already done. Otherwise, check with your registrar how to add external DNS servers. Cloudflare provides [step-by-step documentation](https://developers.cloudflare.com/dns/zone-setups/full-setup/setup/) on how to configure a DNS Zone, whether your domain is external or registered with Cloudflare.
First, you need to set Cloudflare as your [DNS zone](/general/dns) manager. If you bought your domain from Cloudflare, that’s already done. Otherwise, check with your registrar how to add external DNS servers. Cloudflare provides [step-by-step documentation](https://developers.cloudflare.com/dns/zone-setups/full-setup/setup/) on how to configure a DNS Zone, whether your domain is external or registered with Cloudflare.
If you only have one server to protect behind Cloudflare, you can delete all existing DNS records. By default, your domain and all its subdomains will be redirected to the tunnel.
@ -214,10 +214,10 @@ TUNNEL_PW=
Once done, deploy the stack. Check the logs—you should reach `server ready`.
Then confirm your tunnel appears under _Networks > Tunnels_ in [Cloudflare Zero Trust](https://one.dash.cloudflare.com/). By default, all subdomains will be routed through the tunnel—no need to define them [in your DNS zone](/generalites/dns).
Then confirm your tunnel appears under _Networks > Tunnels_ in [Cloudflare Zero Trust](https://one.dash.cloudflare.com/). By default, all subdomains will be routed through the tunnel—no need to define them [in your DNS zone](/general/dns).
::alert{type="success"}
✨ __Tip:__ If you want to expose a service without a tunnel, just define an A record [in your DNS zone](/generalites/dns). If resolution fails, disable the proxy function for that record—e.g., for `sub.mondomaine.fr`.
✨ __Tip:__ If you want to expose a service without a tunnel, just define an A record [in your DNS zone](/general/dns). If resolution fails, disable the proxy function for that record—e.g., for `sub.mondomaine.fr`.
![dns](/img/serveex/cf-dns.png)
::