Entradas

Tanzu v1.29.7+ y Pod Security Admission

Kubernetes v1.26 comenzó a forzar la "seguridad de los pods" haciendo que Pod Security Admission, de forma predeterminada, esté activo en su forma más restrictiva. Para poder desactivar estas restricciones, se deben implementar Labels en los namespaces requeridos para enforce, audit y warn. Siempre me pareció un poco arbitrario este cambio. Está bien intentar impulsar las mejores prácticas pero hacía falta tener una forma de modificar el comportamiento en forma global. Estoy probando Tanzu Supervisor Cluster v1.29.7 (luego de actualizar vSphere a v8U3 ) y encuentro, con mucho agrado, que ahora podemos configurar Pod Security Admission a nivel global en un cluster de kubernetes directamente en el YAML que usamos para crearlo. Nuevo objeto Cluster Venía usando el objeto TanzuKubernetesCluster para crear nuevos clusters en Tanzu. Ahora se deja de usar en favor del objeto Cluster nativo de Kubernetes. El siguiente es un ejemplo básico de YAML: apiVersion: cluster.x-k8s.io/v1beta...

Potencial riesgo de seguridad usando Azure Devops pipelines con la tarea "Execute oc command" de Openshift

Imagen
Existe un problema en el módulo "Execute oc command" disponible en pipelines de Azure Devops para realizar tareas en nuestros clusters de Openshift que supone un gran riesgo de seguridad. Cómo se ejecutan los pipelines Cuando ejecutamos un pipeline de Azure Devops, se crea un proceso en una máquina virtual configurada como agente. El proceso clona el repositorio en una carpeta "efímera" que será borrada luego de la ejecución. Si se ejecutan múltiples pipelines en el mismo agente, cada ejecución tendrá su propia carpeta. Qué hace la tarea "Execute oc command" La tarea "Execute oc command" primero se autentica contra el cluster de Openshift. Para esto hay 3 métodos disponibles: Usando una Service Connection Indicando el archivo kubeconfig que debe utilizar Injectando un kubeconfig "in-line" Cuando usamos la opción de Service Connection, la tarea utiliza el kubeconfig de la carpeta "home" del agente. Esto significa que, cua...

Instalando servicios en un cluster de Tanzu

Imagen
VMware Tanzu clusters, a diferencia de otras soluciones, despliega cluster de Kubernetes sin servicios preinstalados. Somos nosotros los que decidimos qué servicios van en cada cluster. Si no contamos con herramientas como Tanzu Mission Control , el desplieque de los servicios de infraestructura requiere de un poco de conocimiento. En este articulo (y los siguientes) voy a documentar cómo desplegar algunos de los servicios más instalados en los clusters. Helm y Bitnami Para la mayoría de los servicios estoy usando Helm y los servicios, si están disponibles, los obtengo desde el repositorio de Bitnami que contiene las imágenes curadas por VMware. Una vez instalado Helm, agregamos el repositorio de Bitnami: helm repo add bitnami https://charts.bitnami.com/bitnami Cert-Manager y Countour Probablemente el primer servicios que necesitamos en todos los clusters es el de "Ingress" para exponer nuestras aplicaciones con un balanceador capa 7. VMware recomienda el proyecto Co...

Integrar Aria Orchestrator en VMware Cloud Director

Imagen
En un artículo anterior describo el paso a paso para configurar el plugin de Cloud Director en Aria Orchestrator . Ahora es el momento de integrar Aria Orchestrator dentro de Cloud Director para poder ofrecer un catálogo de automatizaciones complejas basado en Orchestrator. Pre requisitos Antes de configurar Aria Orchestrator en Cloud Director debemos haber realizado lo siguiente: Desplegar y configurar VMware Cloud Director Desplegar y configurar Aria Orchestrator utilizando la autenticación del vCenter al cual se conecta Cloud Director Instalar y configurar el plugin de Cloud Director para Aria Orchestrator Registrar Orchestrator El primer paso es registrar la instancia de Aria Orchestrator en VMware Cloud Director. Navegamos Library > Service Management y clic en Add . Name: un nombre para identificar la instancia de Orchestrator Hostname: el FQDN de Aria Orchestrator Username: usuario perteneciente al grupo de administradores de Orchestrator Choose vRO vCenter: el vCenter contr...

Encodear Harbor Registry CA para crear un secret en Kubernetes

Imagen
Cada tanto necesito crear un secreto en algún cluster de kubernetes para confiar en una CA self-signed de Harbor y nunca recuerdo ni cómo obtener la CA ni como encodearla. Obterner CA Para obtener la CA de Harbor simplemente ejecutamos el siguiente comando: sudo wget -O ~/Downloads/ca.crt https://<<harbor_fqdn>>/api/v2.0/systeminfo/getcert --no-check-certificate Encodear certificado para insertar en un secret Ahora que tenemos el certificado, necesitamos convertirlo en una cadena sin saltos de línea para agregarlo a un secret. Lo hacemos con el siguiente comando: cat ~/Downloads/ca.crt | base64 -w 0 Y listo, ya podemos continuar.

Instalar in configurar VMware Cloud Director plugin para Aria Orchestrator

Imagen
Para extender la funcionalidad de VMware Cloud Director podemos utilizar Aria Orchestrator que es, en mi opinión uno de los mejores motores de workflows que he visto en el mercado, capaz de conectarse con cualquier sistema que exponga una API.  No hay mucha información en Internet sobre cómo hacerlo, seguramente porque Cloud Director está restringido a Cloud Providers. Por otra parte, la documentación oficial no es lo suficientemente descriptiva y el proceso nos suele fallar sin entender bien por qué. En nuestro escenario, ya tenemos desplegado y funcionando VMware Cloud Director, ahora debemos desplegar Aria Orchestrator. Aria Orchestrator NO tiene licencia propia, utilizará la de vCenter, por lo que no tenemos costos adicionales de licencia. Desplegar Aria Orchestrator Como siempre debemos descargar la versión correcta del OVA desde el portal de Broadcom según la matriz de interoperabilidad y comenzar el despliegue en vCenter, todo normal hasta que aparece el formulario de config...

VMware Cloud Director - problemas con interfaces

Imagen
Al comenzar a investigar VMware Cloud Director nos encontramos con algunos problemas. El primero es que no hay mucha información en Internet, el segundo aparece cuando queremos desplegar nuestro primer laboratorio. Primer problema, un solo segmento de red Lo primero que intenté es desplegar el Virtual Appliance. Como se trataba de un laboratorio intenté conectar las 2 interfaces de red al mismo segmento y esto terminó en que las interfaces se comportaron de forma extraña. Una funcionaba, la otra no. VMware tiene bien documentado que las interfaces deben ir en segmentos separados.  Segundo problema, segmentos separados Al desplegar el Appliance en dos segmentos de red separados parecía estar todo bien hasta que intenté realizar la primera configuración y daba error conectando al NFS. Luego de muchas pruebas entendí el problema.  Cloud Director utiliza las interfaces de la siguiente forma: La interfaz Eth0 es la principal y es la que configura el Default Gateway que ingresamos e...