Algunas reflexiones sobre las limitaciones de seguridad de las nubes privadas
Debido a que la red está aislada, algunas herramientas de escaneo basadas en la red de la oficina y la red pública interna no pueden obtener fácilmente la información expuesta por el puerto de desarrollo.
No supondrá una carga de trabajo adicional para el desarrollo y las pruebas de la demostración.
Si el clúster dentro del vpc necesita estar expuesto a la red pública interna, entonces solo se debe exponer una ip: puerto mediante reenvío de puerto, LB, etc. Estas aplicaciones deben ser aplicaciones relativamente maduras que integren restricciones de seguridad, como la verificación de usuarios y la lista blanca de IP.
Esto requiere que restrinja el enrutamiento central y audite la IP y el puerto de la red pública especificada.
Entonces, ¿cuál es el problema?
¿Necesita habilitar grupos de seguridad en la intranet vpc?
No creo que sea necesario. En primer lugar, vpc determina que solo ciertos inquilinos (usuarios) en vpc pueden acceder a él, lo que siempre ha estado restringido a unas pocas personas.
Además, si la prueba de demostración opera con información confidencial, la gestión de usuarios generalmente la gestiona el TL. Luego, puede configurar un inquilino temporal separado para realizar pruebas y el vpc estará completamente aislado de la red pública interna.
Los usuarios suelen probar las IP y los puertos, por lo que resulta muy engorroso para los evaluadores y desarrolladores configurar las IP y los puertos especificados. Cada vez que se cambian la IP y el puerto, es necesario modificar el grupo de seguridad y el personal de operación y mantenimiento debe limpiar el grupo de seguridad. Incluso los grupos y configuraciones de seguridad deben probarse, desarrollarse e interconectarse con las operaciones. Estas cosas de alta frecuencia, alta fragmentación y repetitivas también son extremadamente perjudiciales para el crecimiento del personal de operación y mantenimiento.
Si desea liberar la operación y el mantenimiento, necesita personalizar un conjunto de herramientas de configuración para grupos de seguridad, que deben promoverse internamente y requieren una cierta cantidad de tiempo de aprendizaje.
Y el grupo de seguridad ovs restringe el modelo cni de ipvlan|veth-pair de L2 vm k8 para que no utilice el mecanismo aap. Esto da como resultado una cierta relación vinculante entre la IP del pod y el nodo k8s. Para escenarios como statefulset que requieren direcciones IP reservadas, los pods de statefulset están fijos en algunos nodos, lo que da como resultado que los pods no se puedan migrar libremente en todos los nodos, lo que genera una baja alta disponibilidad. De lo contrario, la mac correspondiente a la IP del pod cambiará, lo que provocará que la tabla de flujo cambie con más frecuencia.
El puerto virtual aap depende del puerto principal de la tarjeta de red principal de ovs, y la MAC del puerto virtual sigue al puerto principal. Por lo tanto, la ip mac de l2 ipvlan | veth par cni permanece sin cambios bajo la premisa de que el puerto de la máquina virtual no se desplaza, por lo que permanece en la tarjeta de red principal del nodo original. Esto elimina la necesidad de cambiar las IP virtuales y los grupos de seguridad.
Además, la configuración del grupo de seguridad se configura tanto en el puerto virtual como en el puerto principal. Este mantenimiento también es muy engorroso, pero en un escenario de nube privada, los beneficios son extremadamente bajos. De forma predeterminada, se implementan las restricciones establecidas por los grupos de seguridad y vpc.
La migración del puerto principal de OVS puede mantener IP y MAC sin cambios. Según la medición real de la migración en vivo de openstack vm, si el ping continúa, se perderán entre 2 y 3 paquetes.
La capa inferior depende de ovs, y la migración entre nodos (VM) de L2 ipvlan|veth-pair no puede mantener la mac sin cambios. Debido al DNS y al equilibrio de carga, mientras la IP permanezca sin cambios, perder algunos paquetes en realidad tiene poco impacto.