La magie de 2 lignes dans Lua, ou comment transmettre les en-têtes d'autorisation HTTP Authorization originaux au service Web

L'article sera utile à ceux:

• qui doit utiliser plusieurs types d'autorisation dans une seule demande au serveur;
• qui veut ouvrir les services du monde Kubernetes / Docker à l'Internet général, sans réfléchir à la manière de protéger un service particulier;
• pense que tout a déjà été fait par quelqu'un et aimerait rendre le monde un peu plus pratique et plus sûr.

Avant-propos Les



services mis à disposition via Kubernetes disposent d'un riche ensemble de méthodes d'autorisation. L'un des plus à la mode est l'en-tête Authorization: Bearer - par exemple: autorisation JWT ( JSON Web Token ) avec le transfert de nombreuses clés, et donc de valeurs, dans un en-tête. Il existe également des autorisations de base, par exemple pour le registre (référentiel d'images Docker). Cette autorisation n'utilise pas de cookies et est automatiquement ajoutée par le navigateur (sauf pour Safari - il y a des nuances que nous n'avons pas encore décidées) à toutes les demandes au serveur.







Problème 1:



Je ne peux pas me connecter via Firefox et Safari dans l'interface du système d'exploitation de stockage, le chargeur est affiché, et c'est tout.



Mini-hypothèse:



problème de proxy. Une vérification rapide a montré le résultat: si l'autorisation sans utiliser de proxy (accès sécurisé universel avec un certificat), alors tout fonctionne. Alors, quel est le problème?



Après avoir analysé la pile réseau, nous avons réalisé que l'en-tête Authorization était utilisé, cependant, plus tôt, lors de la configuration du proxy des services Rancher, il a été découvert que cet en-tête est passé au service proxy et contient les données d'autorisation pour le certificat, il a donc été décidé de simplement le supprimer une fois le processus d'autorisation terminé (FakeBasicAuth ).



Problème 2:



Dans de nombreux serveurs Web, l'autorisation de certificat personnel est implémentée par émulation de l'autorisation de base (en fait, interférant avec la demande de l'utilisateur), probablement afin de réduire les changements dans le code principal du serveur Web. Cette méthode s'appelle FakeBasicAuth. Après avoir défini un tel en-tête, le serveur Web écrase l'en-tête d'autorisation qui provient de l'utilisateur.



Hypothèses:

1. La portée de l'en-tête FakeBasicAuth se prête à encore plus de restriction, de sorte que l'en-tête d'origine est restauré pour transmission à la ressource mandatée de sorte que seul l'en-tête d'origine, le cas échéant, soit transmis.
2. La portée de l'en-tête Authorization peut être conçue de sorte que l'en-tête soit enregistré avant d'activer le mécanisme FakeBasicAuth et restauré après.

État visible - Objectif: le



système d'exploitation de stockage autorise, vous pouvez configurer ce service tout en conservant une approche unifiée pour rendre les services disponibles sur Internet externe.



Objectif supplémentaire:



accès http unifié, rapide et sécurisé tout en préservant les fonctionnalités de tous les services http possibles (par exemple, API REST pour une application mobile ou Registry Docker).



Comment vérifier?

• docker login registry-rancher.xxx.ru - en utilisant les clés et login / mot de passe.
• storageos-rancher.xxx.ru/#/login - en utilisant le login et le mot de passe des configs secret rancher.xxx.ru/p/c-84bnv : p-qj9qm / secrets / kube-system: init-secr ... (ne fonctionne pas dans Safari ).
• registry-ui-rancher.xxx.ru - en utilisant un navigateur et un login / mot de passe du registre. Pour ceux qui lisent attentivement l'astuce: vous pouvez utiliser cette interface au lieu de la connexion standard du docker registry-rancher.xxx.ru - il y a un proxy intégré au registre.

Test des hypothèses:



1. Sur la base de l'expérience précédente, essayons de trouver un moyen sur Internet pour de telles demandes: authentification apache externe basique via cert.



Il y avait un article plus ou moins adéquat sur ldap . De cette façon:

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

Et puis passez le titre dans des en-têtes supplémentaires à travers la construction

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

Mais, malheureusement, cette construction n'implique pas la création d'un en-tête identique, l'en-tête de la requête de l'utilisateur, et env est formé de manière incorrecte.



Par conséquent, la méthode basée sur la réécriture standard s'est avérée inutile et compliquée.



2. Si nous ne pouvons pas le faire en standard, alors nous devons nous tourner vers lua, nous avons vu précédemment qu'il y a des blocs de traitement de demande qui sont exécutés avant que les certificats ne soient traités, regardez à nouveau le diagramme de l'article lua_load_resty_core et l'instruction module_lua_writinghooks avec la construction précoce.



Il s'avère que nous pouvons utiliser le même script ( Comment, chez ZeroTech, nous nous sommes fait des amis Apple Safari et des certificats clients avec des websockets) pour conserver l'en-tête Authorization avant de le remplacer par FakeBasicAuth.

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

Dans Lua, cela ressemble maintenant à ceci:

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

Remarque: les



nouveaux designs sont en gras. Et comme on sait que l'env obtenu de Lua n'est disponible que pour les expressions expr, on ajoute une construction à côté du cryptage du jeton zt-cert:



# cookies sortants à l'utilisateur

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

# transmettre les en-têtes au service mandaté

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

La disponibilité des données pour le transfert vers le service a été vérifiée en transférant les données à l'utilisateur vers le navigateur:

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

Le plus intéressant ici est un moyen de vérifier la présence de données, afin de ne pas transmettre l'en-tête au service mandaté s'il ne provenait pas de l'extérieur du navigateur de l'utilisateur. La deuxième partie de la construction en est responsable:

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

Achèvement: Il n'y a pas de



solutions toutes faites sur Internet pour le moment, environ trois heures ont été passées à chercher et à essayer de tester les variantes, car je ne voulais pas «réinventer la roue».



Ajout de 5 lignes, dont 3 peuvent être supprimées en toute sécurité. Qu'est-ce que tu penses? - Écrivez vos options de réponse dans les commentaires de l'article.



Je ne voulais pas écrire sur cette expérience, car en fait il ne s'agit que de 2 lignes et la rubrique Autorisation atteindra le destinataire, mais j'ai quand même décidé de partager l'information, car elle utilise une bonne réserve de connaissances des recherches précédentes sur les certificats (nous parlons de cet article ). De plus, il n'y a pratiquement pas de casse-cou pour écrire quelque chose de leur propre et si simple dans une langue inconnue.