Clever Geek Handbook

La magia de 2 líneas en Lua o cómo llevar los encabezados de autorización de encabezado de autorización HTTP originales al servicio web

El artículo será útil para aquellos:



  • quién necesita utilizar varios tipos de autorización en una solicitud al servidor;
  • que quiera abrir los servicios del mundo Kubernetes / Docker a Internet en general, sin pensar en cómo proteger un servicio en particular;
  • piensa que ya todo lo ha hecho alguien y le gustaría hacer el mundo un poco más cómodo y seguro.


Prólogo Los



servicios que están disponibles a través de Kubernetes tienen un amplio conjunto de métodos de autorización. Uno de los más de moda es el encabezado Authorization: Bearer , por ejemplo: autorización JWT ( JSON Web Token ) con la transferencia de muchas claves, y por lo tanto valores, en un encabezado. También existen autorizaciones básicas, por ejemplo para el Registro (repositorio de imágenes de Docker). Esta autorización no utiliza cookies y el navegador la agrega automáticamente (a excepción de Safari, hay matices que aún no hemos decidido) a todas las solicitudes al servidor.







Problema 1:



no puedo iniciar sesión a través de Firefox y Safari en la interfaz del SO de almacenamiento, se muestra el cargador y listo.



Mini-hipótesis:



problema de aproximación. Una verificación rápida mostró el resultado: si se autoriza sin usar proxy (acceso seguro universal usando un certificado), entonces todo funciona. Entonces, ¿cuál es el problema?



Después de analizar la pila de la red, nos dimos cuenta de que se está utilizando el encabezado de Autorización, sin embargo, anteriormente, durante la configuración del proxy de los servicios de Rancher, se descubrió que este encabezado se pasa al servicio de proxy y contiene los datos de autorización para el certificado, por lo que se decidió simplemente eliminarlo después de que se complete el proceso de autorización (FakeBasicAuth ).



Problema 2:



En muchos servidores web, la autorización con un certificado personal se implementa mediante la emulación de la autorización básica (de hecho, interfiriendo con una solicitud del usuario), probablemente para reducir cambios en el código principal del servidor web. Este método se llama FakeBasicAuth. Después de configurar dicho encabezado, el servidor web sobrescribe el encabezado de autorización que proviene del usuario.



Hipótesis:



  1. El alcance del encabezado FakeBasicAuth se presta a una restricción aún mayor, de modo que el encabezado original se restaura para su transmisión al recurso proxy para que solo se transmita el encabezado original, si lo hay.
  2. El alcance del encabezado de autorización se puede diseñar para que el encabezado se guarde antes de activar el mecanismo FakeBasicAuth y se restaure después.


Estado visible - Propósito: El



sistema operativo de almacenamiento lo autoriza, puede configurar este servicio mientras mantiene un enfoque unificado para hacer que los servicios estén disponibles para Internet externo.



Objetivo adicional:



Acceso http unificado, rápido y seguro mientras se conserva la funcionalidad de todos los servicios http posibles (por ejemplo, API REST para una aplicación móvil o Registry Docker).



¿Como revisar?



  • docker login registration-rancher.xxx.ru - usando claves e inicio de sesión / contraseña.
  • storageos-rancher.xxx.ru/#/login - usando el nombre de usuario y la contraseña de configs secret rancher.xxx.ru/p/c-84bnv : p-qj9qm / secrets / kube-system: init-secr ... (no funciona en Safari ).
  • registry-ui-rancher.xxx.ru - usando un navegador y usuario / contraseña de registro. Para aquellos que lean con atención, el truco: puede usar esta interfaz en lugar del registro de inicio de sesión de la ventana acoplable estándar-rancher.xxx.ru: hay un proxy integrado para el Registro.


Prueba de hipótesis:



1. Basándonos en la experiencia previa, intentemos encontrar una forma en Internet para tales solicitudes: autenticación apache externa básica a través de cert.



Hubo un artículo más o menos adecuado sobre ldap . De este modo: 



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


Y luego pase el título en encabezados adicionales a través de la construcción 



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


Pero, desafortunadamente, esta construcción no implica la creación de un encabezado idéntico, el encabezado de la solicitud del usuario y env se forma incorrectamente.



Por lo tanto, el método basado en la reescritura estándar resultó ser inútil y complicado.



2. Si no podemos hacerlo como estándar, entonces tenemos que recurrir a lua, ya hemos visto anteriormente que hay bloques de procesamiento de solicitudes que se ejecutan antes de que se procesen los certificados, mire nuevamente el diagrama de bloques del artículo lua_load_resty_core y la instrucción module_lua_writinghooks con la construcción inicial.



Resulta que podemos usar el mismo script ( cómo en ZeroTech hicimos amigos Apple Safari y certificados de cliente con websockets) para conservar el encabezado de autorización antes de reemplazarlo con FakeBasicAuth. 







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


En Lua, ahora se ve así: 




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


Nota: Las



nuevas construcciones están en negrita. Y como sabemos que el env obtenido de Lua solo está disponible para expresiones expr, agregamos una construcción junto al cifrado del token zt-cert:



# cookies salientes para el usuario 




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


# pasar encabezados al servicio proxy 




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


La disponibilidad de datos para transferir al servicio se verificó transfiriendo los datos al usuario al navegador: 



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


Lo más interesante aquí es una forma de verificar la presencia de datos, para no transmitir el encabezado al servicio proxy si no proviene de fuera del navegador del usuario. La segunda parte de la construcción se encarga de esto: 



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


Finalización: No hay



soluciones listas para usar en Internet en este momento, pasamos aproximadamente tres horas buscando y tratando de probar las variaciones, porque no quería “reinventar la rueda”.



Se agregaron 5 líneas, 3 de las cuales se pueden eliminar de forma segura. ¿Qué piensas? - Escriba sus opciones de respuesta en los comentarios del artículo.



No quería escribir sobre esta experiencia, ya que en realidad son solo 2 líneas y el encabezado de Autorización llegará al destinatario, pero decidí compartir la información de todos modos, ya que utiliza un buen acervo de conocimientos de investigaciones previas sobre certificados (estamos hablando de este artículo ). Además, apenas hay temerarios por escribir algo propio y tan sencillo en un idioma desconocido.





More articles:


All Articles