Consejos y trucos de Kubernetes: acceso a sitios de desarrollo

Continuamos una serie de artículos prácticos sobre cómo hacer la vida más fácil para los desarrolladores y desarrolladores en su trabajo diario con Kubernetes. Todos ellos se recopilan de nuestra experiencia en la solución de problemas de los clientes y se mejoran con el tiempo, pero aún así no dicen ser ideales: considérelos más como ideas y espacios en blanco, sugiera sus soluciones y mejoras en los comentarios.


Esta vez, se considerarán dos temas, relacionados condicionalmente con un tema: el acceso del usuario al entorno de desarrollo.

1. ¿Cómo cerramos los circuitos de desarrollo de usuarios innecesarios?

A menudo nos enfrentamos a la tarea de cerrar todo el circuito de desarrollo (decenas / cientos de aplicaciones) detrás de la autenticación básica o la lista blanca, para que los robots de búsqueda o solo personas de terceros no puedan llegar allí.

Por lo general, para limitar el acceso, cada Ingress y aplicación deben crear secretos de autenticación básicos por separado . Administrarlos es muy problemático al escribir con una docena de aplicaciones. Por lo tanto, organizamos el control de acceso centralizado.

Para hacer esto, nginx se creó con una configuración de este tipo:

location / { satisfy any; auth_basic "Authentication or whitelist!"; auth_basic_user_file /etc/nginx/htpasswd/htpasswd; allow 10.0.0.0/8; allow 175.28.12.2/32; deny all; try_files FAKE_NON_EXISTENT @return200; } location @return200 { return 200 Ok; } 

Además en los Ingresss de la aplicación, simplemente agregamos la anotación:

ingress.kubernetes.io/auth-url: "http://dev-auth.dev-auth-infra.svc.cluster.local"

Por lo tanto, al acceder a la aplicación, la solicitud va al dev-auth , que verifica si se ingresó la autenticación básica correcta o si el cliente ingresa a la lista blanca. Si se cumple una de las condiciones, la solicitud se confirma y pasa a la aplicación.



En el caso de utilizar dicho servicio, un repositorio es suficiente, en el que se almacena una lista de todos los accesos y a través del cual podemos configurar convenientemente nuestro "centro de autorización único". Su distribución a nuevas aplicaciones se lleva a cabo mediante la adición elemental de anotaciones.

2. ¿Cómo proporcionamos acceso a las aplicaciones dentro de Kubernetes en un entorno de desarrollo?

... ya sea Redis, RabbitMQ, PostgreSQL o el desarrollador PHP favorito de Xdebug.

Muy a menudo, al traducir aplicaciones a Kubernetes, para garantizar una mejor seguridad, tenemos que bloquear el acceso desde el exterior y por completo. Y luego los desarrolladores que están acostumbrados a "ir a su IDE" a la base de datos o a Xdebug experimentan serias dificultades.

Para resolver este problema, utilizamos una VPN directamente en el clúster de Kubernetes. El esquema general se ve de modo que cuando se conecta a un servidor VPN que se ejecuta en K8, en el archivo de configuración de OpenVPN empujamos la dirección del servidor DNS, que también vive en K8. OpenVPN configura la VPN de tal manera que cuando solicita un recurso dentro de Kubernetes, primero va al servidor DNS de Kubernetes, por ejemplo, detrás de la dirección del servicio redis.production.svc.cluster.local . DNS en Kubernetes lo resuelve a 10.244.1.15 y las solicitudes de esta dirección IP pasan por OpenVPN directamente al clúster de Kubernetes.

Durante el funcionamiento de esta solución, logramos expandirla repetidamente. En particular:

1. Como no encontramos un panel de administración simple y adecuado (para nuestro caso) para contabilizar el acceso a la VPN , tuvimos que crear nuestra propia interfaz simple: el gráfico oficial proporciona solo la opción de ejecutar comandos de consola para emitir certificados.
   
   El panel de administración resultante (ver también en Docker Hub ) se ve muy ascético:
   
   
   Puede crear nuevos usuarios o revocar certificados antiguos:
   
   
   También puede ver la configuración de este cliente:
   
   
2. Agregamos autorización en VPN basada en usuarios en GitLab , donde se verifica la contraseña y si el usuario está activo en GitLab. Esto es para los casos en que el cliente desea administrar usuarios que pueden conectarse a la VPN de desarrollo solo sobre la base de GitLab, y sin el uso de administradores adicionales; en cierto sentido, resulta "SSO para los pobres". Como base, tomaron el cuadro ya mencionado.
   
   Para hacer esto, escribimos un script de Python que, al conectar un usuario a OpenVPN, usando el nombre de usuario y la contraseña, compara el hash en la base de datos de GitLab y verifica su estado (si está activo).
   
   
   
   Aquí está el script en sí:
   
   

    #!/usr/bin/env python3 # pip3 install psycopg2-binary bcrypt import bcrypt import sys import os import psycopg2 import yaml with open("/etc/openvpn/setup/config.yaml", 'r') as ymlfile: cfg = yaml.load(ymlfile) def get_user_info(username=''): try: connect_str = "dbname=%s user=%s host=%s password=%s" % (cfg['db'], cfg['user'], cfg['host'], cfg['pass']) # use our connection values to establish a connection conn = psycopg2.connect(connect_str) # create a psycopg2 cursor that can execute queries cursor = conn.cursor() # create a new table with a single column called "name" cursor.execute("""SELECT encrypted_password,state FROM users WHERE username='%s';""" % username) # run a SELECT statement - no data in there, but we can try it rows = cursor.fetchall() print(rows) return(rows[0]) except Exception as e: print("Uh oh, can't connect. Invalid dbname, user or password?") print(e) def check_user_auth(): username = os.environ['username'] password = bytes(os.environ['password'], 'utf-8') # hashed = bcrypt.hashpw(password, bcrypt.gensalt()) user_info = get_user_info(username=username) user_encrypted_password = bytes(user_info[0], 'utf-8') user_state = True if user_info[1] == 'active' else False if bcrypt.checkpw(password, user_encrypted_password) and user_state: print("It matches!") sys.exit(0) else: print("It does not match :(") sys.exit(1) def main(): check_user_auth() if __name__ == '__main__': main() 

   
   Y en la configuración de OpenVPN solo especifique lo siguiente:
   
   auth-user-pass-verify /etc/openvpn/auth-user.py via-env
script-security 3
client-cert-not-required
   
   Por lo tanto, si un empleado dejaba al cliente, simplemente lo desactivaban en GitLab, después de lo cual no podría conectarse a la VPN.

En lugar de una conclusión

Continuando con una serie de artículos con recetas prácticas de Flant para la operación de Kubernetes, cubriré temas como resaltar nodos individuales para tareas específicas (¿por qué y cómo?) Y configurar servicios como php-fpm / gunicorn que se ejecutan en contenedores para cargas pesadas. ¡Suscríbete a nuestro blog para no perderte las actualizaciones!

PS

Otros del ciclo de consejos y trucos de K8s:

• " Páginas de error personalizadas en NGINX Ingress ";
• " Transferencia de recursos que trabajan en un clúster a la gestión de Helm 2 ";
• " Sobre la asignación de nodos y la carga en la aplicación web ";
• " Acelerar el arranque de grandes bases de datos " .

Lea también en nuestro blog:

• " 11 maneras de (no) convertirse en una víctima del pirateo de Kubernetes ";
• " Crear e instalar aplicaciones en Kubernetes utilizando dapp y GitLab CI ";
• " Monitoreo y Kubernetes " (informe de revisión y video) ;
• " Nuestra experiencia con Kubernetes en pequeños proyectos " (informe en video, que incluye una introducción al dispositivo técnico Kubernetes) .