IBM Cloud Docs
Seguridad para Red Hat OpenShift on IBM Cloud

Seguridad para Red Hat OpenShift on IBM Cloud

Puede utilizar características integradas de seguridad en Red Hat® OpenShift® on IBM Cloud® para análisis de riesgos y protección de la seguridad. Estas características le ayudan a proteger la infraestructura del clúster y las comunicaciones en la red, a aislar sus recursos de cálculo y a garantizar la conformidad de la seguridad de los componentes de la infraestructura y de los despliegues de contenedores.

Visión general de las amenazas de seguridad para el clúster

Para evitar que el clúster se vea comprometido, debe comprender las amenazas de seguridad potenciales para el clúster y lo que puede hacer para reducir la exposición a vulnerabilidades.

Ataques externos
Atacantes que obtienen acceso al clúster, recursos desplegados, apps o información personal.
Despliegues vulnerables
Las vulnerabilidades conocidas se explotan para obtener acceso al entorno cloud y ejecutar software malicioso.
Datos comprometidos o perdidos
Almacenamiento incorrecto de datos confidenciales y falta cifrado.
Proveedores internos y de terceros
La falta de segmentación y aislamiento de red puede provocar el uso indebido de permisos legítimos.

La seguridad en la nube y la protección de sus sistemas, infraestructura y datos frente a ataques se han convertido en asuntos de gran importantes en los últimos dos años, a medida que las empresas siguen trasladando sus cargas de trabajo a la nube pública. Un clúster consta de varios componentes, y cada uno puede poner en riesgo su entorno ante ataques maliciosos. Para proteger el clúster frente a estas amenazas de seguridad, debe asegurarse de que aplica las últimas características y actualizaciones de seguridad de Red Hat OpenShift on IBM Cloud, Red Hat OpenShift y Kubernetes en todos los componentes del clúster.

Estos componentes incluyen:

Servidor de API de Red Hat OpenShift y etcd

El servidor de API de Red Hat OpenShift y el almacén de datos etcd son los componentes más confidenciales que se ejecutan en el nodo maestro de Red Hat OpenShift. Desea evitar el acceso no autorizado a estos componentes porque establecen y almacenan las configuraciones para todos los recursos que se ejecutan en el clúster, incluidos algunos valores de seguridad de las aplicaciones.

Red Hat OpenShift proporciona controles de seguridad y limita el acceso para proteger estos componentes y reducir el riesgo de ciberataques.

¿Cómo se concede el acceso a mi servidor API?

De forma predeterminada, Kubernetes requiere que cada petición pase por varias etapas antes de que se otorgue acceso al servidor de API.

Autenticación
Valida la identidad de una cuenta de servicio o de un usuario registrado.
Autorización
Limita los permisos de usuarios autenticados y cuentas de servicio para garantizar que puedan acceder y operar solo en los componentes de clúster que desee.
Control de admisiones
Valida o muta las solicitudes antes de que sean procesadas por el servidor de la API de Red Hat OpenShift. Muchas funciones de Kubernetes requieren controladores de admisión para funcionar correctamente.

¿Qué hace Red Hat OpenShift on IBM Cloud para proteger mi servidor API y mi almacén de datos etcd?

En la imagen siguiente se muestran los valores de seguridad de clúster predeterminados que abordan la autenticación, la autorización, el control de admisiones y la conectividad segura entre el nodo maestro Kubernetes y los nodos trabajadores.

Describe las etapas de seguridad cuando accedes al servidor API.
Etapas de seguridad al acceder al servidor API

Revise las siguientes funciones de seguridad del servidor de API de Red Hat OpenShift y etcd.

Nodo maestro de Red Hat OpenShift totalmente gestionado y dedicado

Cada clúster de Red Hat OpenShift on IBM Cloud está controlado por un maestro dedicado de Red Hat OpenShift gestionado por IBM en una cuenta de IBM Cloud propiedad de IBM. El nodo maestro de Red Hat OpenShift se configura con los siguientes componentes dedicados que no se comparten con otros clientes de IBM.

  • Almacén de datos de etcd: almacena todos los recursos de Kubernetes de un clúster, como Services, Deployments y Pods. Los ConfigMaps y los Secrets de Kubernetes son datos de app que se almacenan como pares de clave y valor para que los pueda utilizar una app que se ejecuta en un pod. Los datos de etcd se almacenan en el disco local del nodo maestro de Red Hat OpenShift y se realiza una copia de seguridad en IBM Cloud Object Storage. Los datos se cifran durante el tránsito a IBM Cloud Object Storage y en reposo. Puede optar por habilitar el cifrado de los datos de etcd en el disco local del maestro Red Hat OpenShift habilitando el cifrado de IBM Key Protect del clúster. Cuando los datos de etcd se envían a un pod, los datos se cifran mediante TLS para garantizar la protección y la integridad de los datos.
  • openshift-api: sirve como punto de entrada principal para todas las solicitudes de gestión del clúster procedentes del nodo trabajador destinadas al nodo maestro de Red Hat OpenShift. El servidor de API valida y procesa las solicitudes que cambian el estado de los recursos del clúster, como pods o servicios, y guarda este estado en el almacén de datos etcd.
  • openshift-controller: observa los pods recién creados y decide dónde se desplegarán en función de la capacidad, las necesidades de rendimiento, las restricciones de políticas, las especificaciones de antiafinidad y los requisitos de la carga de trabajo. Si no se encuentra ningún nodo trabajador que se ajuste a los requisitos, el pod no se despliega en el clúster. El controlador también observa el estado de los recursos de clúster, como por ejemplo los conjuntos de réplicas. Cuando cambia el estado de un recurso, por ejemplo si cae un pod de un conjunto de réplicas, el gestor del controlador inicia acciones de corrección para conseguir el estado necesario.
  • cloud-controller-manager: el gestor de controlador de nube gestiona componentes específicos del proveedor de la nube, como por ejemplo el equilibrador de carga de IBM Cloud.
  • Konnectivity: componente específico de Red Hat OpenShift on IBM Cloud que proporciona conectividad de red segura para todas las comunicaciones entre nodos maestros y trabajadores de Red Hat OpenShift. El servidor Konnectivity trabaja con el agente Konnectivity para conectar de forma segura el nodo maestro con el nodo trabajador. Esta conexión admite solicitudes apiserver proxy a los pods y servicios, y solicitudes oc exec, attach y logs a kubelet. La conexión entre los nodos trabajadores y el maestro se protege automáticamente con certificados TLS.
Supervisión continua por parte de los ingenieros de fiabilidad del sitio (SRE) de IBM

El nodo maestro de Red Hat OpenShift, incluidos todos los componentes de nodo maestro y los recursos de cálculo, de red y de almacenamiento, son supervisados continuamente por los ingenieros de fiabilidad del sitio (SRE) de IBM. Los SRE aplican los estándares de seguridad más recientes, detectan y solucionan actividades maliciosas y trabajan para garantizar la fiabilidad y la disponibilidad de Red Hat OpenShift on IBM Cloud.

CIS Kubernetes Benchmark de maestro

Para configurar Red Hat OpenShift on IBM Cloud, los ingenieros de IBM siguen las prácticas de ciberseguridad relevantes de la prueba de referencia del nodo maestro de Kubernetes que publica el Center of Internet Security (CIS). El nodo maestro del clúster y todos los nodos trabajadores se despliegan con imágenes que se ajustan a las pruebas de referencia.

Comunicación segura a través de TLS

Para utilizar Red Hat OpenShift on IBM Cloud, debe autenticarse con el servicio utilizando sus credenciales. Cuando se ha autenticado, Red Hat OpenShift on IBM Cloud genera certificados TLS que cifran la comunicación a y desde el servidor de API de Red Hat OpenShift y el almacén de datos etcd para garantizar una comunicación segura de extremo a extremo entre los nodos trabajadores y el nodo maestro de Red Hat OpenShift. Estos certificados nunca se comparten entre clústeres ni entre componentes de maestros de Red Hat OpenShift.

Conectividad con nodos trabajadores

Aunque Kubernetes protege la comunicación entre el maestro y los nodos trabajadores mediante el protocolo https, no se proporciona autenticación en el nodo trabajador de forma predeterminada. Para asegurar esta comunicación, Red Hat OpenShift on IBM Cloud establece automáticamente una conexión Konnectivity entre el maestro Red Hat OpenShift y el nodo trabajador cuando se crea el cluster.

Control de acceso preciso

Como administrador de la cuenta, puede otorgar acceso a otros usuarios para Red Hat OpenShift on IBM Cloud utilizando IBM Cloud Identity and Access Management (IAM). IBM Cloud IAM proporciona autenticación segura con la plataforma IBM Cloud, Red Hat OpenShift on IBM Cloud y todos los recursos de su cuenta. La configuración de roles de usuario y permisos adecuados es clave para limitar quién puede acceder a los recursos y para limitar el daño que un usuario puede infligir cuando se hace un uso incorrecto de permisos legítimos. Puede seleccionar entre los siguientes roles de usuario predefinidos que determinan el conjunto de acciones que el usuario puede realizar:

  • Roles de acceso a plataforma: determinan las acciones relacionadas con la gestión de clúster y de nodo trabajador que un usuario puede realizar en Red Hat OpenShift on IBM Cloud. Los roles de acceso a plataforma también asignan a los usuarios los roles RBAC basic-users y self-provisioners. Con estos roles RBAC, puede crear un proyecto Red Hat OpenShift en el clúster, en el que puede desplegar aplicaciones y otros recursos Kubernetes. Como creador del proyecto, se le asigna automáticamente el rol de RBAC de admin sobre el proyecto para que pueda controlar por completo lo que se despliega y se ejecuta en el proyecto. Sin embargo, estos roles de RBAC no otorgan acceso a otros proyectos de Red Hat OpenShift. Para ver y acceder a otros proyectos de Red Hat OpenShift, debe tener asignado el rol de acceso al servicio adecuado en IAM.
  • Roles de acceso al servicio: Determina el rol RBAC de Kubernetes que se asigna al usuario y las acciones que un usuario puede ejecutar contra el servidor API Red Hat OpenShift. Aunque el rol de RBAC basic-users y self-provisioners que está asignado con un rol de acceso a plataforma permite crear y gestionar sus propios proyectos de Red Hat OpenShift, no puede ver, acceder ni trabajar con otros proyectos de Red Hat OpenShift hasta que se le asigne un rol de acceso de servicio. Para obtener más información sobre los roles RBAC correspondientes que se asignan a un usuario y los permisos asociados, consulte Roles de acceso a servicios de IAM.
  • Infraestructura clásica: Permite acceder a los recursos de tu infraestructura clásica. Algunas acciones de ejemplo permitidas por los roles de infraestructura clásica son ver los detalles de las máquinas de los nodos trabajadores del clúster o editar recursos de red y de almacenamiento.
  • Infraestructura de VPC: habilita el acceso a los recursos de la infraestructura de VPC. Algunos ejemplos de acciones que permiten los roles de infraestructura de VPC son crear una VPC, añadir subredes, cambiar direcciones IP flotantes y crear instancias de VPC Block Storage.

Para obtener más información sobre el control de acceso en un clúster, consulte [Asignación de acceso al clúster] (/docs/openshift?topic=openshift-iam-platform-access-roles.

Controladores de admisión

Los controladores de admisiones se implementan para características específicas en Kubernetes y Red Hat OpenShift on IBM Cloud. Con los controladores de admisiones puede configurar políticas en el clúster que determinen si se permite o no una acción concreta en el clúster. En la política, puede especificar condiciones cuando un usuario no puede realizar una acción, incluso si esta acción forma parte de los permisos generales que ha asignado al usuario utilizando roles RBAC. Por lo tanto, los controladores de admisión pueden proporcionar una capa adicional de seguridad para el clúster antes de que el servidor de la API de Red Hat OpenShift procese una solicitud de API.

Cuando se crea un clúster, Red Hat OpenShift on IBM Cloud instala automáticamente los controladores de admisión Kubernetes predeterminados en un orden particular en el maestro Red Hat OpenShift, que el usuario no puede cambiar. Revise el orden de los controladores de admisión predeterminados por versión de clúster en la información de referencia del componente kube-apiserver.

Puede instalar sus propios controladores de admisión en el clúster o elegir un controlador de admisión opcional, como por ejemplo Portieris. Con Portieris se pueden bloquear despliegues de contenedor de imágenes no firmadas.

Si ha instalado controladores de admisión manualmente y ya no desea utilizarlos, elimínelos por completo. Si los controladores de admisiones no se eliminan por completo, es posible que bloqueen todas las acciones que desee realizar en el clúster.

¿Qué más puedo hacer para proteger mi servidor API?

Puede restringir la conectividad de red a su maestro de clúster de varias maneras

  • Habilite únicamente el punto final del servicio de nube privada: El punto final de servicio público solo es necesario para los clústeres clásicos de OpenShift. Se puede desactivar para todos los clusters VPC. También se puede desactivar para los clusters clásicos de Kubernetes siempre que su cuenta tenga activados VRF y Service Endpoint. Esto protege a su maestro de clúster de ataques en la red pública.
  • Habilitar restricciones basadas en contexto: puede proteger el acceso a la red a los puntos finales de servicio públicos y privados de su clúster mediante restricciones basadas en contexto (CBR). Sólo se permiten las solicitudes autorizadas a su maestro de clúster que procedan de subredes incluidas en las reglas CBR. Para obtener más información, consulte Utilización de restricciones basadas en el contexto.

Nodo de trabajador

Los nodos trabajadores se ocupan de los despliegues y los servicios que forman la app. Si aloja las cargas de trabajo en la nube pública, querrá asegurarse de que la app está protegida frente al acceso, modificación y supervisión por parte de un usuario o software no autorizado.

¿A quién pertenece el nodo trabajador y soy responsable de asegurarlo?

La propiedad de un nodo trabajador depende del tipo de clúster que haya creado y del proveedor de infraestructura que elija.

  • Clusters clásicos: Los nodos de trabajo se aprovisionan en su cuenta de IBM Cloud. Dispone de nodos trabajadores dedicados y es el responsable de solicitar actualizaciones puntuales para los nodos trabajadores para asegurarse de que el sistema operativo y los componentes de IBM Cloud Kubernetes Service aplican las últimas actualizaciones de seguridad y parches.
  • Clústeres VPC: Los nodos de trabajo se aprovisionan en una cuenta IBM Cloud propiedad de IBM para permitir la supervisión de actividades maliciosas y aplicar actualizaciones de seguridad. No puede acceder a los nodos de trabajador mediante el panel de control de VPC. Sin embargo, puede gestionar los nodos trabajadores mediante la consola de IBM Cloud Kubernetes Service, la CLI o la API. Dispone de máquinas virtuales dedicadas que componen los nodos trabajadores y es el responsable de solicitar actualizaciones puntuales para que el SO de los nodos trabajadores y los componentes de IBM Cloud Kubernetes Service apliquen las últimas actualizaciones de seguridad y parches.

Para obtener más información, consulte Sus responsabilidades al utilizar Red Hat OpenShift on IBM Cloud.

Utilice el mandato ibmcloud oc worker update periódicamente (por ejemplo, mensualmente) para desplegar actualizaciones y parches de seguridad en el sistema operativo y para actualizar la versión de Red Hat OpenShift que ejecutan los nodos de trabajador. Cuando hay actualizaciones disponibles, recibe una notificación al ver información sobre los nodos maestro y de trabajador en la consola o CLI de IBM Cloud, como por ejemplo con los mandatos ibmcloud oc clusters ls o ibmcloud oc workers ls --cluster <cluster_name>. IBM proporciona las actualizaciones de nodo trabajador como una imagen de nodo trabajador completo que incluye los parches de seguridad más recientes. Para aplicar las actualizaciones, se debe volver a crear una imagen del nodo trabajador y se debe volver a cargar con la nueva imagen. Las claves para el usuario root rotan automáticamente cuando se vuelve a cargar el nodo trabajador.

¿Qué aspecto tiene la configuración de mi nodo trabajador?

En la imagen siguiente se muestran los componentes que se configuran para cada nodo trabajador para proteger el nodo trabajador frente a ataques maliciosos.

La imagen no incluye componentes que garanticen la comunicación segura de extremo a extremo a y desde el nodo trabajador. Para obtener más información, consulte Seguridad de red.

Configuración del nodo trabajador en Red Hat OpenShift on IBM Cloud excluyendo la seguridad de la red.
Configuración del nodo de trabajo en Red Hat OpenShift on IBM Cloud excluyendo la seguridad de la red

CIS-imagen conforme
Cada nodo trabajador está configurado con un sistema operativo que implementa los puntos de referencia publicados por el Centro de Seguridad de Internet ( CIS ). El usuario o el propietario de la máquina no puede cambiar este sistema operativo a otro sistema operativo. Para revisar la versión actual del sistema operativo, ejecute oc get nodes -o wide. IBM trabaja con equipos de asesoramiento de seguridad interna y externa para abordar las vulnerabilidades potenciales de conformidad de seguridad. Las actualizaciones de seguridad y los parches para el sistema operativo están disponibles a través de Red Hat OpenShift on IBM Cloud y los debe instalar el usuario para mantener seguro el nodo trabajador.

Red Hat OpenShift on IBM Cloud utiliza un núcleo de tipo " Linux " para los nodos de trabajo. Puede ejecutar contenedores basados en cualquier distribución de Linux en Red Hat OpenShift on IBM Cloud. Consulte con su proveedor de imágenes de contenedor para verificar que sus imágenes de contenedor pueden ejecutarse en el núcleo.

Supervisión continua por parte de los ingenieros de fiabilidad del sitio (SRE)
La imagen instalada en los nodos trabajadores recibe supervisión continua por parte de los ingenieros de fiabilidad del sitio (SRE) de IBM para detectar vulnerabilidades y problemas de conformidad de seguridad. Para hacer frente a las vulnerabilidades, los SRE crean parches de seguridad y fixpacks para los nodos trabajadores. Asegúrese de aplicar estos parches cuando estén disponibles para garantizar un entorno seguro para sus nodos trabajadores y las aplicaciones que ejecute en ellos.
Prueba de referencia de nodos trabajadores de Kubernetes de CIS
Para configurar Red Hat OpenShift on IBM Cloud, los ingenieros de IBM siguen las prácticas de ciberseguridad pertinentes del nodo trabajador de referencia Kubernetes que publica el Centro de Seguridad de Internet(CIS ). Puede revisar el cumplimiento de los nodos trabajadores respecto de los estándares CIS Kubernetes Benchmark y pruebas de referencia de Red Hat OpenShift.
Aislamiento de cálculo
Los nodos de trabajador se dedican a un clúster y no alojan cargas de trabajo de otros clústeres. Cuando se crea un clúster clásico, se puede optar por aprovisionar los nodos de trabajo como máquinas físicas (bare metal) o como máquinas virtuales que se ejecutan en hardware físico compartido o dedicado. Los nodos de trabajo de un clúster VPC sólo pueden aprovisionarse como máquinas virtuales en infraestructura compartida.
Opción para despliegue nativo en el clúster clásico
Si crea un clúster clásico estándar, puede optar por suministrar los nodos trabajadores en servidores físicos nativos (en lugar de instancias de servidor virtual). Con los servidores físicos nativos, tiene más control sobre el host de cálculo, como por ejemplo la memoria o la CPU. Esta configuración elimina el hipervisor de máquina virtual que asigna recursos físicos a máquinas virtuales que se ejecutan en el host. En su lugar, todos los recursos de una máquina nativa están dedicados exclusivamente al trabajador, de modo que no es necesario preocuparse de que haya "vecinos ruidosos" que compartan recursos o ralenticen el rendimiento. Los servidores nativos están dedicados a usted, con todos los recursos disponibles para que los utilice el clúster.
Discos cifrados
De forma predeterminada, cada nodo trabajador se suministra con dos particiones de datos cifrados SSD locales AES de 256 bits. La primera partición contiene la imagen de kernel que se utiliza para arrancar el nodo trabajador y que no está cifrada. La segunda partición contiene el sistema de archivos de contenedor y se desbloquea mediante las claves de cifrado LUKS. Cada nodo trabajador de un clúster tiene su propia clave de cifrado LUKS, que gestiona Red Hat OpenShift on IBM Cloud. Cuando se crea un clúster o se añade un nodo trabajador a un clúster existente, las claves se extraen de forma segura y luego se descartan una vez desbloqueado el disco cifrado. El cifrado puede afectar al rendimiento de E/S de disco. Para las cargas de trabajo que requieren E/S de disco de alto rendimiento, pruebe un clúster con cifrado habilitado e inhabilitado para decidir mejor si desactiva el cifrado.
SELinux
Cada nodo trabajador se configura con políticas de seguridad y acceso que se aplican mediante perfiles de seguridad mejorada Linux(SELinux) que se cargan en el nodo trabajador durante el arranque. El usuario o el propietario de la máquina no puede cambiar los perfiles de SELinux.
SSH inhabilitado
De forma predeterminada, el acceso SSH está inhabilitado en el nodo trabajador para proteger el clúster frente a ataques maliciosos. Cuando el acceso SSH está inhabilitado, el acceso al clúster se impone mediante el servidor de API de Red Hat OpenShift. El servidor de API de Red Hat OpenShift requiere que cada solicitud se compruebe con las políticas establecidas en la autenticación, autorización y módulo de control de admisiones antes de que la solicitud se ejecute en el clúster.
Si tiene un clúster estándar y desea instalar más funciones en su nodo trabajador, puede elegir entre los complementos que proporciona Red Hat OpenShift on IBM Cloud o utilizar conjuntos de demonios Kubernetes para todo lo que desee ejecutar en cada nodo trabajador. Para cualquier acción puntual que deba ejecutar, utilice Kubernetes jobs.

Red

El enfoque clásico para proteger la red de una empresa consiste en configurar un cortafuegos y bloquear todo el tráfico de red no deseado dirigido a sus apps. Aunque esto sigue vigente, recientes investigaciones muestran que muchos ataques malintencionados provienen de personal interno o de usuarios autorizados que hacer un mal uso de sus permisos asignados.

Segmentación de red y privacidad para clústeres clásicos

Para proteger la red y limitar el rango de daños que puede infligir un usuario cuando se otorga el acceso a una red, debe asegurarse de que las cargas de trabajo estén tan aisladas en la medida de lo posible y de que limite el número de apps y nodos trabajadores que están expuestos públicamente.

¿Qué tráfico de red se permite por defecto en mi clúster Classic?

Todos los contenedores están protegidos por valores predefinidos de política de red de Calico que se configuran en cada nodo trabajador durante la creación del clúster. De forma predeterminada, todo el tráfico de red de salida está permitido para todos los nodos trabajadores. El tráfico de red de entrada está bloqueado con las siguientes excepciones:

  • NodePort: El rango Kubernetes NodePort está abierto por defecto para que puedas exponer apps con servicios NodePort. Para bloquear el tráfico de red de entrada en los NodePorts del clúster, consulte Control del tráfico de entrada a NLB o servicios de NodePort.
  • Puertos de supervisión de IBM: de forma predeterminada, IBM abre algunos puertos del clúster para que IBM pueda supervisar el tráfico de la red y para que IBM instale automáticamente las actualizaciones de seguridad correspondientes al nodo maestro de Red Hat OpenShift.

El acceso desde el maestro Red Hat OpenShift al kubelet del nodo trabajador está asegurado por un túnel Konnectivity. Para obtener más información, consulte el apartado sobre la arquitectura de Red Hat OpenShift on IBM Cloud.

¿Qué es la segmentación de red y cómo puedo configurarla para un clúster Classic?

La segmentación de red describe el enfoque para dividir una red en varias subredes. Puede agrupar apps y datos relacionados a los que vaya a acceder un determinado grupo de la organización. Las aplicaciones que se ejecutan en una subred no pueden ver las aplicaciones de otra subred ni acceder a ellas. La segmentación de red también limita el acceso que se proporciona a un software interno o de terceros y puede limitar el rango de actividades maliciosas.

Red Hat OpenShift on IBM Cloud proporciona VLAN de IBM Cloud que garantizan un rendimiento de red de calidad y el aislamiento de la red de los nodos trabajadores. Una VLAN configura un grupo de nodos trabajadores y pods como si estuvieran conectadas a la misma conexión física. Las VLAN están dedicadas a su cuenta de IBM Cloud y no se comparten entre los clientes de IBM. En clústeres clásicos, si tiene varias VLAN para un clúster, varias subredes en la misma VLAN o un clúster multizona, debe habilitar una función de direccionador virtual (VRF) para la cuenta de infraestructura de IBM Cloud para que los nodos trabajadores puedan comunicarse entre sí en la red privada. Para habilitar VRF, consulte Habilitación de VRF. Para comprobar si un VRF ya está habilitado, utilice el mandato ibmcloud account show. Si no puede o no desea habilitar VRF, habilite Expansión de VLAN. Para realizar esta acción, necesita el permiso Red > Administrar infraestructura de expansión de VLAN de red, o puede solicitar al propietario de la cuenta que lo habilite. Para comprobar si el spanning de VLAN ya está activado, utilice el comando ibmcloud oc vlan spanning get --region <region>.

Si habilita VRF o la distribución de VLAN para la cuenta, la segmentación de red se elimina de los clústeres.

Revise la siguiente tabla para ver las opciones sobre cómo conseguir la segmentación de red cuando se habilita VRF o la distribución de VLAN para la cuenta.

Opciones de segmentación de red
Característica de seguridad Descripción
Configuración de políticas de red personalizadas con Calico Puede utilizar la interfaz integrada de Calico para configurar políticas de red de Calico personalizadas para los nodos trabajadores. Por ejemplo, puede permitir o bloquear el tráfico de red en interfaces de red específicas, para pods específicos o servicios. Para configurar políticas de red personalizadas, debe instalar la CLI de calicoctl.
Soporte para cortafuegos de red de IBM Cloud Red Hat OpenShift on IBM Cloud es compatible con todas las ofertas de cortafuegos de IBM Cloud. Por ejemplo, puede configurar un cortafuegos con políticas de red personalizadas para proporcionar seguridad de red dedicada para el clúster estándar y para detectar y solucionar problemas de intrusión en la red. Por ejemplo, podría elegir configurar un Virtual Router Appliance para que actuase como cortafuegos para bloquear el tráfico no deseado. Si configura un cortafuegos, también debe abrir los puertos y direcciones IP necesarios para cada región para que los nodos maestro y trabajador se puedan comunicar.

¿Qué más puedo hacer para reducir la superficie de ataques externos en los clústeres clásicos?

Cuantas más apps o nodos trabajadores exponga públicamente, más pasos debe llevar a cabo para evitar ataques maliciosos externos. Revise la siguiente tabla para ver las opciones disponibles para mantener la privacidad de sus apps y nodos trabajadores.

Opciones de servicios privados y de nodos trabajadores
Característica de seguridad Descripción
Limitación del número de apps expuestas De forma predeterminada, no se puede acceder sobre internet público a las apps y servicios que se ejecutan en el clúster. Puede elegir si desea exponer sus apps al público, o si desea que solo se pueda acceder a sus apps y servicios en la red privada. Si mantiene la privacidad de las apps y los servicios, puede aprovechar las características de seguridad integradas para garantizar una comunicación segura entre nodos trabajadores y pods. Para exponer servicios y apps a Internet pública, puede utilizar rutas de Red Hat OpenShift o aprovechar el soporte de NLB y ALB de Ingress para poner los servicios a disponibilidad pública de forma segura. Asegúrese de que solo se expongan los servicios necesarios y vuelva a visitar la lista de apps expuesta con regularidad para asegurarse de que siguen siendo válidas.
Limitación de la conectividad de Internet pública con los nodos de extremo Cada nodo trabajador se configura de modo que acepte pods de app y pods de ingress o de equilibrador de carga asociados. Puede etiquetar los nodos trabajadores como nodos de extremo para forzar el despliegue de los pods del equilibrador de carga solo en estos nodos trabajadores. Además, puede marcar los nodos de trabajador para que los pods de aplicación no se puedan planificar en los nodos periféricos. Con nodos de extremo puede aislar la carga de trabajo de red en menos nodos trabajadores en el clúster y mantener la privacidad de los otros nodos trabajadores del clúster.

¿Y si quiero conectar mi clúster a un centro de datos local?

Para conectar los nodos trabajadores y las apps a un centro de datos local, puede configurar un punto final VPN IPSec con un servicio strongSwan, un dispositivo direccionador virtual o un Fortigate Security Appliance.

Segmentación de red y privacidad para clústeres de VPC

Para proteger la red y limitar el rango de daños que puede infligir un usuario cuando se otorga el acceso a una red, debe asegurarse de que las cargas de trabajo estén tan aisladas en la medida de lo posible y de que limite el número de apps y nodos trabajadores que están expuestos públicamente.

¿Qué tráfico de red está permitido por defecto para mi clúster VPC?

De forma predeterminada, los nodos de trabajador están conectados a subredes de VPC solo en la red privada y no tienen interfaz de red pública. Se bloquea toda entrada pública a los nodos de trabajador. La salida pública desde los nodos de trabajador solo se permite si los nodos de trabajador están conectados a una subred VPC que tiene una pasarela pública.

Para acceder a los componentes de Red Hat OpenShift predeterminados tales como la consola web u OperatorHub sin estar conectado a la red privada de la VPC, debe adjuntar una pasarela pública a las subredes de VPC en las que se despliegan los nodos trabajadores. Se permite todo el tráfico de salida correspondiente a los nodos trabajadores en una subred con una pasarela pública conectada, pero el tráfico de entrada sigue bloqueado.

Si despliega apps en el clúster que deben recibir solicitudes de tráfico de Internet, puede crear un equilibrador de carga de VPC para exponer las apps. Para permitir el tráfico de entrada red a las apps, debe configurar el equilibrador de carga de VPC para el tráfico de red de entrada que desea recibir.

Los grupos de seguridad se aplican a su instancia de VPC y a los ALB de VPC de forma predeterminada. Para obtener más información, consulte Control del tráfico con grupos de seguridad de VPC.

¿Qué es la segmentación de red y cómo puedo configurarla para un clúster VPC?

La segmentación de red describe el enfoque para dividir una red en varias subredes. Puede agrupar apps y datos relacionados a los que vaya a acceder un determinado grupo de la organización. Las aplicaciones que se ejecutan en una subred no pueden ver las aplicaciones de otra subred ni acceder a ellas. La segmentación de red también limita el acceso que se proporciona a un software interno o de terceros y puede limitar el rango de actividades maliciosas.

Red Hat OpenShift on IBM Cloud proporciona subredes de IBM Cloud VPC que garantizan un rendimiento de red de calidad y el aislamiento de la red de los nodos trabajadores. Una subred de VPC consta de un rango específico de direcciones IP privadas (bloque de CIDR) y configura un grupo de nodos trabajadores y pods como si estuvieran conectados a la misma conexión física. Las subredes de VPC están dedicadas a su cuenta de IBM Cloud y no se comparten entre los clientes de IBM.

Las subredes de VPC proporcionan un canal para la conectividad entre los nodos trabajadores dentro del clúster. Cualquier sistema que esté conectado a cualquiera de las subredes privadas en la misma VPC puede comunicarse con los nodos trabajadores. Por ejemplo, todas las subredes de una VPC se pueden comunicar a través del direccionamiento de capa 3 privado con un direccionador de VPC incorporado. Si los clústeres no necesitan comunicarse, puede lograr una segmentación óptima de la red creando los clústeres en VPC independientes. Si tiene varios clústeres que deben comunicarse entre sí, puede crear los clústeres en la misma VPC. Aunque las subredes contenidas en una VPC se pueden compartir entre varios clústeres de esa VPC, puede conseguir una mejor segmentación de red si utiliza distintas subredes para clústeres dentro de una VPC.

Para conseguir una mayor segmentación de red privada entre subredes de VPC para su cuenta, puede configurar políticas de red personalizadas con listas de control de accesos (ACL) de VPC. Al crear una VPC, se crea una ACL predeterminada con el formato allow-all-network-acl-<VPC_ID> para la VPC. De forma predeterminada, cualquier subred que cree en la VPC se conecta a esta ACL. La ACL incluye una regla de entrada y una regla de salida que permiten todo el tráfico entre los nodos trabajadores de una subred y cualquier sistema de las subredes de la misma VPC. Si desea especificar qué tráfico de red privada se permite a los nodos trabajadores en las subredes de VPC, puede crear una ACL personalizada para cada subred en la VPC. Por ejemplo, puede crear un conjunto de reglas de ACL para bloquear la mayor parte del tráfico de red privada de entrada y salida de un clúster, al tiempo que permite la comunicación necesaria para que el clúster funcione.

¿Qué más puedo hacer para reducir la superficie de ataques externos para clústeres VPC?

Cuantas más apps o nodos trabajadores exponga públicamente, más pasos debe llevar a cabo para evitar ataques maliciosos externos. Revise la siguiente tabla para ver las opciones disponibles para mantener la privacidad de sus apps y nodos trabajadores.

Opciones de seguridad de red de VPC
Característica de seguridad Descripción
Limitación del número de apps expuestas De forma predeterminada, no se puede acceder sobre internet público a las apps y servicios que se ejecutan en el clúster. Puede elegir si desea exponer sus apps al público, o si desea que solo se pueda acceder a sus apps y servicios en la red privada. Si mantiene la privacidad de las apps y los servicios, puede aprovechar las características de seguridad integradas para garantizar una comunicación segura entre nodos trabajadores y pods. Para exponer servicios y apps a Internet pública, puede aprovechar el soporte de equilibrador de carga de VPC y de ALB de Ingress para poner los servicios a disponibilidad pública de forma segura. Asegúrese de que solo se expongan los servicios necesarios y vuelva a visitar la lista de apps expuesta con regularidad para asegurarse de que siguen siendo válidas.
Limitación del tráfico de salida de la red pública a una subred con una pasarela pública Si los pods de los nodos trabajadores tienen que conectarse a un punto final externo público, puede conectar una pasarela pública a la subred en la que están esos nodos trabajadores.

En función de la red a la que desee conectar los nodos trabajadores, puede elegir una solución de VPN.

Exposición segura de apps con rutas

Si desea permitir el tráfico de red entrante desde Internet, puede exponer sus aplicaciones mediante el uso de rutas.

Cada clúster Red Hat OpenShift se configura automáticamente con un enrutador Red Hat OpenShift al que se asigna un nombre de dominio único y se asegura con un certificado TLS. Cuando expone la app mediante una ruta, se asigna a la app un URL del direccionador de Red Hat OpenShift.

Cuando crea una ruta para su app, puede optar por crear una ruta protegida (HTTPS) o no protegida (HTTP). En el caso de rutas protegidas, puede decidir dónde implementar la terminación de TLS, por ejemplo en el direccionador o en el pod. Para obtener más información, consulte Exposición de apps con rutas.

Exposición segura de apps con los servicios LoadBalancer e Ingress

Puede utilizar los servicios de red de equilibrador de carga de red (NLB) y de equilibrador de carga de aplicación de Ingress (ALB) para conectar sus apps a internet público o a redes privadas externas. Revise los siguientes valores opcionales para los NLB y los ALB que puede utilizar para satisfacer los requisitos de seguridad de las apps de fondo o para cifrar el tráfico a medida que circula a través del clúster.

¿Puedo utilizar grupos de seguridad para gestionar el tráfico de red de mi clúster?

Clústeres clásicos: los grupos de seguridad de IBM Cloud se aplican a la interfaz de red de un solo servidor virtual para filtrar el tráfico a nivel de hipervisor. Si desea gestionar el tráfico para cada nodo trabajador, puede utilizar grupos de seguridad. Cuando cree un grupo de seguridad, debe permitir el protocolo VRRP, que es el que utiliza Red Hat OpenShift on IBM Cloud para gestionar las direcciones IP de NLB. Para gestionar de forma uniforme el tráfico de su clúster en todos sus nodos de trabajo, utilice las políticas Calico y Kubernetes.

Clústeres de VPC: se aplican grupos de seguridad de VPC a la interfaz de red de un servidor virtual único para filtrar el tráfico a nivel de hipervisor. Puede añadir reglas de entrada y de salida al grupo de seguridad predeterminado para el clúster para gestionar el tráfico de entrada y salida a un clúster de VPC. Para obtener más información sobre los grupos de seguridad, incluidos los valores predeterminados, consulte Control del tráfico con grupos de seguridad de VPC.

Puesto que los nodos de trabajador del clúster de VPC existen en una cuenta de servicio y no se listan en el panel de control de infraestructura de VPC, no puede crear un grupo de seguridad y aplicarlo a las instancias de nodo de trabajador. Solo puede modificar los grupos de seguridad existentes que se crean para usted.

¿Cómo puedo realizar la terminación TLS con los servicios LoadBalancer e Ingress?

El servicio Ingress ofrece terminación de TLS en dos puntos en el flujo del tráfico:

  • Descifrar el paquete a su llegada: Por defecto, el ALB de entrada equilibra la carga HTTP tráfico de red a las aplicaciones en su clúster. Para equilibrar también la carga de conexiones HTTPS entrantes, puede configurar el ALB para descifrar el tráfico de red y reenviar las solicitudes descifradas a las apps expuestas en su clúster. Si utiliza el subdominio de Ingress proporcionado por IBM, puede utilizar el certificado TLS proporcionado por IBM. Si utiliza un dominio personalizado, puede utilizar su propio certificado TLS para gestionar la terminación TLS.
  • Recifrado de paquete antes de que se reenvíe a las apps en sentido ascendente: el ALB descifra las solicitudes HTTPS antes de reenviar el tráfico a las apps. Si tiene apps que requieren HTTPS y necesita que el tráfico se cifre antes de que se reenvíen a dichas apps en sentido ascendente, puede utilizar la anotación ssl-services. Si sus apps en sentido ascendente pueden manejar TLS, puede proporcionar de forma opcional un certificado contenido en un secreto TLS de autenticación mutua o de un solo sentido.

Almacén persistente

Consulte las opciones admitidas para cifrar y proteger sus datos en almacenamiento persistente en IBM Cloud.

De forma predeterminada, todas las soluciones de almacenamiento de IBM Cloud cifran automáticamente los datos en reposo con una clave de cifrado gestionada por IBM sin coste adicional. Para obtener más información, consulte los siguientes enlaces.

En función del tipo de almacenamiento que elija, puede configurar cifrado adicional con IBM Key Protect para proteger los datos en tránsito y en reposo con su propia clave de cifrado.

También puede utilizar un servicio de base de datos de IBM Cloud, como por ejemplo IBM Cloudant NoSQL DB, para persistir datos en una base de datos gestionada fuera del clúster. Se puede acceder a los datos que se almacenan con un servicio de base de datos de nube a través de clústeres, zonas y regiones. Para ver información relacionada con la seguridad, consulte la documentación de IBM Cloud específica del servicio de base de datos.

Supervisión y registro

La clave para detectar ataques maliciosos en el clúster es la supervisión y el registro adecuados de las métricas y de todos los sucesos que se producen en el clúster. La supervisión y el registro también pueden ayudarle a comprender la capacidad de clúster y la disponibilidad de los recursos para su app, lo que le ayudará a realizar una planificación consecuente para proteger sus apps frente a un tiempo de inactividad.

¿Monitorea IBM mi cluster?
Cada maestro de clúster es supervisado continuamente por IBM para controlar y remediar los ataques de denegación de servicio (DOS) a nivel de proceso. Red Hat OpenShift on IBM Cloud analiza automáticamente cada nodo en el que se despliega el maestro en busca de vulnerabilidades que se encuentran en Kubernetes, Red Hat OpenShift, y correcciones de seguridad específicas del sistema operativo. Si se encuentran vulnerabilidades, Red Hat OpenShift on IBM Cloud aplica automáticamente los arreglos y soluciona las vulnerabilidades en nombre del usuario para garantizar la protección del nodo maestro.
¿Qué información se registra?
De forma predeterminada, Red Hat OpenShift on IBM Cloud recopila automáticamente registros para los siguientes componentes de clúster:
  • Contenedores: los registros se escriben en STDOUT o STDERR.
  • Apps: los registros que se escriben en una vía de acceso específica dentro de la app.
  • Nodos trabajadores: los registros que se leen del sistema operativo Red Hat Enterprise Linux se envían a /var/log/syslog y a /var/log/auth.log.
  • Servidor de API de Red Hat OpenShift: cada acción relacionada con el clúster que se envía al servidor de API de Red Hat OpenShift se registra para fines de auditoría, y se incluye la hora, el usuario y el recurso afectado. Para más información, consulte Kubernetes audit logs. Puede acceder a estos registros mediante IBM Cloud Logs.
  • Direccionadores: registra el tráfico de red de entrada en las rutas.
  • Componentes del sistema Kubernetes: los registros procedentes de kubelet, kube-proxy y otros componentes que se ejecutan en el espacio de nombres kube-system.

Para acceder a los registros de los componentes de su clúster, configure IBM Cloud Logs. IBM Cloud Logs proporciona acceso a todos sus registros y puede agregar registros y crear sus propias vistas personalizadas en varios clústeres.

¿Cómo puedo supervisar la salud y el rendimiento de mi clúster?
Puede verificar el estado, la capacidad y el rendimiento de sus apps, servicios y nodos trabajadores supervisando los componentes de clúster y los recursos de cálculo de la consola o CLI de Red Hat OpenShift on IBM Cloud, como el uso de CPU y memoria. Para ver métricas más detalladas de su clúster, puede utilizar las funciones de supervisión integradas que se basan en tecnologías de código abierto, como Prometheus y Grafana. Prometheus se instala automáticamente cuando se crea el clúster y puede utilizar la herramienta para acceder al clúster en tiempo real y a métricas de app. Las métricas de Prometheus no se guardan de forma permanente. Para acceder a métricas históricas y para comparar métricas entre varios clústeres, utilice IBM Cloud Monitoring en su lugar.

Para configurar un sistema de detección de intrusiones basado en host (HIDS) y la supervisión de registros de eventos de seguridad (SELM), instale herramientas de terceros diseñadas para supervisar su clúster y aplicaciones en contenedores con el fin de detectar intrusiones o usos indebidos, como Twistlock o el proyecto Sysdig Falco.

¿Cómo puedo auditar los eventos que se producen en mi clúster?
Puede configurar IBM Cloud Logs en el clúster de Red Hat OpenShift on IBM Cloud. Para obtener más información, consulte la documentación Más información sobre IBM Cloud Logs.
¿Qué opciones tengo para activar la confianza en mi clúster?
De forma predeterminada, Red Hat OpenShift on IBM Cloud proporciona muchas características para los componentes de clúster para que pueda desplegar sus apps contenerizadas en un entorno de seguridad. Amplíe su nivel de confianza en su clúster para asegurarse de que lo que sucede en su clúster es lo que tiene previsto. La confianza en el clúster se puede implementar de varias maneras, tal como se muestra en el siguiente diagrama.

Despliegue de contenedores con contenido de confianza.
Despliegue de contenedores con contenido de confianza

  1. Confianza de contenido en sus imágenes: Asegúrese de la integridad de sus imágenes habilitando la confianza de contenido en IBM Cloud Container Registry. Con el contenido de confianza podrá controlar los usuarios que pueden firmar imágenes como imágenes de confianza. Después los firmantes de confianza transferirán una imagen a su registro y los usuarios podrán extraer el contenido firmado de forma que podrán verificar el origen de la misma. Para obtener más información, consulte Firma de imágenes para contenido de confianza.

  2. Container Image Security Enforcement: utilice un controlador de admisión con políticas personalizadas para poder verificar imágenes de contenedor antes de desplegarlas. Con un proyecto de aplicación de seguridad de imágenes de contenedor como Portieris, puede controlar dónde se despliegan las imágenes y asegurarse de que cumplen los requisitos de fiabilidad del contenido. Si un despliegue no cumple las políticas que ha establecido, la aplicación de la seguridad impide modificaciones en el clúster.

  3. Image Vulnerability Scanner: de forma predeterminada, Vulnerability Advisor explora imágenes almacenadas en IBM Cloud Container Registry para localizar vulnerabilidades de seguridad potenciales. Para obtener más información, consulte Gestión de imágenes de seguridad con Vulnerability Advisor.

  4. IBM Cloud Security and Compliance Center: cuando habilita IBM Cloud Security and Compliance Center, puede ver informes sobre el tráfico de red entrante y saliente sospechoso. Para obtener más información, consulte ¿Qué es IBM Cloud Security and Compliance Center?

  5. IBM Cloud® Secrets Manager: puede almacenar sus secretos de Ingress y Kubernetes en IBM Cloud® Secrets Manager. Cuando integra Secrets Manager en el clúster, establece una instancia de Secrets Manager predeterminada en la que se cargan todos los secretos de subdominio de Ingress. Para obtener más información, consulte Configuración de Secrets Manager en el clúster de Kubernetes Service.

Tiempo de ejecución de contenedor

Sus nodos trabajadores se instalan con CRI-O como interfaz de ejecución del contenedor, que está protegido por el sistema de etiquetado Security-Enhanced Linux(SELinux).

Cuando utiliza Kubernetes para interactuar con una imagen de contenedor, como por ejemplo creando un pod, el kubelet se comunica con CRI-O a través de un socket Unix, crio.sock. El socket Unix utiliza las etiquetas SELinux en la tabla siguiente para imponer las políticas adecuadas de acceso al sistema. Estas etiquetas impiden que los contenedores de usuario puedan acceder al socket de tiempo de ejecución del contenedor.

Etiquetas SELinux que se utilizan para proteger los procesos de tiempo de ejecución del contenedor.
Proceso Etiqueta SELinux
CRI-O system_u:system_r:container_runtime_t:s0
kubelet system_u:system_r:unconfined_service_t:s0
crio.sock system_u:object_r:container_var_run_t:s0
Un proceso de contenedor, como por ejemplo c14 system_u:system_r:container_t:s0:c14

Flujo de solicitud de ejemplo

El diagrama siguiente presenta un flujo de solicitud de ejemplo entre kubelet y CRI-O.

Ejemplo de flujo de peticiones entre kubelet y CRI-O.
Ejemplo de flujo de peticiones entre kubelet y CRI-O

Imagen y registro

Cada despliegue se basa en una imagen que contiene las instrucciones sobre cómo utilizar el contenedor que ejecuta la app. Estas instrucciones incluyen el sistema operativo dentro del contenedor y el software adicional que desea instalar. Para proteger la app, debe proteger la imagen y establecer comprobaciones para garantizar la integridad de la imagen.

¿Debo utilizar un registro público o privado para almacenar mis imágenes?
Los registros públicos, como por ejemplo Docker Hub, se pueden utilizar para empezar a trabajar con imágenes de Docker y Kubernetes para crear la primera app contenerizada de un clúster. Pero, cuando se trata de aplicaciones de empresa, evite los registros que no conozca o en los que no confía para proteger el clúster de imágenes maliciosas. Mantenga sus imágenes en un registro privado, como el que se proporciona en IBM Cloud Container Registry o el registro interno que se configura automáticamente en su clúster Red Hat OpenShift, y asegúrese de controlar el acceso al registro y el contenido de la imagen que se puede enviar.
¿Por qué es importante comprobar las vulnerabilidades de las imágenes?
Las investigaciones muestran que la mayoría de los ataques maliciosos aprovechan las vulnerabilidades conocidas de software y las configuraciones débiles del sistema. Cuando despliega un contenedor a partir de una imagen, el contenedor se utiliza con el sistema operativo y con los binarios adicionales que ha descrito en la imagen. Al igual que protege su máquina virtual o física, debe eliminar las vulnerabilidades conocidas en el sistema operativo y los binarios que utiliza dentro del contenedor para evitar que usuarios no autorizados accedan a la app.

Para proteger sus apps, tenga en cuenta la posibilidad de abordar las siguientes áreas:

  1. Automatizar el proceso de compilación y limitar los permisos: automatice el proceso para compilar la imagen de contenedor desde el código fuente para eliminar las variaciones y defectos del código fuente. Al integrar el proceso de creación en el conducto CI/CD, puede garantizar que la imagen solo se explora y se crea si la pasa las comprobaciones de seguridad que ha especificado. Para evitar que los desarrolladores apliquen hot fixes a imágenes confidenciales, limite el número de personas de la organización que tienen acceso al proceso de creación.

  2. Explorar las imágenes antes de desplegarlas en producción: Asegúrese de explorar cada imagen antes de desplegar un contenedor a partir de la misma. Por ejemplo, si utiliza IBM Cloud Container Registry, todas las imágenes se exploran automáticamente en busca de vulnerabilidades cuando envía la imagen a su espacio de nombres. Si se encuentran vulnerabilidades, considere la posibilidad de eliminar las vulnerabilidades o de bloquear el despliegue para dichas imágenes. Busque la persona o el equipo de su organización responsable de supervisar y eliminar las vulnerabilidades. En función de su estructura organizativa, esta persona puede formar parte de un equipo de seguridad, de operaciones o de despliegue. Habilite la fiabilidad del contenido para que las imágenes deban ser aprobadas por un firmante de confianza antes de que se puedan enviar al registro de contenedor. Luego, instale el controlador de admisión del proyecto de código abierto Portieris para bloquear las implementaciones de contenedores desde imágenes no firmadas.

  3. Explorar periódicamente los contenedores en ejecución:. Aunque haya desplegado un contenedor a partir de una imagen que haya pasado la comprobación de vulnerabilidad, el sistema operativo o los binarios que se ejecutan en el contenedor pueden volverse vulnerables con el tiempo. Para proteger la app, debe asegurarse de que los contenedores en ejecución se exploran de forma regular para que pueda detectar y solucionar las vulnerabilidades. Dependiendo de la aplicación, para añadir seguridad extra, puedes establecer un trabajo que elimine los contenedores vulnerables después de que sean detectados.

Puede utilizar el registro de contenedor integrado para automatizar el proceso de creación de imágenes de contenedor desde el código de origen de un repositorio de origen externo en el registro interno. Sin embargo, no se exploran automáticamente las imágenes en busca de vulnerabilidades cuando se envían al registro interno. Para configurar la exploración de imágenes, configure un espacio de nombres de registro y en su lugar envíe las imágenes a IBM Cloud Container Registry gestionado.

Seguridad para imágenes y despliegues
Característica de seguridad Descripción
Repositorio de imágenes privadas de Docker protegido en IBM Cloud Container Registry Configure su propio repositorio de imágenes de Docker en un registro de imágenes privadas multiarrendatario, altamente disponible y escalable que aloja y gestiona IBM. Mediante el registro, puede crear, almacenar de forma segura y compartir imágenes de Docker entre usuarios de clúster. /n Más información sobre cómo proteger la información personal al trabajar con imágenes de contenedor.
Enviar imágenes solo con contenido de confianza Garantice la integridad de las imágenes habilitando la confianza de contenido en el repositorio de imágenes. Con el contenido de confianza, puede controlar quién puede firmar imágenes como fiables y enviar por push imágenes a un espacio de nombres de registro específico. Una vez que los firmantes de confianza envían una imagen a un espacio de nombres de registro, los usuarios pueden extraer el contenido firmado para verificar la aplicación de publicación y la integridad de la imagen.
Exploración automática de vulnerabilidades Cuando utiliza IBM Cloud Container Registry, puede aprovechar la exploración de seguridad incorporada que proporciona el asesor de vulnerabilidades. Cada imagen que se publica en el espacio de nombres del registro se explora automáticamente para detectar vulnerabilidades especificadas en una base de datos de problemas conocidos de CentOS, Debian, Red Hat y Ubuntu. Si se detectan vulnerabilidades, el asesor de vulnerabilidades proporciona instrucciones sobre cómo resolverlas para garantizar la integridad y la seguridad de la imagen.
Bloquear despliegues de imágenes vulnerables o usuarios no fiables Cree un controlador de admisión con políticas personalizadas para verificar las imágenes de contenedor antes de desplegarlas. Con el proyecto de código abierto Portieris, usted controla desde dónde se despliegan las imágenes y se asegura de que cumplen los requisitos de confianza de los contenidos. Si un despliegue no cumple las políticas que ha establecido, el controlador de admisión bloquea el despliegue en el clúster.
¿Qué opciones tengo para escanear contenedores en ejecución en busca de vulnerabilidades?
Puede instalar soluciones de terceros en su clúster, como Twistlock o StackRox para escanear contenedores en ejecución y bloquear actividades maliciosas cuando se detecten.

Seguridad y aislamiento de contenedores

Cuando ejecute varias apps en el clúster, deseará asegurarse de que las cargas de trabajo se ejecutan de forma aislada unas de otras y de que restringe los permisos de los pods dentro del clúster para evitar vecinos ruidosos o ataques de tipo negación de servicio.

¿Qué es un proyecto Red Hat OpenShift y por qué debería utilizarlo?
Los proyectos de Red Hat OpenShift son una forma de particionar virtualmente un clúster y proporcionar aislamiento para los despliegues y los grupos de usuarios que deseen mover su carga de trabajo al clúster. Con los proyectos, puede organizar los recursos entre los nodos trabajadores y entre las zonas de los clústeres multizona.
Cada clúster se configura con un conjunto de proyectos de Red Hat OpenShift predeterminados que incluyen los despliegues y los servicios necesarios para que Red Hat OpenShift on IBM Cloud se ejecute correctamente y gestione el clúster. Para obtener más información, consulte Arquitectura del servicio.
Los administradores del clúster tienen automáticamente acceso a estos proyectos y pueden configurar proyectos adicionales en el clúster. Además, los usuarios del clúster a los que se otorgue acceso al clúster pueden crear su propio proyecto y, como creadores del proyecto, pueden gestionar el proyecto con permisos de administrador. Sin embargo, los usuarios del clúster no tienen acceso a otros proyectos de forma predeterminada, a menos que un administrador de clúster les otorgue acceso.

Para cada proyecto que tenga en el clúster, asegúrese de configurar políticas RBAC adecuadas para limitar el acceso a este proyecto, controlar lo que se despliega y establecer cuotas de recursos y rangos de límites adecuados.

¿Debo crear un clúster de un solo inquilino o de varios?

En un clúster de un solo arrendatario, puede crear un clúster para cada grupo de personas que deben ejecutar cargas de trabajo en un clúster. Normalmente, este equipo es el responsable de gestionar el clúster y de configurarlo y protegerlo correctamente. Los clústeres multiarrendatario utilizan varios proyectos para aislar los arrendatarios y sus cargas de trabajo.

Decidir entre un único arrendatario o un clúster de varios arrendatarios.
Clúster de inquilino único frente a clúster de inquilino múltiple

La decisión entre clústeres de un solo arrendatario y de varios arrendatarios depende del número de equipos que deben ejecutar cargas de trabajo en un clúster, sus requisitos de servicio, el tamaño del servicio y el nivel de aislamiento que desea alcanzar para las cargas de trabajo.

Un clúster de un solo arrendatario puede resultar su opción adecuada si tiene una gran cantidad de equipos con servicios complejos, y cada uno de ellos debe controlar el ciclo de vida del clúster. Esto incluye la libertad de decidir cuándo se actualiza un clúster o qué recursos se pueden desplegar en el clúster. También puede configurar un clúster de un solo arrendatario para permitir pods privilegiados sin poner a otros inquilinos en riesgo de verse comprometidos. Tenga en cuenta que para gestionar un clúster se necesitan conocimientos avanzados de Kubernetes, de Red Hat OpenShift y de la infraestructura para garantizar la capacidad y la seguridad de los despliegues.

Los clústeres de varios arrendatarios utilizan proyectos de Red Hat OpenShift para aislar a los arrendatarios y, por lo general, los gestiona un equipo independiente que no pertenece a uno de los arrendatarios. Un clúster de varios arrendatarios puede ser su opción si tiene varios equipos que deben ejecutar pequeñas cargas de trabajo en un clúster y en el que la creación de un clúster de un solo arrendatario que esté altamente disponible en varias zonas no aporte los beneficios de coste que desee. Aunque los clústeres multiarrendatarios normalmente precisan de menos personas para gestionar y administrar el clúster, es posible que no proporcionen el nivel de aislamiento que necesita y añada más complejidad en las áreas siguientes:

  • Acceso: cuando configure varios proyectos, debe configurar las políticas de RBAC adecuadas para cada proyecto para garantizar el aislamiento de recursos. Las políticas de RBAC son complejas y requieren conocimientos profundos de Kubernetes.
  • Pods privilegiados: si un arrendatario en un clúster de varios arrendatarios necesita ejecutar pods privilegiados, este pod puede acceder a otros proyectos en el clúster o dañar el host de cálculo compartido. El control de pods privilegiados es una tarea compleja que requiere un esfuerzo y una gran experiencia técnica. Use restricciones de contexto de seguridad (SCC) para controlar los recursos que sus arrendatarios pueden desplegar en el clúster.
  • Políticas de red: como los nodos trabajadores están conectados a la misma red privada, debe asegurarse de que tiene políticas de red estrictas activas para evitar que los pods accedan a pods en otros espacios de nombres.
  • Limitación de recursos informáticos: Para garantizar que cada equipo dispone de los recursos necesarios para desplegar servicios y ejecutar apps en el clúster, debes establecer cuotas de recursos para cada espacio de nombres. Las cuotas de recursos determinan las restricciones de despliegue, como el número de recursos Kubernetes que puede desplegar y la cantidad de CPU y memoria que pueden consumir dichos recursos. Después de establecer una cuota, los usuarios deben incluir los límites y las solicitudes de recursos en sus despliegues.
  • Recursos de clúster compartidos: si ejecuta varios arrendatarios en un clúster, algunos recursos de clúster, como por ejemplo el direccionador de Red Hat OpenShift, el equilibrador de carga de aplicación de Ingress (ALB) o las direcciones IP portátiles disponibles se comparten entre los arrendatarios. Es posible que a los servicios pequeños les cueste utilizar recursos compartidos si deben competir con servicios del clúster de gran tamaño.
  • Actualizaciones: solo puede ejecutar una versión de API de Red Hat OpenShift cada vez. Todas las apps que se ejecutan en un clúster deben cumplir con la versión de API de Red Hat OpenShift actual, independientemente del equipo propietario de la app. Cuando desee actualizar un clúster, debe asegurarse de que todos los equipos estén listos para cambiar a una nueva versión de API de Red Hat OpenShift y que las apps se hayan actualizado consecuentemente. Esto también significa que los equipos individuales tienen menos control sobre la versión de la API de Red Hat OpenShift que desean ejecutar.
  • Cambios en la configuración del clúster: si desea cambiar la configuración del clúster o replanificar cargas de trabajo a nuevos nodos trabajadores, debe desplegar este cambio entre los arrendatarios. Este despliegue requiere más conciliación y pruebas que en un clúster de un solo arrendatario.
  • Proceso de comunicación: cuando gestione varios arrendatarios, considere la posibilidad de configurar un proceso de comunicación para que los arrendatarios sepan a dónde ir cuando exista un problema con el clúster o cuando necesiten más recursos para sus servicios. Este proceso de comunicación también incluye informar a los arrendatarios acerca de todos los cambios en la configuración del clúster o de las actualizaciones planificadas.

Aunque los clústeres de un solo arrendatario y de varios arrendatarios tienen costes parecidos, los clústeres de un solo arrendatario proporcionan un nivel superior de aislamiento en comparación con los proyectos en un clúster de varios arrendatarios. Para un mejor aislamiento de la carga de trabajo, utilice clústeres de un solo arrendatario.

Las Políticas de red de Kubernetes protegen los pods del tráfico de la red interna. Por ejemplo, si la mayoría de los pods, o todos ellos, no requieren acceso a pods o servicios específicos, y desea asegurarse de que los pods no puedan acceder a dichos pods o servicios de forma predeterminada, puede crear una política de red de Kubernetes para bloquear el tráfico de entrada a dichos pods o servicios. Las políticas de red de Kubernetes también pueden ayudarle a imponer el aislamiento de carga de trabajo entre espacios de nombres controlando la forma en que se pueden comunicar los pods y los servicios en distintos espacios de nombres.

¿Cómo puedo controlar los permisos de los pods?
Para controlar los permisos de pod dentro de proyectos o entre proyectos, Red Hat OpenShift on IBM Cloud utiliza restricciones de contexto de seguridad (SCC). De forma predeterminada, cada clúster se configura con SCC de Red Hat OpenShift y un conjunto de SCC proporcionadas por IBM que puede asignar a cuentas de servicio, pods, despliegues o proyectos para limitar los permisos dentro del clúster. Si no asigna explícitamente un SCC, los pods utilizan la SCC de restricted. Las SCC de Red Hat OpenShift son más estrictas que las políticas de seguridad de pod predeterminadas en los clústeres de Kubernetes de comunidad. Es posible que tenga que modificar una app que se ejecuta en un clúster de Kubernetes de comunidad para que esta app pueda ejecutarse en Red Hat OpenShift. Para obtener más información, consulte Configuración de restricciones de contexto de seguridad.
¿Qué más puedo hacer para proteger mi contenedor?
Limitar el número de contenedores privilegiados. Los contenedores se ejecutan como un proceso Linux independiente en el host de cálculo que está aislado de otros procesos. Aunque los usuarios tienen acceso de usuario root dentro del contenedor, los permisos de este usuario están limitados fuera del contenedor para proteger otros procesos de Linux, el sistema de archivos de host y los dispositivos de host. Algunas apps requieren acceso al sistema de archivos de host o permisos avanzados para que se ejecuten correctamente. Puede ejecutar contenedores en modalidad privilegiada para permitir que el contenedor tenga el mismo acceso que los procesos que se ejecutan en el host de cálculo.
Tenga en cuenta que los contenedores privilegiados causan grandes daños en el clúster y en el host de cálculo subyacente si se ven comprometidos. Intente limitar el número de contenedores que se ejecutan en modalidad privilegiada y considere la posibilidad de cambiar la configuración de la app de modo que la app se pueda ejecutar sin permisos avanzados.

Si desea evitar que los contenedores privilegiados se ejecuten en el clúster, considere la posibilidad de configurar restricciones de contexto de seguridad.

Aplicar valores de seguridad del sistema operativo a los pods
Puedes personalizar las restricciones de contexto de seguridad predeterminadas para controlar el ID de usuario y el ID de grupo que pueden ejecutarse dentro del contenedor, o el ID de usuario y el ID de grupo que poseen la ruta de montaje del volumen. Establecer un ID de usuario específico ayuda a facilitar un modelo con menos privilegios. Si el contexto de seguridad no especifica un usuario, Kubernetes utiliza automáticamente el usuario especificado en la imagen de contenedor. Para obtener más información, consulte Configuración de restricciones de contexto de seguridad.
Establecer límites de CPU y de memoria para contenedores
Cada contenedor necesita una cantidad específica de CPU y de memoria para iniciarse correctamente y para continuar ejecutándose. Puede definir rangos de límites para sus contenedores o pods para limitar la cantidad de CPU y memoria que pueden consumir. Si no hay límites para la CPU y la memoria establecidos y el contenedor está ocupado, el contenedor utiliza todos los recursos disponibles. Este alto consumo de recursos puede afectar a otros contenedores del nodo de trabajador y provocar que no tengan suficientes recursos para iniciarse o ejecutarse correctamente, además de poner en riesgo el nodo de trabajador por posibles ataques de denegación de servicio.

Almacenamiento de información personal

El usuario es responsable de garantizar la seguridad de la información personal en las imágenes de contenedor y en los recursos de Kubernetes. La información personal incluye nombre, dirección, número de teléfono, dirección de correo electrónico u otra información que permita identificar, ponerse en contacto o ubicar a los clientes, o a cualquier otro individuo.

Utilización de un secreto de Kubernetes para almacenar información personal

Almacene información personal únicamente en recursos Kubernetes que estén diseñados para alojar información personal. Por ejemplo, no utilice su nombre en el nombre de un proyecto, implantación, servicio o mapa de configuración de Red Hat OpenShift. Para una protección y encriptación adecuadas, almacene la información personal en secretos.

Para la gestión centralizada de todos sus secretos entre clústeres e inyección en el tiempo de ejecución de la aplicación, pruebe IBM Cloud Secrets Manager.

Utilización de imagePullSecret de Kubernetes para almacenar credenciales de registros de imagen

No almacene información personal en espacios de nombres de registro ni imágenes de contenedor. Para una protección y cifrado adecuados, almacene las credenciales de registro en Kubernetes imagePullSecrets y otra información personal en secretos. Recuerde que si la información personal se almacena en una capa previa de una imagen, la supresión de la imagen no será suficiente para suprimir esta información personal.

Boletines de seguridad de Kubernetes

Si se encuentran vulnerabilidades en Kubernetes, Kubernetes publica CVE en boletines de seguridad para informar a los usuarios y describir las acciones que los usuarios deben tomar para remediar la vulnerabilidad. Los boletines de seguridad de Kubernetes que afectan a los usuarios de Red Hat OpenShift on IBM Cloud o a la plataforma de IBM Cloud se publican en el boletín de seguridad de IBM Cloud.

Algunos CVE requieren la actualización de parche más reciente de una versión de Red Hat OpenShift que puede instalar como parte del proceso de actualización de clúster en Red Hat OpenShift on IBM Cloud. Asegúrese de aplicar los parches de seguridad a tiempo para proteger el clúster frente a ataques maliciosos. Para más información sobre lo que incluye un parche de seguridad, consulte la información sobre la versión en Red Hat OpenShift on IBM Cloud.