Clever Geek Handbook

Die Magie von 2 Zeilen in Lua oder wie die ursprünglichen HTTP-Autorisierungsheader-Autorisierungsheader an den Webdienst übertragen werden

Der Artikel wird nützlich sein für:



  • Wer muss mehrere Arten von Autorisierung in einer Anfrage an den Server verwenden?
  • Wer möchte die Dienste der Kubernetes / Docker-Welt für das allgemeine Internet öffnen, ohne darüber nachzudenken, wie ein bestimmter Dienst geschützt werden kann?
  • denkt, dass alles bereits von jemandem gemacht wurde und möchte die Welt ein wenig bequemer und sicherer machen.


Vorwortdienste



, die über Kubernetes bereitgestellt werden, verfügen über eine Vielzahl von Autorisierungsmethoden. Einer der modischeren ist der Authorization: Bearer- Header - zum Beispiel: JWT-Autorisierung ( JSON Web Token ) mit der Übertragung vieler Schlüssel und damit Werte in einem Header. Es gibt auch Basisberechtigungen, beispielsweise für die Registrierung (Docker Image Repository). Diese Autorisierung verwendet keine Cookies und wird vom Browser automatisch (mit Ausnahme von Safari - es gibt Nuancen, die wir noch nicht entschieden haben) zu allen Anfragen an den Server hinzugefügt.







Problem 1:



Ich kann mich nicht über Firefox & Safari in der Storage OS-Oberfläche anmelden, der Loader wird angezeigt und das wars.



Mini-Hypothese:



Proxy-Problem. Eine schnelle Überprüfung ergab das Ergebnis: Wenn die Autorisierung ohne Proxy erfolgt (universeller sicherer Zugriff über ein Zertifikat), funktioniert alles. Also, was ist der Deal?



Nach der Analyse des Netzwerkstapels haben wir festgestellt, dass der Autorisierungsheader verwendet wird. Bei der Konfiguration des Proxys von Rancher-Diensten wurde jedoch früher festgestellt, dass dieser Header an den Proxy-Dienst übergeben wird und die Autorisierungsdaten für das Zertifikat enthält. Daher wurde beschlossen, ihn nach Abschluss des Autorisierungsprozesses einfach zu löschen (FakeBasicAuth) ).



Problem 2:



Auf vielen Webservern wird die Autorisierung persönlicher Zertifikate durch Emulation der Basisautorisierung implementiert (was tatsächlich die Benutzeranforderung stört), wahrscheinlich um Änderungen im Hauptcode des Webservers zu reduzieren. Diese Methode heißt FakeBasicAuth. Nach dem Festlegen eines solchen Headers überschreibt der Webserver den vom Benutzer stammenden Autorisierungsheader.



Hypothesen:



  1. Der Umfang des FakeBasicAuth-Headers kann noch weiter eingeschränkt werden, sodass der ursprüngliche Header für die Übertragung an die Proxy-Ressource wiederhergestellt wird, sodass nur der ursprüngliche Header, falls vorhanden, übertragen wird.
  2. Der Bereich des Authorization-Headers kann so gestaltet werden, dass der Header vor dem Aktivieren des FakeBasicAuth-Mechanismus gespeichert und anschließend wiederhergestellt wird.


Sichtbarer Status - Zweck: Das



Speicherbetriebssystem autorisiert, dass Sie diesen Dienst konfigurieren können, während Sie einen einheitlichen Ansatz für die Bereitstellung von Diensten für das externe Internet beibehalten.



Zusätzliches Ziel:



Einheitlicher, schneller und sicherer http-Zugriff unter Beibehaltung der Funktionalität aller möglichen http-Dienste (z. B. REST-API für eine mobile Anwendung oder Registry Docker).



Wie zu überprüfen?



  • Docker Login registry-rancher.xxx.ru - mit Schlüsseln und Login / Passwort.
  • storageos-rancher.xxx.ru/#/login - Verwenden von Login und Passwort von Configs Secret Rancher.xxx.ru/p/c-84bnv : p-qj9qm / Secrets / Kubesystem: Init-Secr ... (funktioniert nicht in Safari ).
  • registry-ui-rancher.xxx.ru - mit einem Browser und Login / Passwort aus der Registry. Für diejenigen, die sorgfältig lesen, der Trick: Sie können diese Schnittstelle anstelle der Standard-Docker-Anmeldung registry-rancher.xxx.ru verwenden - es gibt einen integrierten Proxy für die Registrierung.


Testen von Hypothesen:



1. Versuchen wir auf der Grundlage früherer Erfahrungen, im Internet einen Weg für solche Anforderungen zu finden: Apache-Authentifizierung external basic via cert.



Es gab einen mehr oder weniger angemessenen Artikel über ldap . Auf diese Weise: 



RewriteEngine on
RewriteCond %{IS_SUBREQ} ^false$
RewriteCond %{LA-U:REMOTE_USER} (.+)
RewriteRule . - [E=RU:%1]
RequestHeader set REMOTE_USER %{RU}e


Und geben Sie dann den Titel in zusätzlichen Überschriften durch die Konstruktion 



RequestHeader add Authorization "expr=%{env:zt-auth-before}" "expr=%{env:zt-auth-before} =~/.{1,}/"


Leider impliziert diese Konstruktion nicht die Erstellung eines identischen Headers, des Headers der Benutzeranforderung, und env wird falsch gebildet.



Daher erwies sich die auf der Standardumschreibung basierende Methode als nutzlos und kompliziert.



2. Wenn wir dies nicht standardmäßig tun können, müssen wir uns an lua wenden. Wir haben zuvor gesehen, dass es Anforderungsverarbeitungsblöcke gibt, die ausgeführt werden, bevor Zertifikate verarbeitet werden. Sehen Sie sich das Flussdiagramm aus dem Artikel lua_load_resty_core und der Anweisung module_lua_writinghooks mit der frühen Konstruktion erneut an.



Es stellt sich heraus, dass wir dasselbe Skript verwenden können ( wie wir bei ZeroTech Freunde von Apple Safari und Client-Zertifikaten mit Websockets gefunden haben), um den Authorization-Header beizubehalten, bevor er durch FakeBasicAuth ersetzt wird. 







LuaHookAccessChecker /usr/local/etc/apache24/sslincludes/websocket_token.lua handler early


In Lua sieht es jetzt so aus: 




require 'apache2'

function handler(r)
        local fmt = '%Y%m%d%H%M%S'
        local timeout = 3600 -- 1 hour
        local auth = r.headers_in['Authorization']

        r.notes['zt-cert-timeout'] = timeout
        r.notes['zt-cert-date-next'] = os.date(fmt,os.time()+timeout)
        r.notes['zt-cert-date-halfnext'] = os.date(fmt,os.time()+ (timeout/2))
        r.notes['zt-cert-date-now'] = os.date(fmt,os.time())

        if auth ~= nil then
                r.notes['zt-auth-before'] = auth
        end

        return apache2.OK
end


Hinweis:



Neue Konstruktionen sind fett gedruckt. Und da wir wissen, dass die von Lua erhaltene env nur für Ausdrucksausdrücke verfügbar ist, fügen wir neben der Verschlüsselung des zt-cert-Tokens eine Konstruktion hinzu:



# ausgehende Cookies für den Benutzer 




Header set Set-Cookie "expr=zt-cert=%{sha1:...


# Überschriften an den Proxy-Dienst übergeben 




RequestHeader add Authorization "expr=%{env:zt-auth-before}" "expr=%{env:zt-auth-before} =~/.{1,}/"


Die Verfügbarkeit von Daten für die Übertragung an den Dienst wurde überprüft, indem Daten an den Benutzer zurück an den Browser übertragen wurden: 



Header add Authorization "expr=%{env:zt-auth-before}" "expr=%{env:zt-auth-before} =~/.{1,}/"


Das Interessanteste dabei ist, das Vorhandensein von Daten zu überprüfen, um den Header nicht an den Proxy-Dienst zu übertragen, wenn er nicht von außerhalb des Browsers des Benutzers stammt. Der zweite Teil der Konstruktion ist dafür verantwortlich: 



"expr=%{env:zt-auth-before} =~/.{1,}/"


Fertigstellung:



Im Internet gibt es derzeit keine vorgefertigten Lösungen. Es wurden ungefähr drei Stunden damit verbracht, die Variationen zu suchen und zu testen, weil ich das Rad nicht "neu erfinden" wollte.



Es wurden 5 Zeilen hinzugefügt, von denen 3 sicher entfernt werden können. Was denkst du? - Schreiben Sie Ihre Antwortmöglichkeiten in die Kommentare zum Artikel.



Ich wollte nicht über diese Erfahrung schreiben, da es sich tatsächlich nur um 2 Zeilen handelt und der Autorisierungsheader den Adressaten erreicht, aber ich habe mich trotzdem entschlossen, die Informationen weiterzugeben, da er einen guten Wissensspeicher aus früheren Untersuchungen zu Zertifikaten verwendet (in diesem Artikel geht es um diesen Artikel ). Darüber hinaus gibt es kaum Draufgänger, etwas Eigenes und so Einfaches in einer unbekannten Sprache zu schreiben.





More articles:


All Articles