Ediciones ENI Editorial | líder en informática
Securizar el acceso a las aplicaciones
Objetivos del capítulo y requisitos previos
El capítulo anterior explica cómo exponer una aplicación en Internet, lo que implica que sea posible consultarla desde cualquier lugar. En contraposición, no se ha abordado la cuestión del acceso seguro.
El capítulo abordará varios mecanismos:
-
Implementar el protocolo HTTPS (utilizando certificados Let’s Encrypt).
-
Restringir el acceso mediante autenticación HTTP básica.
-
Implementar una restricción de acceso por Oauth2.
Los siguientes ejercicios utilizarán el administrador Ingress Nginx, pero también se darán indicaciones para Traefik.
La protección del acceso interno se tratará en el próximo capítulo.
Implementar Let’s Encrypt
1. Presentación de Let’s Encrypt
Según Wikipedia, Let’s Encrypt es una autoridad de certificación lanzada el 3 de diciembre de 2015. Esta autoridad proporciona certificados X.509 gratuitos para el protocolo criptochart TLS.
El objetivo de esta autoridad de certificación es generalizar el uso de conexiones seguras en Internet, por ejemplo, con el protocolo HTTPS.
La creación de certificados se realiza de manera automática, sobre un desafío-respuesta basado en la creación de entradas DNS o HTTP. Un autómata se encarga de verificar que estas entradas se crean correctamente.
Para obtener más detalles, consulte el artículo Let’s Encrypt de Wikipedia España, disponible en la siguiente dirección: https://es.wikipedia.org/wiki/Let%27s_Encrypt
2. Instalar el chart Helm cert-manager
a. Presentación del chart Helm
El chart Helm jetstack/cert-manager que ofrece Jetstack proporciona una versión lista para usar del administrador de certificados. Este administrador se encargará de todo el ciclo de vida de los certificados del clúster:
-
Petición de creación.
-
Renovación automática.
Se va a presentar para poder trabajar con el administrador de certificados Let’s Encrypt.
Para funcionar correctamente, el administrador de certificados debe tener permisos para administrar los registros DNS. Estos permisos se pueden dar por medio de:
-
una regla a nivel del clúster, en el momento de la creación,
-
o creando una cuenta dedicada y usando un secreto (ver capítulo Exponer aplicaciones en Internet).
Tenga en cuenta que el desarrollo de los ejercicios requiere la implementación del administrador de entrada DNS (external-dns) que se ha visto en el capítulo anterior. Es imprescindible disponer de una cuenta de servicio que permita la gestión de las entradas DNS.
b. Requisitos previos a la instalación
En el primer despliegue, el administrador de certificados crea un nuevo tipo de recursos personalizados (CustomResourceDefinition o CRD en modo abreviado).
En instalaciones posteriores, estos objetos se deben actualizar. Consulte la dirección https://cert-manager.io/docs/installation/helm para descubrir las instrucciones completas.
El chart tiene su propio repositorio, por lo que no se tiene que añadir.
Los objetos...
Protección del acceso a las aplicaciones
1. Origen de la necesidad
Debido a la presencia de certificados, ya no es posible trazar el tráfico de los usuarios. Por otro lado, no hay control de acceso de usuarios: cualquiera que recupere la dirección de MailHog puede acceder a ella sin limitación.
Para proteger las aplicaciones, se debe implementar un mecanismo de control de acceso.
2. Contraseña sencilla (HTTP basic)
a. Principio de funcionamiento
Una de las soluciones de protección más comunes consiste en utilizar la autenticación por identificador/contraseña (estamos hablando de protección HTTP básica). Al acceder a la aplicación con el navegador, se solicita al usuario que introduzca un nombre de usuario y una contraseña.
Este mecanismo de autenticación es relativamente antiguo y tiene su origen en los primeros servidores HTTP y, en particular, en el servidor Apache. Este último proporciona la herramienta htpasswd: permite generar firmas de contraseña saladas en archivos dedicados a este uso.
A continuación, el usuario descubrirá una técnica que permite almacenar estos elementos directamente en un secreto de Kubernetes y después decirle al controlador Ingress cómo acceder a ellos.
b. Crear el secreto con htpasswd
La implementación de esta protección requiere la creación de un archivo que contenga los identificadores de los usuarios. Esto se hace usando el comando htpasswd seguido de estas opciones:
-
La opción -c (que se debe añadir en el caso de la creación inicial).
-
El nombre del archivo (ejemplo: mailhog-secret.htpasswd).
-
El nombre del usuario que se ha de crear en el archivo.
Inicialice el contenido del archivo con el siguiente comando:
$ htpasswd -c mailhog-secret.htpasswd mailhog-user El comando solicita la doble entrada de la contraseña del usuario:
New password:
Re-type new password:
Adding password for user mailhog-user No dude en observar el contenido del archivo con el comando cat:
$ cat mailhog.htpasswd A continuación, se muestra un ejemplo de resultado esperado:
mailhog-user:$apr1$O1...WD.$Y9VX.tai...vU/...Autenticación basada en OAuth2
1. Acerca del protocolo OAuth2
El protocolo OAuth2 gestiona el acceso a un sitio web basándose en un mecanismo existente (Facebook, Google, GitHub, Gitlab, etc.).
Para tener más detalles, puede consultar el siguiente artículo en Wikipedia: https://es.wikipedia.org/wiki/OAuth
La principal ventaja de este protocolo es que permite delegar la identificación de los usuarios a un tercero conocido por ellos. Por lo tanto, pueden reutilizar una identidad existente.
2. Principio de la solución
La autenticación del usuario se realizará con un servicio dedicado utilizando un proxy. Este último se encargará de autenticar al usuario y enviarlo a Mail-Hog.
El mecanismo de proxy se basará en la herramienta oauth2-proxy, disponible en forma de chart Helm.
Esquema principal de uso del servicio de autenticación de GitHub como autoridad OAuth2
GitHub servirá como un tercero de autenticación, pero el ejercicio se puede aplicar a otros terceros externos, como por ejemplo Google, Facebook, Twitter, etc. o internos (p. ej.: Keycloak, OpenAM, Azure Active Directory, etc.).
Aunque la herramienta Proxy OAuth2 soporta varios proveedores de identidad, solo puede usar uno a la vez.
3. Crear un identificador GitHub
Para el resto del ejercicio, el usuario debe tener un identificador en GitHub.
La primera operación consistirá en crear una nueva aplicación de GitHub. Para hacer esto, introduzca la siguiente dirección en un navegador: https://github.com/settings/applications/new
La pantalla le pedirá lo siguiente en la aplicación:
-
El nombre de la aplicación.
-
La dirección de la aplicación (p. ej.: https://mailhog.eni.yannig.ovh).
-
Una descripción opcional.
-
La dirección de gestión de autenticación: es la misma que la dirección de la aplicación, seguida del contexto/oauth2.
Creación de una aplicación para gestionar la autenticación de MailHog
Pantalla resumen de la aplicación, así como el secreto y el identificador necesarios para la implementación de la misma OAuth
4. Desplegar el proxy
a. Acerca del proxy
El proxy utilizado se basa en el proyecto pusher/oauth2_proxy. Para obtener más información, consulte la siguiente dirección: https://github.com/pusher/oauth2_proxy