Docker - Authelia - Nginx Proxy Manager

  • Hallo,


    auf einem Ubuntu 24.0.4 Server laufen div. Docker Dienste, die hinter dem Nginx Proxy Manager erreichbar sind. Aktuell ist alles noch in einer nicht öffentlich zugänglichen Umgebung.

    Zur weiteren Sicherheit möchte ich diese Dienste mit Authelia absichern, ist auch als Container schon installiert.

    Mit der Konfiguration klappt es aber noch nicht richtig. Habe mich an dieser Anleitung und den Dokumenten dazu orientiert:

    https://www.youtube.com/watch?v=4UKOh3ssQSU


    Mittlerweile scheinen sich aber Parameter Bezeichnungen in den conf Dateien geändert zu haben, die Authelia logs werfen unzählige errors und Hinweise.


    Hat jemand eine Quelle für aktuelle conf Dateien, die man anpassen kann?


    Weitere Frage: Wenn ich jetzt single factor oder dual factor bei Authelia einstelle. Ist das dann für jeden mit Authlia gesicherten Dienst aus dem NPM der gleich User/ PW bzw. das gleiche OTP?

    Ich würde gerne, wenn es dann läuft jedem Dienst individuelle User/ PW bzw OTPs verpassen. Geht das?


    Danke für Hinweise und Feedback

  • Ja, du kannst für jede Domain anpassen. Eine gute Anleitung findest du z.B. hier: https://thehomelab.wiki/books/…-with-nginx-proxy-manager


    In der authelia Konfiguration sieht das dann z.B. so aus:

    Code
    access_control:
      default_policy: deny
      rules:
        - domain: # Proxies only requiring username and password
            - "homer.yourdomain.com"
          policy: one_factor
        - domain: # Proxies needing 2 factor below
            - "proxmox.yourdomain.com"
          policy: two_factor
  • Ein IDM bzw. SSO ist generell keine so einfache Geschichte. Damit muss man sich sowieso etwas auseinandersetzen. Da ist so eine Debugging Session in der Config durchaus hilfreich. Den Lerneffekt kann man da ruhig mitnehmen. Daher versuche es ruhig mal. Viel Erfolg.

  • Hast Du Authelia in der neusten Version laufen? Funktioniert es? Dann wäre ich zum Abgleich mal an Deiner Conifguration interessiert. Einiege Fehler hab ich wegbekommen, einige nicht. Liegt vermutlich daran, dass in den Anleitungen verwendete Parameter in der neuesten Version anders sind, bzw. es diese nicht mehr gibt.

  • Ich selbst habe aktuell kein Authelia im Einsatz. Ist auch schon etwas her, dass ich das mal als PoC getestet habe. Daher kann ich gerade nicht mit einem praktischen Beispiel dienen. Im Authelia Github Repo selbst sind aber ein paar Beispiel Konfigurationen. Vielleicht helfen die dir auch schon weiter: https://github.com/authelia/au…uthelia/configuration.yml


    Was hast du denn bisher gemacht? Generell lohnt es sich ja mit einer minimalen Konfig zu starten und dann nach und nach die Punkte hinzuzufügen, die man haben möchte.

  • Hier die Infos:


    Configuration.yml


    users_database.yml

    Advanced Tab im NPM auf dem Authelia host:

  • Jetzt fehlen nur noch die Fehlermeldungen, die du erhältst. Das würde uns noch weiterhelfen.


    Generell solltest du im immer das "latest" Tag vermeiden. Das ist in der Regel die Development Version, die meist fehlerbehaftet und nicht für produktive Umgebungen gedacht ist. Auch nicht für einen PoC oder eine Testumgbung. Sonst weißt du nie, welche Version du gerade im Einsatz hast. Dieser Hinweis gilt im Allgemeinen für sämtliche Container - auch wenn man das sehr häufig in Howtos und Dokumentationen liest.


    Ersetze daher unabhängig der Konfiguration mal das authelia/authelia:latest durch ein authelia/authelia:4.38.16 (Das ist die aktuell stabile Version).

  • Generell solltest du im immer das "latest" Tag vermeiden. Das ist in der Regel die Development Version, die meist fehlerbehaftet und nicht für produktive Umgebungen gedacht ist.

    Also meine Erfahrung ist da eine andere. „latest“ zeigt bei allen von mir genutzten Images immer auf die neuste produktive Version. So ist’s auch bei authelia/authelia.

    Hättest du mal ein Beispiel, wo das nicht so ist?


    Generell bin ich aber auch ein Freund davon die genaue Version mit anzugeben.

    RS Brezn | VPS 500 G8 Plus | 2× VPS Karneval 2020 | VPS Pocket Admin | RS Cyber Quack | VPS 500 ARM


    Dieses Gebäude hat mir die Vorfahrt genommen! *hup*

  • Bei meinen eigenen Containern, die ich selbst gebaut habe, war das meist so ;) . Vielleicht hat sich das mittlerweile auch etwas gebessert. Aber gerade früher war das latest Tag immer das letzte Image, das in die Registry gepusht wurde. Durch die CI Pipelines war das dann oft eben die Development Version oder wenn man Glück hatte eine alpha oder beta Version der Applikation.


    Das Problem ist dann auch eher, das man später nicht mehr sieht, welche Version gerade läuft, wenn man nicht gerade den Hash Wert des Images überprüft. Wenn man heute ein Deployment mit latest macht, in 2 Wochen dann nochmal, hat man in der Regel eine komplett andere Version. Hat man z.B. einen postgres Container, den man vor kurzem mit dem latest Tag deployed hat, der dann in Version 16.x initialisiert wurde und macht jetzt einfach sein normales Updates, dann würde der jetzt in Version 17.x gestartet werden. Bei postgres schlägt das aber fehl, wenn man da keine manuelle Datenmigration macht. Obwohl sich im docker-compose File nichts geändert hat, steht man auf einmal vor einem kaputten Deployment, weil der DB Container nicht mehr startet. Daher sollte man immer nur Tags verwenden, die klar zeigen, welche Version damit gemeint ist.

  • Also ich habe bei allen Containern "latest". Keine Probleme, zumal auch Watchtower nur mit "latest" updated.


    Also das Problem, dass ich Authelia gar nicht aufrufen konnte, habe ich lösen können. Es gehört die IP vom Container rein, nicht die öffentliche des Servers.

    Aber den zu schützenden Service, kann ich trotz jetzt richtiger IP nicht aufrufen:


  • Die Fehlermeldung sagt ja im Grunde nur, dass der Zugriff ohne Login blockiert wird (<anonymous>). Bist du denn in Authelia angemeldet? Du kommt vermutlich gar nicht zum Login Screen, wenn du die Seite aufrufst? Hast du denn für diese Seite (speed.domain.de) eine entsprechende nginx configuration vorgenommen?

  • Super, dass es jetzt geht!

    Logge ich mich dagegen zuerst auf a.domain.de ein, und gehe dann auf speed.domain.de ist kein login mehr erforderlich. Ist das das korrekte Verhalten?

    Ja. Genau das ist ja die Idee hinter einem SSO. Falls du ein anderes Verhalten möchtest, müsstest du für jede App andere User bzw. Gruppen nutzen und dann die User nur für die bestimmte App zulassen (Stichwort Subject: https://www.authelia.com/confi…/security/access-control/).

  • Danke. Ok verstanden.


    Würde denn ein login auf a.domain.de am PC dazu führen, dass ich mich vom z.B. iPhone nicht mehr auf speed.domain.de einloggen muss?


    Wenn ich Dich richtig verstanden habe, muss ich wenn jedem Service einen anderen Login geben will, jeweils einen eigenen Nutzer anlegen, damit die Services unabhängig von einander sind.

    Woher weiß dann z.b. dienst2.domain.de, dass er ejtzt nicht mehr auf die Zugangsdaten von "Dienst1 reagieren" soll? Wo geben ich den an, welcher user für welchen Dienst erlaubt ist? Das hab ich noch nicht verstanden.


    Die Servcies, die mit one factor laufen sollen, gehen jetzt schon mal. Bei two factor Services habe ich jetzt noch "offline" im NPM beim entsrepchenden host stehen, obwohl eine entsprechende advanced config hinterlegt ist.

  • Hatte Deinen Link nicht gesehen. Ich hab jetzt einfach mal ChatGPT nach einer Beispiel Config für die Anzahl meiner Services und User gefragt. Dann hab ich schon mal die korrekte Struktur .Das leg ich mir jetzt mal neben dran und prüfe Schritt für Schritt was da gemacht wird und was ich wie umsetzen muss.

  • So es funktioniert jetzt alles wie es soll.

    Ein Tipp der anderen vll. hilft:

    keine Container Namen mit "-" oder "_" erstellen oder erstellen lassen. Das funktioniert zwar mit dem NPM, aber sobald man dort die Authelia Erweiterung einträgt und konfguriert funktioniert es nicht mehr. Hat etwas gedauert, bis ich das rausgefunden habe