Proyectos Kubernetes
Un proyecto Kubernetes es un conjunto de imágenes Docker pertenecientes a un espacio de nombres en un clúster Kubernetes, todo ello visto como un único activo que agrupa las vulnerabilidades de las imágenes que lo componen. Cada imagen se considera una tecnología del proyecto, lo que permite identificar las imágenes vulnerables sin necesidad de analizar su contenido.
Creación de un proyecto Kubernetes
Los proyectos Kubernetes son un tipo de conexiones sin agente. Los datos que se deben completar dependen de la forma de conectar con el clúster. Siempre es posible conectarse a un clúster accediendo directamente a la API de Kubernetes, pero para facilitar la gestión de credenciales, Cyberwatch puede recuperar automáticamente desde Azure o AWS las configuraciones de Kubernetes.
Clúster Kubernetes
Para acceder directamente a un clúster Kubernetes, primero hay que crearle un conjunto de credenciales registradas de tipo Kubernetes. Las credenciales creadas deben tener los siguientes permisos RBAC:
- apiGroups: [""]
resources: ["namespaces/status", "pods/status"]
verbs: ["list", "get"]
- apiGroups: [""]
resources: ["pods"]
verbs: ["list"]
Consulte la documentación de Kubernetes Using RBAC Authorization para más información.
El clúster será seleccionable posteriormente al crear el proyecto Kubernetes.
El campo Dirección del proyecto debe contener el nombre del espacio de nombres del que listar las imágenes, por ejemplo «mi namespace». Si otros clústeres definen el mismo espacio de nombres, es posible anteponerle un nombre arbitrario de clúster separado por una barra, por ejemplo «mi cluster/mi namespace». El nombre del clúster añadido de esta forma no tiene ningún impacto en el resultado del escaneo.
Azure Kubernetes Service
Para configurar un clúster AKS, se requiere una clave de API de Azure. El proceso de añadir credenciales registradas de Azure es el mismo que para los descubrimientos Azure.
Para identificar un clúster AKS, se necesitan 3 informaciones:
- el ID de la suscripción a la que está vinculado
- el nombre de su grupo de recursos, si corresponde
- el nombre del clúster
En la página de creación de la conexión sin agente, seleccionar el tipo proyecto Kubernetes y el conjunto de credenciales de Azure hará aparecer los campos específicos de Azure.
El nombre del clúster no dispone de un campo propio y debe escribirse en la dirección, seguido de una barra y luego el nombre del espacio de nombres del proyecto, por ejemplo «mi cluster/mi namespace».
Amazon Elastic Kubernetes Service
Para configurar un clúster EKS, se necesita una clave de API de AWS. Los pasos de configuración son los mismos que para los descubrimientos Amazon EC2.
Al crear la conexión sin agente de tipo proyecto Kubernetes, el campo Dirección debe tener el formato «mi cluster/mi namespace», donde «mi cluster» es el nombre del clúster en AWS y «mi namespace» es el nombre del espacio de nombres en el clúster Kubernetes.
Además de la dirección, también se debe completar en el campo Región la zona geográfica del clúster. El Rol permite opcionalmente indicar un ARN sobre el que realizar la operación AssumeRole, si es necesario.
Rancher
Para configurar un clúster Kubernetes gestionado por Rancher, se necesita una clave de API en forma de un token Bearer. Los requisitos previos son los mismos que para los descubrimientos Rancher.
El campo Dirección debe tener el formato «mi cluster/mi namespace», donde «mi cluster» corresponde al ID del clúster gestionado por Rancher (no utilizar el nombre del clúster), y «mi namespace» es el nombre del espacio de nombres en el clúster Kubernetes.
Escaneo de imágenes
Para obtener la información de vulnerabilidades, las imágenes de los proyectos Kubernetes deben ser escaneadas como imágenes Docker registradas de forma independiente.
Los proyectos Kubernetes reportan sus imágenes por digest, que sirve como clave para encontrar las imágenes escaneadas. Estas últimas deben contener una metadato IMAGE_DIGEST, declarada en la forma META:IMAGE_DIGEST|sha256:… en uno de sus análisis. Dado que el SHA-256 es el único criterio, la imagen encontrada puede ser un activo air gap, una imagen Docker, puede provenir de un registro espejo o incluso tener un nombre diferente. Para mayor fiabilidad, es preferible registrar las imágenes por digest en vez de por tag.
Para tener en cuenta nuevas imágenes Docker, el proyecto Kubernetes debe ser reanalizado.
Registro manual
Las imágenes que faltan en un proyecto Kubernetes pueden añadirse manualmente por digest desde el menú Gestión de activos > Imágenes Docker de la barra lateral, indicando en el campo Tag una versión con el formato sha256:50d858e0985ecc7f60418aaf0cc5ab587f42c2570a884095a9e8ccacd0f6545c, por ejemplo.
Para facilitar el registro manual, también es posible abrir la pestaña Tecnologías de la página de detalles del proyecto Kubernetes y hacer clic en el icono de añadir a la derecha de cada imagen Docker ausente.
Registro automático
El enfoque más sencillo para escanear todas las imágenes Docker de un proyecto Kubernetes es registrarlas automáticamente a través de un descubrimiento Docker, y más concretamente un descubrimiento Kubernetes, AKS o EKS cuyo perímetro esté definido en Imágenes en curso de ejecución.
En el caso de que las imágenes provengan de un registro Harbor, es posible configurar desde la administración, entre las herramientas externas, un escáner Harbor. Este enfoque permite escanear sin demora las nuevas imágenes Docker.
Descubrimiento de proyectos
Los descubrimientos Docker para Kubernetes, AKS y EKS ofrecen en Perímetro la opción Espacios de nombres. Esta opción permite listar los espacios de nombres presentes en los pods en lugar de listar sus imágenes.
Los proyectos así descubiertos pueden añadirse manualmente como activos desde la lista de activos descubiertos utilizando la acción agrupada Escanear con conexiones sin agente, y seleccionando como tipo Proyecto Kubernetes.
El registro de los nuevos proyectos Kubernetes puede automatizarse desde el formulario de edición del descubrimiento activando el registro automático como conexiones sin agente de tipo Proyecto Kubernetes.