Operador autónomo 1.2.0 Conectividad pública

En mi artículo anterior Discutí -desde un alto nivel- la nueva característica de Conectividad Pública en el Operador Autónomo 1.2.0. Esto fue intencionalmente una visión general abstracta con el fin de persuadir al usuario a aprender acerca de las alegrías de DDNS, TLS y redes de capa 3.

Dale un pez a un hombre y lo alimentarás durante un día. Enséñale a pescar y le darás de comer toda la vida.

Esperemos que todos hayáis invertido tiempo en aprender a pescar (o al menos os hayáis mojado los pies). (o al menos listos para mojarse los pies.) Este artículo ofrece un tutorial práctico sobre la configuración del Operator para poder exponer tus clusters de Couchbase de forma segura en la internet pública.

¿Por qué utilizar esta función?

Las nuevas empresas tecnológicas se centran más en la nube que las empresas tradicionales. Algunos argumentarían que la empresa tradicional está atrincherada, protegiendo los datos tras cortafuegos en centros de datos privados, y podría decirse que, desde el punto de vista de la seguridad, es lo correcto.

El aumento de la exposición a la nube, aunque es un riesgo mayor, también se está convirtiendo en una preocupación menor a medida que pasa el tiempo. Lo más importante es que la nube abre innumerables puertas a la agilidad y la innovación. Conectar las ofertas de servicios públicos a través de la Internet pública es un beneficio enorme, que no puede lograrse fácil y económicamente con servicios que viven en las instalaciones, ocultos detrás de los límites de NAT.

Un ejemplo que personalmente me gusta mucho es el auge de las funciones como servicio (FaaS). Las funciones son trabajos de corta duración (normalmente basados en contenedores) que responden a estímulos y devuelven un resultado. Se crean bajo demanda y se escalan horizontalmente de forma automática e instantánea para gestionar la carga de trabajo requerida. Puede utilizar ofertas públicas de servicios FaaS hoy mismo, sin perder tiempo instalando y configurando infraestructura virtual o física. AWS Lambda es una encarnación de este tipo con la que puede estar familiarizado.

A menos que su función sea pura (en el sentido de que sólo procesa datos), necesitará entradas, normalmente en forma de base de datos. Estas ofertas FaaS, dado que operan en la Internet pública, también requerirán una conexión a una base de datos pública. Establecer túneles VPN privados entre estos servicios puede ser difícil o imposible.

Por estas razones -interconectividad, sencillez y agilidad- ofrecemos la opción de conectividad pública.

Seguridad, seguridad, seguridad

Un servicio puesto a disposición del público en Internet se enfrentará al escrutinio de terceros malintencionados. Internet está plagado de intentos de obtener y explotar información personal. Como prueba sencilla, conecte un sistema UNIX a Internet. Sus registros SSH se llenarán rápidamente de intentos de acceso a la máquina utilizando diccionarios de nombres de usuario y contraseñas comunes o robados. Los cortafuegos mostrarán intentos de escanear puertos abiertos. Esto es lo normal, y lo ha sido desde que tengo uso de razón.

Las bases de datos, en particular, son tarros de miel para los delincuentes que intentan explotar los sistemas con el fin de acceder a listas de correo para ataques de phishing, o extraer datos de tarjetas de crédito para fraudes y robos de identidad. Hay que proteger estos servicios.

La función de conectividad pública del operador obliga a utilizar un cifrado completo de extremo a extremo. Esto impide que los fisgones vean información confidencial mientras están en redes públicas. Los certificados digitales crean un vínculo de confianza entre clientes y servidores. Un cliente verificará que un servidor es válido para el nombre de host al que intentó conectarse y que está firmado por una autoridad de certificación de confianza.

El Operador sólo permite el uso de cadenas de certificados de servidor, y no actúa como autoridad de certificación, firmando certificados de servidor para servidores individuales a medida que cambia la topología. Actuar como CA permitiría crear y firmar cualquier certificado, por lo que optamos por el enfoque seguro. Como resultado, admitimos un certificado comodín para el clúster en su conjunto. Al utilizar certificados comodín también necesitamos utilizar DNS público para que el cliente pueda confirmar que el certificado del servidor es válido para el host con el que se está contactando.

Estos antecedentes nos proporcionan conocimientos suficientes para empezar a desplegar nuestra base de datos con conectividad pública.

Empecemos

DNS

Como ya hemos comentado, necesitamos usar DNS públicos para contactar con los nodos del cluster Couchbase cuando usamos conectividad pública. Estos se pueden comprar relativamente barato en línea de los registradores, tales como Gandi, GoDaddy, Namecheap etc.

También necesitamos poder utilizar DNS dinámicos. A medida que se añaden y eliminan nodos de nuestro clúster Couchbase, necesitamos que se añadan y eliminen las entradas correspondientes del DNS. También necesitan ser actualizadas si las direcciones IP públicas de estos nodos cambian. Esto es debido al alto rendimiento, la fragmentación del lado del cliente utilizada por los clientes Couchbase y XDCR. Utilizaremos el Kubernetes external-dns para realizar actualizaciones DDNS. El enlace enumera los proveedores de DDNS compatibles. Una vez que haya comprado un dominio DNS, tendrá que delegar sus servidores de nombres al proveedor DDNS que haya elegido. Mi elección personal para este ejemplo es Cloudflare. El paso final de preparación es la creación de una clave API u otras credenciales para que el controlador external-dns se autentique con el proveedor DDNS y controle los registros DNS requeridos por el cluster Couchbase.

TLS

Para la mayoría de la gente esta es la parte más mística del proceso. Las páginas web HTTPS simplemente funcionan de forma transparente, por lo que hay poca necesidad de preocuparse de esto en el día a día por parte del usuario medio. No voy a entrar en detalles (ya que eso es para otro post), pero lo que tenemos que discutir son las principales cosas que necesitan estar vinculados a su configuración de DNS elegido.

Utilizo mi dominio DNS personal, spjmurray.espara esta demostración. Instalaré mi clúster Couchbase en su propio espacio de nombres llamado 6c3c0075-b44a-11e9-9518-4a8d7629c69ay el clúster se llamará couchbase. Es importante conocer estos parámetros porque nos permiten direccionar de forma única un clúster Couchbase dentro de nuestro clúster Kubernetes. El clúster Couchbase se configurará para que su dominio sea couchbase.6c3c0075-b44a-11e9-9518-4a8d7629c69a.spjmurray.co.uk. El operador requerirá la creación de registros A dentro de este dominio para cada nodo, así como la Consola Web de Couchbase.

Conociendo nuestro dominio, ahora podemos determinar el nombre alternativo del sujeto del certificado comodín DNS *.couchbase.6c3c0075-b44a-11e9-9518-4a8d7629c69a.spjmurray.co.uk.

La herramienta EasyRSA de OpenVPN es un método sencillo para generar certificados. Primero, clona el repositorio e inicialízalo.

Generar el certificado de CA y el par de claves. Si recuerdas, la clave privada de la CA se utiliza para firmar digitalmente un certificado de servidor. Un cliente puede entonces verificar que el certificado del servidor es auténtico con la clave pública de la CA. Este comando le pedirá un nombre de CA y una contraseña. Una vez completado, el certificado de la CA se puede encontrar en pki/ca.crt.

El certificado del servidor y el par de claves se crean a continuación. Cuando se especifica TLS en la configuración del cluster de Couchbase, el Operador utilizará TLS para comunicarse con el cluster. Esto evita que cualquier contraseña o datos sensibles sean transmitidos en texto plano. Para soportar los nombres DNS privados de Kubernetes necesitamos otro nombre alternativo de sujeto comodín DNS. El nopass para que la clave privada no esté encriptada y pueda ser leída por el servidor Couchbase. El siguiente comando solicitará una contraseña; esta es la contraseña de la clave privada de la CA utilizada para firmar digitalmente el certificado.

Puede comprobar que el certificado es el esperado examinándolo en OpenSSL:

EasyRSA crea claves privadas en el moderno formato PKCS#7, sin embargo Couchbase Server sólo soporta PKCS#1. Para remediar esto necesitamos convertir los formatos.

Ahora que TLS está configurado, recoge tu certificado CA y el par certificado/clave privada del servidor, ya que serán necesarios cuando configures tu cluster Couchbase en un paso posterior.

Configuración DDNS

Ahora podemos empezar a desplegar algunos recursos reales de Kubernetes. En primer lugar, vamos a crear nuestro espacio de nombres para el controlador externo-dns para ejecutar y una cuenta de servicio para ejecutar como.

Se requiere un rol para otorgar permiso al controlador external-dns para interrogar los recursos de Kubernetes en el espacio de nombres en el que se está ejecutando. La función está vinculada a la cuenta de servicio que el controlador externo-dns se ejecutará como. Utilizaré un rol de clúster en este ejemplo para que pueda ser compartido entre todas las instancias del controlador de DNS externo. Sin embargo, se vinculará dentro del espacio de nombres, ya que el controlador no necesita acceder a todos los espacios de nombres. Usuarios de OpenShift: Necesitará privilegios de administrador para la creación y vinculación de roles, ya que requieren escalado de privilegios y, por motivos de seguridad, no pueden ser realizados por usuarios normales. El rol tiene el siguiente aspecto:

Y se instala con lo siguiente:

El último paso es instalar el controlador external-dns. Lo configuraremos para que busque servicios dentro del espacio de nombres. Si un servicio tiene una anotación external-dns.alpha.kubernetes.io/hostname entonces el controlador external-dns creará registros DNS A en nuestro proveedor DDNS mapeando a la dirección IP del servicio.

Es posible que varias instancias de external-dns estén sincronizando registros DNS para el mismo dominio. Si ve un registro que no corresponde a un servicio que está gestionando, lo borrará. Para evitar que dos o más controladores estén continuamente añadiendo registros propios y borrando registros ajenos, añadimos un GUID para que el controlador sólo responda a los registros de su propiedad. Para tu curiosidad, la propiedad se gestiona a través de registros DNS TXT. El YAML de despliegue tiene el siguiente aspecto. Debe sustituir su propia clave API de Cloudflare y dirección de correo electrónico en los parámetros de entorno.

Esto se puede crear con lo siguiente:

Comprueba que el despliegue se está ejecutando y estamos listos para instalar nuestro clúster Couchbase.

Instalar el operador

Este tema se trata ampliamente en el documentación oficial. En primer lugar, deberá instalar las definiciones de recursos personalizadas. A continuación, instale el controlador de admisión dinámico en un espacio de nombres de su elección y conéctelo a la API de Kubernetes.

El controlador de admisión es un componente obligatorio del despliegue de Operator 1.2.0. Aplica valores por defecto al cluster, y lo más importante, realiza validaciones fuera del alcance de la validación nativa del esquema JSON. La validación más importante que realiza para esta configuración es asegurar que tus DNS y TLS están configurados correctamente en la definición de tu cluster Couchbase.

El Operador se instala en el mismo espacio de nombres que el controlador external-dns mediante un proceso muy similar al del controlador external-dns.

Clúster Couchbase público

El último paso es en realidad el más sencillo. Aquí está la definición YAML:

La consola de administración y las funcionalidades expuestas (por pod services) se exponen con nuevos parámetros que permiten especificar el tipo de servicio. En esta ocasión estoy ejecutando en GKE. Cuando un LoadBalancer se le asocia una dirección IP pública.

La nueva configuración DNS, cuando se especifique, anotará la consola de administración y los servicios per-pod con las etiquetas entendidas por el controlador DNS externo. Para la configuración de la consola de administración es console.${metadata.name}.${spec.dns.domain} por ejemplo.

Por último, como estamos utilizando conectividad pública y DNS, el controlador de admisión dinámico nos obligará a utilizar TLS. Los parámetros TLS son poblada de secretos que contiene los certificados TLS que creamos anteriormente para este clúster.

Crea el cluster y observa los logs de estado u Operator para ver si se ha completado. Eventualmente deberías poder conectarte a la consola con la url https://console.6c3c0075-b44a-11e9-9518-4a8d7629c69a.spjmurray.co.uk:18091/ a medida que se asignan las IPs del balanceador de carga y se añaden los registros DNS. Puedes usar esta misma dirección para establecer clusters remotos XDCR y arrancar SDKs de cliente Couchbase. Enhorabuena, ¡has habilitado la conectividad pública!

Solución de problemas

Explicar simplemente cómo configurar la conectividad pública es la mitad del trabajo. Tienes que ser capaz de determinar dónde está el problema antes de plantear casos de asistencia. Dado que siempre es culpa de la red (bueno, casi siempre), aquí tienes algunos consejos que te ayudarán.

El DNS no es instantáneo, los registros tardan en aparecer y las modificaciones tardan en propagarse a medida que expiran los TTL. Para comprobar que el DNS es el esperado, primero busca los nombres DNS esperados. Busca los nombres de servicio:

Busque el nombre DNS calculado:

¿Existe el registro DNS A? ¿Corresponde la dirección IP a la dirección IP pública del servicio?

A continuación hay que asegurarse de que los puertos solicitados están a la escucha. Podemos comprobar que el puerto Admin habilitado para TLS está escuchando y podemos establecer una sesión TCP en ese puerto:

Lo último que hay que hacer es establecer si TLS funciona como se espera utilizando el certificado CA:

Además, para los especialmente valientes, puedes comprobar que las direcciones DNS pasadas a los clientes son correctas:

Próximos pasos

Couchbase Autonomous Operator 1.2.0 es un gran lanzamiento con muchas nuevas características. Los focos principales son la capacidad de actualización y la facilidad de uso. Esperamos que disfrutes haciendo cosas nuevas con él tanto como nosotros hemos disfrutado creándolo. Como siempre, ¡sus comentarios son clave!

• Pruébalo: https://www.couchbase.com/downloads
• Foros de apoyo: https://www.couchbase.com/forums/c/couchbase-server/Kubernetes
• Documentación: https://docs.couchbase.com/operator/1.2/whats-new.html

Seguir leyendo

• Operador autónomo 1.2.0 Trabajo en red: https://www.couchbase.com/blog/autonomous-operator-1-2-0-networking