Articles

KubeSec es otra herramienta para ayudar a mejorar la seguridad de nuestro clúster de Kubernetes. Y estamos viendo a muchas agencias centrarse en la seguridad para resaltar la importancia de este tema en arquitecturas y despliegues modernos. La seguridad es ahora un componente clave, probablemente el más crucial. Todos necesitamos mejorar nuestro desempeño en ese tema, y por eso es esencial tener herramientas en nuestro conjunto de herramientas que nos ayuden en esa tarea sin ser expertos en seguridad en cada una de las tecnologías, como Kubernetes en este caso.

KubeSec es una herramienta de código abierto desarrollada por una consultoría de seguridad nativa de la nube y de código abierto llamada ControlPlane que nos ayuda a realizar un análisis de riesgo de seguridad en los recursos de Kubernetes.

¿Cómo Funciona KubeSec?

KubeSec funciona basado en los Archivos de Manifiesto de Kubernetes que usas para desplegar los diferentes recursos, por lo que necesitas proporcionar el archivo YAML a una de las formas de ejecución que esta herramienta soporta. Este es un tema importante, «una de las formas de ejecución», porque KubeSec soporta muchos modos de ejecución diferentes que nos ayudan a cubrir otros casos de uso.

Puedes ejecutar KubeSec en los siguientes modos:

• Modo HTTP: KubeSec estará escuchando solicitudes HTTP con el contenido del YAML y proporcionará un informe basado en eso. Esto es útil en casos que necesitan ejecución en modo servidor, como las canalizaciones CICD, o simplemente servidores de seguridad para ser utilizados por algunos equipos, como DevOps o Ingeniería de Plataforma. Además, otro caso de uso crítico de este modo es ser parte de un Controlador de Admisión de Kubernetes en tu Clúster de Kubernetes para que puedas hacer cumplir esto cuando los desarrolladores estén desplegando recursos en la plataforma misma.
  
• Modo SaaS: Similar al modo HTTP pero sin necesidad de alojarlo tú mismo, todo disponible detrás de kubesec.io cuando el modo SaaS es de tu preferencia, y no estás manejando información sensible en esos componentes.
  
• Modo CLI: Solo para ejecutarlo tú mismo como parte de tus pruebas locales, tendrás disponible otro comando CLI aquí: kubesec scan k8s-deployment.yaml
  
• Modo Docker: Similar al modo CLI pero como parte de una imagen de docker, también puede ser compatible con las canalizaciones CICD basadas en cargas de trabajo contenedorizadas.
  

Informe de Salida de KubeScan

Lo que obtendrás de la ejecución de KubeScan en cualquiera de sus formas es un informe JSON que puedes usar para mejorar y calificar el nivel de seguridad de tus recursos de Kubernetes y algunas formas de mejorarlo. La razón detrás de usar JSON como salida también simplifica el uso de la herramienta en cargas de trabajo automatizadas como las canalizaciones CICD. Aquí puedes ver un ejemplo del informe de salida que obtendrás:

Lo importante sobre la salida es el tipo de información que recibirás de ella. Como puedes ver en la imagen de arriba, está separada en dos secciones diferentes por objeto. La primera es el «puntaje», que son las cosas implementadas relacionadas con la seguridad que proporcionan algún puntaje para la seguridad del objeto. Pero también tendrás una sección de consejos que proporciona algunas cosas y configuraciones que puedes hacer para mejorar ese puntaje, y debido a eso, también la seguridad global del objeto de Kubernetes en sí.

Kubescan también aprovecha otra herramienta que hemos comentado no hace mucho en este sitio, Kubeconform, por lo que también puedes especificar la versión de Kubernetes objetivo a la que estás apuntando para tener un informe mucho más preciso de tu Manifiesto de Kubernetes específico. Para hacer eso, puedes especificar el argumento --kubernetes-version cuando estés lanzando el comando, como puedes ver en la imagen a continuación:

 ¿Cómo Instalar KubeScan?

La instalación también proporciona diferentes formas y sabores para ver qué es lo mejor para ti. Aquí hay algunas de las opciones disponibles en el momento de escribir este artículo:

• Imagen de contenedor Docker en docker.io/kubesec/kubesec:v2
• Binario Linux/MacOS/Win (obtener la última versión)
• Controlador de Admisión de Kubernetes
• Plugin de Kubectl
  

Conclusión

Enfatizando la importancia primordial de la seguridad en las arquitecturas intrincadas de hoy en día, KubeSec emerge como un activo vital para fortalecer la protección de los clústeres de Kubernetes. Desarrollada por ControlPlane, esta herramienta de código abierto facilita evaluaciones de riesgo de seguridad exhaustivas de los recursos de Kubernetes. Ofreciendo versatilidad a través de múltiples modos operativos—como HTTP, SaaS, CLI y Docker—KubeSec proporciona soporte adaptado para diversos escenarios. Su salida basada en JSON simplifica la integración en flujos de trabajo automatizados, mientras que su sinergia con Kubeconform asegura un análisis preciso de los Manifiestos de Kubernetes. El enfoque amigable de KubeSec empodera tanto a expertos en seguridad como a novatos, catalizando un estándar elevado de seguridad en Kubernetes en todos los ámbitos.

📚 Want to dive deeper into Kubernetes? This article is part of our comprehensive Kubernetes Architecture Patterns guide, where you’ll find all fundamental and advanced concepts explained step by step.

Este artículo cubrirá cómo mejorar la seguridad de tus imágenes de TIBCO BWCE creando una Imagen de Sistema de Archivos de Solo Lectura para TIBCO BWCE. En artículos anteriores, hemos comentado los beneficios que este tipo de imagen proporciona varias ventajas en términos de seguridad, centrándonos en aspectos como la reducción de la superficie de ataque al limitar el tipo de cosas que cualquier usuario puede hacer, incluso si logran acceder a contenedores en ejecución.

Lo mismo se aplica en caso de que cualquier malware que pueda tener tu imagen haya limitado las posibles acciones que pueden hacer sin ningún acceso de escritura a la mayor parte del contenedor.

¿Cómo afecta ReadOnlyFileSystem a una imagen de TIBCO BWCE?

Esto tiene un impacto claro ya que la imagen de TIBCO BWCE es una imagen que necesita escribir en varias carpetas como parte del comportamiento esperado de la aplicación. Eso es obligatorio y no depende de los scripts que usaste para construir tu imagen.

Como probablemente sepas, TIBCO BWCE incluye dos conjuntos de scripts para construir la imagen base de Docker: los principales y los incluidos en la carpeta reducedStartupTime, como puedes ver en la página de GitHub pero también dentro de tu carpeta docker en el TIBCO-HOME después de la instalación, como puedes ver en la imagen a continuación.

La principal diferencia entre ellos es dónde se realiza la descompresión del bwce-runtime. En el caso del script por defecto, la descompresión se realiza en el proceso de inicio de la imagen, y en el reducedStartupTime esto se hace en la construcción de la imagen misma. Así que, puedes empezar a pensar que los predeterminados necesitan algún acceso de escritura ya que necesitan descomprimir el archivo dentro del contenedor, y eso es cierto.

Pero también, el reducedStartupTime requiere acceso de escritura para ejecutar la aplicación; se realizan varias actividades relacionadas con la descompresión del archivo EAR, la gestión del archivo de propiedades y actividades internas adicionales. Así que, no importa qué tipo de scripts estés usando, debes proporcionar una carpeta con acceso de escritura para realizar esta actividad.

Por defecto, todas estas actividades están limitadas a una sola carpeta. Si mantienes todo por defecto, esta es la carpeta /tmp, por lo que debes proporcionar un volumen para esa carpeta.

¿Cómo desplegar una aplicación TIBCO BWCE con el

Ahora, está claro que necesitas un volumen para la carpeta /tmp, y ahora necesitas definir el tipo de volumen que deseas usar para este. Como sabes, hay varios tipos de volúmenes que puedes determinar dependiendo de los requisitos que tengas.

En este caso, el único requisito es el acceso de escritura, pero no hay necesidad en cuanto a almacenamiento y persistencia, por lo que, en ese caso, podemos usar un modo emptyDir. El contenido de emptyDir, que se borra cuando se elimina un pod, es similar al comportamiento predeterminado pero permite permiso de escritura en su contenido.

Para mostrar cómo sería el YAML, usaremos el predeterminado que tenemos disponible en la documentación aquí:

apiVersion: v1
kind: Pod
metadata:
  name: bookstore-demo
  labels:
    app: bookstore-demo
spec:
  containers:
  - name: bookstore-demo
    image: bookstore-demo:2.4.4
    imagePullPolicy: Never
    envFrom:
    - configMapRef:
      name: name 

Así que, cambiaremos eso para incluir el volumen, como puedes ver aquí:

apiVersion: v1
kind: Pod
metadata:
  name: bookstore-demo
  labels:
    app: bookstore-demo
spec:
  containers:
  - name: bookstore-demo
    image: bookstore-demo:2.4.4
    imagePullPolicy: Never
	securityContext:
		readOnlyRootFilesystem: true
    envFrom:
    - configMapRef:
      name: name
    volumeMounts:
    - name: tmp
      mountPath: /tmp
  volumes:
  - name: tmp
    emptyDir: {}

Los cambios son los siguientes:

• Incluir la sección volumes con una única definición de volumen con el nombre de tmp con una definición de emptyDir.
• Incluir una sección volumeMounts para el volumen tmp que se monta en la ruta /tmp para permitir escribir en esa ruta específica para habilitar también la descompresión del bwce-runtime así como todas las actividades adicionales que se requieren.
• Para activar este comportamiento, incluye la bandera readOnlyRootFilesystem en la sección securityContext.
  

Conclusión

Incorporar un enfoque de ReadOnlyFileSystem en tus imágenes de TIBCO BWCE es una estrategia proactiva para fortalecer la postura de seguridad de tu aplicación. Al reducir el acceso de escritura innecesario y minimizar las posibles vías para acciones no autorizadas, estás dando un paso vital hacia la protección de tu entorno de contenedores.

Esta guía ha revelado los aspectos críticos de implementar tal medida de mejora de seguridad, guiándote a través del proceso con instrucciones claras y ejemplos prácticos. Con un enfoque en reducir vectores de ataque y reforzar el aislamiento, puedes desplegar con confianza tus aplicaciones TIBCO BWCE, sabiendo que has fortalecido su entorno de ejecución contra posibles amenazas.

Si quieres profundizar más en el ecosistema TIBCO, consulta nuestra Guía completa de la plataforma de integración TIBCO donde cubrimos patrones, mejores prácticas y guía de producción.

Introducción

Una característica de seguridad tan importante es el uso de ReadOnlyRootFilesystem, una herramienta poderosa que puede mejorar significativamente la postura de seguridad de tus contenedores.

En el panorama de desarrollo y despliegue de software en rápida evolución, los contenedores han surgido como una tecnología revolucionaria. Ofreciendo portabilidad, eficiencia y escalabilidad, los contenedores se han convertido en la solución preferida para empaquetar y entregar aplicaciones. Sin embargo, con estos beneficios vienen desafíos de seguridad específicos que deben abordarse para garantizar la integridad de tus aplicaciones en contenedores.

Un ReadOnlyRootFilesystem es precisamente lo que parece: un sistema de archivos que solo se puede leer, no escribir. En la contenedorización, el contenido del sistema de archivos de un contenedor está bloqueado en un estado de solo lectura, evitando cualquier modificación o alteración durante el tiempo de ejecución.

 Ventajas de Usar ReadOnlyRootFilesystem

• Superficie de Ataque Reducida: Uno de los principios fundamentales de la ciberseguridad es reducir la superficie de ataque: los puntos de entrada potenciales para actores maliciosos. Aplicar un ReadOnlyRootFilesystem elimina la posibilidad de que un atacante obtenga acceso de escritura a tu contenedor. Esta medida simple pero efectiva limita significativamente su capacidad para inyectar código malicioso, manipular archivos críticos o instalar malware.
• Infraestructura Inmutable: La infraestructura inmutable es un concepto donde los componentes nunca se cambian una vez desplegados. Este enfoque asegura consistencia y repetibilidad, ya que cualquier cambio se realiza desplegando una nueva instancia en lugar de modificar una existente. Al aplicar un ReadOnlyRootFilesystem, estás esencialmente adoptando los principios de infraestructura inmutable dentro de tus contenedores, haciéndolos más resistentes a modificaciones no autorizadas.
• Mitigación de Malware: El malware a menudo depende de obtener acceso de escritura a un sistema para llevar a cabo sus actividades maliciosas. Al emplear un ReadOnlyRootFilesystem, eriges una barrera significativa contra el malware que intenta establecer persistencia o exfiltrar datos sensibles. Incluso si un atacante logra comprometer un contenedor, su capacidad para instalar y ejecutar código malicioso está severamente restringida.
• Mejor Forense y Auditoría: En el desafortunado caso de una violación de seguridad, tener un ReadOnlyRootFilesystem en su lugar puede ayudar en el análisis forense. Dado que el sistema de archivos permanece inalterado, los investigadores pueden rastrear más precisamente el vector de ataque, determinar el alcance de la violación e identificar los puntos de entrada vulnerables.
  

Consideraciones de Implementación

Implementar un ReadOnlyRootFilesystem en tus aplicaciones en contenedores requiere un enfoque deliberado:

• Diseño de Imagen: Construye tus imágenes de contenedor con el concepto de ReadOnlyRootFilesystem en mente. Asegúrate de separar las áreas de solo lectura y escritura del sistema de archivos. Esto podría implicar crear volúmenes para datos escribibles o usar variables de entorno para personalizar el comportamiento en tiempo de ejecución.
• Configuración en Tiempo de Ejecución: Los contenedores a menudo requieren acceso de escritura para archivos temporales, registros u otras necesidades de tiempo de ejecución. Diseña cuidadosamente tu aplicación para usar directorios o volúmenes designados para estos propósitos mientras mantienes los componentes críticos de solo lectura.
• Pruebas y Validación: Prueba exhaustivamente tu aplicación en contenedores con la configuración de ReadOnlyRootFilesystem para asegurar que funcione como se espera. Presta atención a cualquier error en tiempo de ejecución, problemas de permisos o comportamientos inesperados que puedan surgir.
  

¿Cómo Definir un Pod como ReadOnlyRootFilesystem?

Para definir un Pod como “ReadOnlyRootFilesystem”, esta es una de las banderas que pertenecen a la sección securityContext del pod, como puedes ver en el ejemplo a continuación:

apiVersion: v1
kind: Pod
metadata:
  name: <nombre del Pod>
spec:
  containers:
  - name: <nombre del contenedor>
    image: <imagen>
    securityContext:
      readOnlyRootFilesystem: true

Conclusión

A medida que la adopción de contenedores continúa aumentando, también lo hace la importancia de medidas de seguridad robustas. Incorporar un ReadOnlyRootFilesystem en tu estrategia de contenedores es un paso proactivo hacia la protección de tus aplicaciones y datos. Al reducir la superficie de ataque, fortalecer contra el malware y permitir un mejor análisis forense, estás mejorando la postura de seguridad general de tu entorno en contenedores.

A medida que adoptas infraestructura inmutable dentro de tus contenedores, estarás mejor preparado para enfrentar el panorama en constante evolución de las amenazas de ciberseguridad. Recuerda, cuando se trata de seguridad en contenedores, un ReadOnlyRootFilesystem puede ser el escudo que protege tus activos digitales de posibles daños.

📚 Want to dive deeper into Kubernetes? This article is part of our comprehensive Kubernetes Architecture Patterns guide, where you’ll find all fundamental and advanced concepts explained step by step.