¿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 el servidor de la API de Kubernetes las procese. Muchas funciones de Kubernetes requieren controladores de admisión para funcionar correctamente.

¿Qué hace IBM Cloud Kubernetes Service 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.

Revise las siguientes funciones de seguridad del servidor de la API de Kubernetes y etcd.

Maestro de Kubernetes totalmente gestionado y dedicado

Cada clúster de IBM Cloud Kubernetes Service está controlado por un nodo maestro de Kubernetes gestionado por IBM en una cuenta de IBM Cloud propiedad de IBM. El nodo maestro de Kubernetes 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 Kubernetes 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 de Kubernetes mediante la habilitación del cifrado de IBM Key Protect para el 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.
• kube-apiserver: sirve como punto de entrada principal para todas las solicitudes de gestión del clúster procedentes del nodo trabajador destinadas al maestro de Kubernetes. 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.
• kube-scheduler: decide dónde desplegar los pods, considerando los requisitos de capacidad y de rendimiento, las restricciones de política de hardware y de software, las especificaciones anti afinidad y los requisitos de 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.
• kube-controller-manager: responsable de supervisar los conjuntos de réplicas y de crear los pods correspondientes para alcanzar el estado especificado.
• Konnectivity: componente específico de IBM Cloud Kubernetes Service que proporciona conectividad de red segura para todas las comunicaciones entre nodos maestros y trabajadores de Kubernetes. 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 kubectl top, 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 Kubernetes, incluidos todos los componentes maestros y los recursos de cálculo, de red y de almacenamiento, reciben supervisión continua por parte de 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 IBM Cloud Kubernetes Service.

CIS Kubernetes Benchmark de maestro

Para configurar IBM Cloud Kubernetes Service, los ingenieros de IBM siguen las prácticas de ciberseguridad relevantes de la prueba de referencia del 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 IBM Cloud Kubernetes Service, debe autenticarse con el servicio utilizando sus credenciales. Cuando se ha autenticado, IBM Cloud Kubernetes Service genera certificados TLS que cifran la comunicación a y desde el servidor de API de Kubernetes 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 Kubernetes. Estos certificados nunca se comparten entre clústeres ni entre componentes de maestro de Kubernetes.

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, IBM Cloud Kubernetes Service establece automáticamente una conexión Konnectivity entre el maestro Kubernetes 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 IBM Cloud Kubernetes Service utilizando IBM Cloud Identity and Access Management (IAM). IBM Cloud IAM proporciona autenticación segura con la plataforma de IBM Cloud, IBM Cloud Kubernetes Service y todos los recursos de la 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 del clúster y del nodo de trabajador que un usuario puede realizar en IBM Cloud Kubernetes Service.
• 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 Kubernetes. Con los roles de RBAC, los usuarios pueden crear recursos de Kubernetes, como despliegues de aplicaciones, espacios de nombres o mapas de configuración. 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/containers?topic=containers-iam-platform-access-roles.

Acceso de pod mediante señal de cuenta de servicio

Para los clústeres que ejecutan Kubernetes 1.21 y posteriores, las señales de cuenta de servicio que utilizan los pods para comunicarse con el servidor de la API de Kubernetes tienen un límite de tiempo, se renuevan automáticamente, se circunscriben a un público concreto de usuarios (el pod) y se invalidan después de que se suprima el pod. Para continuar la comunicación con el servidor de API, debe diseñar sus apps para leer periódicamente, por ejemplo cada minuto. el valor de la señal renovada Para obtener más información, consulte Fichas de cuentas de servicio vinculadas.

Controladores de admisión

Los controladores de admisiones se implementan para características específicas en Kubernetes y IBM Cloud Kubernetes Service. 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 admisiones pueden proporcionar una capa adicional de seguridad para el clúster antes de que el servidor de API Kubernetes procese una solicitud de API.

Cuando crea un clúster, IBM Cloud Kubernetes Service instala automáticamente los controladores de admisión Kubernetes predeterminados en un orden particular en el maestro Kubernetes, 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.

¿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 IBM Cloud Kubernetes Service.

Utilice el comando ibmcloud ks worker update con regularidad (por ejemplo, mensualmente) para desplegar actualizaciones y parches de seguridad en el sistema operativo y para actualizar la versión de Kubernetes que ejecutan sus nodos trabajadores. 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 ks clusters ls o ibmcloud ks 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.

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 kubectl 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 IBM Cloud Kubernetes Service y los debe instalar el usuario para mantener seguro el nodo trabajador.

IBM Cloud Kubernetes Service utiliza un núcleo de tipo " Linux " para los nodos de trabajo. Puede ejecutar contenedores basados en cualquier distribución de Linux en IBM Cloud Kubernetes Service. 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 IBM Cloud Kubernetes Service, 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 la conformidad de los nodos trabajadores con los estándares de CIS Kubernetes Benchmark.

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 estándar, 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 IBM Cloud Kubernetes Service. 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.

Políticas AppArmor de experto

Cada nodo trabajador se configura con políticas de seguridad y acceso que se aplican mediante AppArmor que se cargan en el nodo trabajador durante el arranque. El usuario o propietario de la máquina no puede cambiar los perfiles de appArmor.

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 Kubernetes. El servidor de API de Kubernetes 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 IBM Cloud Kubernetes Service 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.

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 en el clúster para que IBM pueda supervisar el tráfico de la red y para que IBM instale automáticamente las actualizaciones de seguridad para el nodo maestro Kubernetes.

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

¿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.

IBM Cloud Kubernetes Service proporciona VLAN de IBM Cloud que garantizan un rendimiento de red de calidad y el aislamiento de 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 ks 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.

¿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.

¿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.

Si los nodos trabajadores deben acceder a un punto final público fuera del clúster, puede conectar una pasarela pública a la subred de VPC en la que se despliegan los nodos trabajadores. Por ejemplo, el clúster de VPC se puede conectar automáticamente a otros servicios de IBM Cloud que den soporte a puntos finales de servicio en la nube privado, como por ejemplo IBM Cloud Container Registry. Sin embargo, si necesita acceder a los servicios de IBM Cloud que solo dan soporte a puntos finales de servicio en la nube público, puede conectar una pasarela pública a la subred para que sus pods puedan enviar solicitudes a través de la red pública. 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.

IBM Cloud Kubernetes Service proporciona subredes de IBM Cloud VPC que garantizan un rendimiento de red de calidad y el aislamiento de 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.

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 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 IBM Cloud Kubernetes Service 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 asegurar la IP de origen dentro del clúster?

En los NLB de la versión 2.0, de forma predeterminada se conserva la dirección IP de origen de la solicitud de cliente. No obstante, en los NLB de la versión 1.0 NLB y en todos los ALB de Ingress, la dirección IP de origen de la solicitud de cliente no se conserva. Cuando se envía al clúster una solicitud de cliente para la app, a solicitud se direcciona a un pod para el NLB 1.0 o el ALB. Si no existen pods de app en el mismo nodo trabajador que el pod del servicio equilibrador de carga, el NLB o el ALB reenvía las solicitudes a un pod de app en un nodo trabajador diferente. La dirección IP de origen del paquete se cambia a la dirección IP pública del nodo trabajor en el que se ejecuta el pod de la app.

Conservar la dirección IP del cliente es útil, por ejemplo, cuando los servidores de apps tienen que aplicar políticas de control de acceso y seguridad. Para conservar la dirección IP de origen original de la solicitud de cliente, puede habilitar la conservación de IP de origen para los NLB de la versión 1.0 o los ALB de Ingress.

¿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.

Para asegurar la comunicación de servicio a servicio, puede utilizar la autenticación TLS mutua de Istio. Istio es un servicio de código fuente abierto que ofrece a los desarrolladores una forma de conectarse, proteger, gestionar y supervisar una red de microservicios, también conocida como red de servicios, en plataformas de orquestación de nube como Kubernetes.

¿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 espacios de nombres para aislar los arrendatarios y sus cargas de trabajo.

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 profundos de Kubernetes y de la infraestructura para garantizar la capacidad y la seguridad de los despliegues.

Los clústeres de varios arrendatarios utilizan espacios de nombres de Kubernetes para aislar a los arrendatarios y, por lo general, son gestionados por 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 espacios de nombres, debe configurar las políticas de RBAC adecuadas para cada espacio de nombres 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 espacios de nombres 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. Utilice las políticas de seguridad de pods (PSP) para controlar qué recursos pueden desplegar sus inquilinos 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 equilibrador de carga de aplicación (ALB) de Ingress 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 Kubernetes en un momento determinado. Todas las apps que se ejecutan en un clúster deben cumplir con la versión de la API Kubernetes actual, independientemente del equipo que posea 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 Kubernetes 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 Kubernetes 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 espacios de nombres 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?

Por defecto, todos los clústeres activan el controlador de admisión de políticas de seguridad de pods de Kubernetes, que puede utilizar para definir los requisitos que debe cumplir un pod para implantarse en un espacio de nombres. Con políticas de seguridad de pod, puede controlar el uso de contenedores con privilegios, espacios de nombres raíz, redes de host y puertos, tipos de volúmenes, sistemas de archivos de host y permisos de Linux como, por ejemplo, los ID de solo lectura o de grupo.

¿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 bloquear la ejecución de contenedores privilegiados en su clúster, considere la posibilidad de configurar políticas de seguridad de pods personalizadas.

Aplicar valores de seguridad del sistema operativo a los pods

Puede añadir la sección securityContext a sus pods 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.

Si quiere utilizar securityContext para establecer el ID de usuario runAsUser o el ID de grupo fsGroup, puede utilizar el almacenamiento en bloque al crear un almacén persistente. El almacenamiento NFS no da soporte a fsGroup y runAsUser se debe establecer a nivel de contenedor, no a nivel de pod.

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 Kubernetes solicitudes de recursos y límites de recursos 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.

Imponer autenticación según políticas

Puede añadir una anotación de Ingress a los despliegues para controlar el acceso a los servicios y a las API. Mediante el uso de App ID y de la seguridad declarativa, puede garantizar la autenticación de usuarios y la validación de señales.