Pavel Selivanov, arquitecto de soluciones de Southbridge y profesor de Slurm, realizó una presentación en DevOpsConf 2019. Esta charla es parte de uno de los temas del curso en profundidad sobre Kubernetes “Slurm Mega”.
tendrá lugar en Moscú del 18 al 20 de noviembre.
— Moscú, 22-24 de noviembre.
siempre disponible.
Debajo del corte hay una transcripción del informe.
Buenas tardes compañeros y quienes se solidarizan con ellos. Hoy hablaré de seguridad.
Veo que hoy hay muchos guardias de seguridad en el pasillo. Le pido disculpas de antemano si utilizo términos del mundo de la seguridad que no sean exactamente los habituales para usted.
Dio la casualidad de que hace unos seis meses me encontré con un clúster público de Kubernetes. Público significa que hay un enésimo número de espacios de nombres; en estos espacios de nombres hay usuarios aislados en su espacio de nombres. Todos estos usuarios pertenecen a diferentes empresas. Bueno, se suponía que este clúster debería usarse como CDN. Es decir, te dan un clúster, te dan un usuario allí, vas a tu espacio de nombres, implementas tus frentes.
Mi empresa anterior intentó vender dicho servicio. Y me pidieron que pinchara el clúster para ver si esta solución era adecuada o no.
Llegué a este grupo. Me dieron derechos limitados, espacio de nombres limitado. Los muchachos allí entendieron lo que era la seguridad. Leyeron sobre el control de acceso basado en roles (RBAC) en Kubernetes y lo modificaron para que no pudiera iniciar pods por separado de las implementaciones. No recuerdo el problema que intentaba resolver lanzando un pod sin implementación, pero realmente quería lanzar solo un pod. Para tener suerte, decidí ver qué derechos tengo en el cluster, qué puedo hacer, qué no puedo hacer y qué han metido la pata allí. Al mismo tiempo te cuento qué han configurado mal en RBAC.
Sucedió que en dos minutos recibí un administrador de su clúster, miré todos los espacios de nombres vecinos y vi allí los frentes de producción en ejecución de empresas que ya habían comprado el servicio y lo habían implementado. Apenas pude evitar ir al frente de alguien y poner alguna mala palabra en la página principal.
Te contaré con ejemplos cómo hice esto y cómo protegerte de esto.
Pero primero, déjame presentarme. Mi nombre es Pavel Selivanov. Soy arquitecto en Southbridge. Entiendo Kubernetes, DevOps y todo tipo de cosas sofisticadas. Los ingenieros de Southbridge y yo estamos construyendo todo esto y estoy dando consultoría.
Además de nuestras actividades principales, recientemente hemos lanzado proyectos denominados Slurms. Estamos tratando de llevar un poco nuestra capacidad de trabajar con Kubernetes a las masas, para enseñar a otras personas a trabajar también con K8.
¿De qué hablaré hoy? El tema del informe es obvio: la seguridad del clúster de Kubernetes. Pero quiero decir de inmediato que este tema es muy amplio y, por lo tanto, quiero aclarar de inmediato de qué definitivamente no hablaré. No hablaré de términos trillados que ya se han utilizado cientos de veces en Internet. Todo tipo de RBAC y certificados.
Hablaré sobre lo que nos molesta a mí y a mis colegas sobre la seguridad en un clúster de Kubernetes. Vemos estos problemas tanto entre los proveedores que proporcionan clústeres de Kubernetes como entre los clientes que acuden a nosotros. E incluso de clientes que nos llegan procedentes de otras empresas de consultoría administrativa. Es decir, la magnitud de la tragedia es realmente muy grande.
Hay literalmente tres puntos de los que hablaré hoy:
- Derechos de usuario frente a derechos de pod. Los derechos de usuario y los derechos de pod no son lo mismo.
- Recopilación de información sobre el clúster. Le mostraré que puede recopilar toda la información que necesita de un clúster sin tener derechos especiales en este clúster.
- Ataque DoS al cluster. Si no podemos recopilar información, podremos poner un clúster en cualquier caso. Hablaré sobre ataques DoS a elementos de control de clústeres.
Otra cosa general que mencionaré es en qué probé todo esto, sobre lo cual definitivamente puedo decir que todo funciona.
Tomamos como base la instalación de un cluster de Kubernetes usando Kubespray. Si alguien no lo sabe, este es en realidad un conjunto de roles para Ansible. Lo utilizamos constantemente en nuestro trabajo. Lo bueno es que puedes enrollarlo en cualquier lugar: puedes enrollarlo sobre trozos de hierro o hacia una nube en algún lugar. En principio, un método de instalación funciona para todo.
En este clúster tendré Kubernetes v1.14.5. Todo el clúster de Cube que consideraremos está dividido en espacios de nombres, cada espacio de nombres pertenece a un equipo separado y los miembros de este equipo tienen acceso a cada espacio de nombres. No pueden ir a diferentes espacios de nombres, sólo al suyo propio. Pero hay una determinada cuenta de administrador que tiene derechos sobre todo el clúster.
Prometí que lo primero que haremos será obtener derechos de administrador para el clúster. Necesitamos un pod especialmente preparado que rompa el clúster de Kubernetes. Todo lo que tenemos que hacer es aplicarlo al clúster de Kubernetes.
kubectl apply -f pod.yamlEste pod llegará a uno de los maestros del clúster de Kubernetes. Y después de esto, el clúster felizmente nos devolverá un archivo llamado admin.conf. En Cube, este archivo almacena todos los certificados de administrador y al mismo tiempo configura la API del clúster. Así de fácil es obtener acceso de administrador a, creo, el 98% de los clústeres de Kubernetes.
Repito, este módulo fue creado por un desarrollador de su clúster que tiene acceso para implementar sus propuestas en un pequeño espacio de nombres, todo está controlado por RBAC. No tenía derechos. Sin embargo, el certificado fue devuelto.
Y ahora sobre una cápsula especialmente preparada. Lo ejecutamos en cualquier imagen. Tomemos como ejemplo debian:jessie.
Tenemos esto:
tolerations:
- effect: NoSchedule
operator: Exists
nodeSelector:
node-role.kubernetes.io/master: "" ¿Qué es la tolerancia? Los maestros en un clúster de Kubernetes generalmente están marcados con algo llamado contaminación. Y la esencia de esta "infección" es que dice que los pods no se pueden asignar a nodos maestros. Pero nadie se molesta en indicar en ningún grupo que es tolerante a la “infección”. La sección Tolerancia simplemente dice que si algún nodo tiene NoSchedule, entonces nuestro nodo es tolerante a dicha infección y no hay problemas.
Además, decimos que nuestro under no sólo es tolerante, sino que también quiere apuntar específicamente al maestro. Porque los maestros tienen lo más delicioso que necesitamos: todos los certificados. Por lo tanto, decimos nodeSelector, y tenemos una etiqueta estándar en maestros, que le permite seleccionar de todos los nodos del clúster exactamente aquellos nodos que son maestros.
Con estas dos secciones definitivamente llegará al maestro. Y se le permitirá vivir allí.
Pero para nosotros no basta con acudir al maestro. Esto no nos dará nada. Entonces a continuación tenemos estas dos cosas:
hostNetwork: true
hostPID: true Especificamos que nuestro pod, que lanzamos, vivirá en el espacio de nombres del kernel, en el espacio de nombres de la red y en el espacio de nombres PID. Una vez que el pod se inicia en el maestro, podrá ver todas las interfaces reales y en vivo de este nodo, escuchar todo el tráfico y ver el PID de todos los procesos.
Entonces es una cuestión de pequeñas cosas. Toma etcd y lee lo que quieras.
Lo más interesante es esta característica de Kubernetes, que está presente de forma predeterminada.
volumeMounts:
- mountPath: /host
name: host
volumes:
- hostPath:
path: /
type: Directory
name: host Y su esencia es que podemos decir en el pod que lanzamos, incluso sin derechos sobre este clúster, que queremos crear un volumen de tipo hostPath. Esto significa tomar la ruta desde el host en el que ejecutaremos y tomarla como volumen. Y luego lo llamamos nombre: host. Montamos todo este hostPath dentro del pod. En este ejemplo, al directorio /host.
Lo repetiré de nuevo. Le dijimos al pod que viniera al maestro, obtuviera hostNetwork y hostPID allí y montara toda la raíz del maestro dentro de este pod.
Entiendes que en Debian tenemos bash ejecutándose, y este bash se ejecuta bajo la raíz. Es decir, acabamos de recibir root en el maestro, sin tener ningún derecho en el clúster de Kubernetes.
Luego, toda la tarea es ir al subdirectorio /host /etc/kubernetes/pki, si no me equivoco, recoger todos los certificados maestros del clúster allí y, en consecuencia, convertirse en el administrador del clúster.
Si lo miras de esta manera, estos son algunos de los derechos más peligrosos en los pods, independientemente de los derechos que tenga el usuario:
Si tengo los derechos para ejecutar un pod en algún espacio de nombres del clúster, entonces este pod tiene esos derechos de forma predeterminada. Puedo ejecutar pods privilegiados y, por lo general, todos tienen derechos, prácticamente root en el nodo.
Mi favorito es el usuario root. Y Kubernetes tiene esta opción Ejecutar como no root. Este es un tipo de protección contra un hacker. ¿Sabes qué es el “virus de Moldavia”? Si de repente eres un hacker y vienes a mi clúster de Kubernetes, entonces nosotros, malos administradores, te preguntamos: “Por favor, indica en tus pods con qué hackearás mi clúster, ejecútalo como no root. De lo contrario, sucederá que ejecutes el proceso en tu pod bajo la raíz y te resultará muy fácil hackearme. Por favor, protégete de ti mismo".
El volumen de ruta del host es, en mi opinión, la forma más rápida de obtener el resultado deseado de un clúster de Kubernetes.
¿Pero qué hacer con todo esto?
El pensamiento que debería tener cualquier administrador normal que se encuentre con Kubernetes es: “Sí, ya te lo dije, Kubernetes no funciona. Tiene agujeros. Y todo el Cubo es una mierda”. De hecho, existe la documentación y, si miras allí, hay una sección .
Este es un objeto yaml (podemos crearlo en el clúster de Kubernetes) que controla los aspectos de seguridad específicamente en la descripción de los pods. Es decir, de hecho, controla los derechos para usar cualquier hostNetwork, hostPID y ciertos tipos de volúmenes que se encuentran en los pods al inicio. Con la ayuda de Pod Security Policy, todo esto se puede describir.
Lo más interesante de la política de seguridad de Pod es que en el clúster de Kubernetes, todos los instaladores de PSP no solo no se describen de ninguna manera, sino que simplemente están deshabilitados de forma predeterminada. La política de seguridad del pod se habilita mediante el complemento de admisión.
Bien, implementemos la Política de seguridad de pods en el clúster. Digamos que tenemos algunos pods de servicios en el espacio de nombres, a los que solo tienen acceso los administradores. Digamos que, en todos los demás casos, los pods tienen derechos limitados. Porque lo más probable es que los desarrolladores no necesiten ejecutar pods privilegiados en su clúster.
Y todo parece estar bien con nosotros. Y nuestro clúster de Kubernetes no se puede piratear en dos minutos.
Hay un problema. Lo más probable es que, si tiene un clúster de Kubernetes, la supervisión esté instalada en su clúster. Incluso me atrevería a predecir que si su clúster tiene monitoreo, se llamará Prometheus.
Lo que voy a contarles será válido tanto para el operador de Prometheus como para Prometheus entregado en su forma pura. La pregunta es que si no puedo lograr que un administrador ingrese al clúster tan rápido, significa que necesito buscar más. Y puedo buscar con la ayuda de su seguimiento.
Probablemente todos lean los mismos artículos sobre Habré y el monitoreo se encuentra en el espacio de nombres de monitoreo. El gráfico de timón se llama más o menos igual para todos. Supongo que si realizas helm install stable/prometheus, terminarás con aproximadamente los mismos nombres. Y lo más probable es que ni siquiera tenga que adivinar el nombre DNS de su clúster. Porque es estándar.
A continuación tenemos ciertos desarrolladores, en los que puedes ejecutar un determinado pod. Y luego desde este pod es muy fácil hacer algo como esto:
$ curl http://prometheus-kube-state-metrics.monitoring prometheus-kube-state-metrics es uno de los exportadores de Prometheus que recopila métricas de la propia API de Kubernetes. Hay muchos datos allí, qué se está ejecutando en su clúster, qué es, qué problemas tiene con él.
Como un ejemplo sencillo:
kube_pod_container_info{namespace=“kube-system”,pod=”kube-apiserver-k8s- 1″,container=”kube-apiserver”,image=
"gcr.io/google-containers/kube-apiserver:v1.14.5"
,image_id=»docker-pullable://gcr.io/google-containers/kube- apiserver@sha256:e29561119a52adad9edc72bfe0e7fcab308501313b09bf99df4a96 38ee634989″,container_id=»docker://7cbe7b1fea33f811fdd8f7e0e079191110268f2 853397d7daf08e72c22d3cf8b»} 1
Al realizar una solicitud curl simple desde un pod sin privilegios, puede obtener la siguiente información. Si no sabe qué versión de Kubernetes está ejecutando, se lo dirá fácilmente.
Y lo más interesante es que además de acceder a kube-state-metrics, puedes acceder fácilmente a Prometheus directamente. Puede recopilar métricas desde allí. Incluso puedes crear métricas a partir de ahí. Incluso en teoría, puede crear una consulta de este tipo desde un clúster en Prometheus, que simplemente la desactivará. Y su monitoreo dejará de funcionar desde el clúster por completo.
Y aquí surge la pregunta de si algún seguimiento externo supervisa su seguimiento. Acabo de tener la oportunidad de operar en un clúster de Kubernetes sin consecuencias para mí. Ni siquiera sabrás que estoy operando allí, ya que ya no hay ningún seguimiento.
Al igual que con la PSP, parece que el problema es que todas estas tecnologías sofisticadas (Kubernetes, Prometheus) simplemente no funcionan y están llenas de agujeros. No precisamente.
Existe tal cosa - .
Si es un administrador normal, lo más probable es que sepa acerca de la Política de red que este es solo otro yaml, de los cuales ya hay muchos en el clúster. Y algunas políticas de red definitivamente no son necesarias. E incluso si lee qué es la Política de red, que es un firewall yaml de Kubernetes, le permite limitar los derechos de acceso entre espacios de nombres, entre pods, entonces seguramente decidió que el firewall en formato yaml en Kubernetes se basa en las siguientes abstracciones. ... No, no. Definitivamente esto no es necesario.
Incluso si no le dijo a sus especialistas en seguridad que usando Kubernetes puede construir un firewall muy sencillo y muy granular. Si aún no lo saben y no te molestan: "Bueno, dame, dame..." Entonces, en cualquier caso, necesitas una Política de red para bloquear el acceso a algunos lugares de servicio que se pueden extraer de tu clúster. sin autorización alguna.
Como en el ejemplo que di, puedes obtener métricas de estado de Kube desde cualquier espacio de nombres en el clúster de Kubernetes sin tener ningún derecho para hacerlo. Las políticas de red han cerrado el acceso desde todos los demás espacios de nombres al espacio de nombres de monitoreo y eso es todo: sin acceso, sin problemas. En todos los gráficos que existen, tanto el Prometheus estándar como el Prometheus que hay en el operador, simplemente hay una opción en los valores del timón para simplemente habilitar políticas de red para ellos. Sólo necesitas encenderlo y funcionarán.
Realmente hay un problema aquí. Como administrador barbudo normal, lo más probable es que haya decidido que las políticas de red no son necesarias. Y después de leer todo tipo de artículos sobre recursos como Habr, decidió que la franela, especialmente con el modo host-gateway, es lo mejor que puede elegir.
¿Qué hacer?
Puede intentar volver a implementar la solución de red que tiene en su clúster de Kubernetes, intentar reemplazarla con algo más funcional. Por el mismo Calico, por ejemplo. Pero quiero decir de inmediato que la tarea de cambiar la solución de red en un clúster de trabajo de Kubernetes no es nada trivial. Lo resolví dos veces (ambas veces, sin embargo, en teoría), pero incluso mostramos cómo hacerlo en Slurms. Para nuestros estudiantes, mostramos cómo cambiar la solución de red en un clúster de Kubernetes. En principio, puede intentar asegurarse de que no haya tiempo de inactividad en el clúster de producción. Pero probablemente no lo consigas.
Y en realidad el problema se resuelve de forma muy sencilla. Hay certificados en el clúster y usted sabe que sus certificados caducarán en un año. Bueno, y generalmente es una solución normal con certificados en el clúster: ¿por qué nos preocupamos? Crearemos un nuevo clúster cerca, dejaremos que el anterior se pudra y volveremos a implementar todo. Es cierto que cuando se pudra, tendremos que permanecer sentados un día, pero aquí hay un nuevo grupo.
Cuando levantes un nuevo grupo, al mismo tiempo inserta Calico en lugar de franela.
¿Qué hacer si sus certificados se emiten por cien años y no va a volver a implementar el clúster? Existe algo llamado Kube-RBAC-Proxy. Este es un desarrollo muy interesante, le permite integrarse como un contenedor complementario en cualquier módulo del clúster de Kubernetes. Y, de hecho, agrega autorización a este módulo a través del RBAC del propio Kubernetes.
Hay un problema. Anteriormente, esta solución Kube-RBAC-Proxy estaba integrada en Prometheus del operador. Pero luego se fue. Ahora las versiones modernas se basan en el hecho de que usted tiene una política de red y la cierra usando ellas. Y por tanto tendremos que reescribir un poco el gráfico. De hecho, si vas a , hay ejemplos de cómo utilizar esto como complementos y los gráficos deberán reescribirse mínimamente.
Hay un pequeño problema más. Prometheus no es el único que entrega sus métricas a cualquiera. Todos nuestros componentes del clúster de Kubernetes también pueden devolver sus propias métricas.
Pero como ya dije, si no puedes acceder al clúster y recopilar información, al menos puedes causar algún daño.
Así que mostraré rápidamente dos formas de arruinar un clúster de Kubernetes.
Te reirás cuando te cuente esto, son dos casos de la vida real.
Método uno. Falta de recursos.
Lancemos otra cápsula especial. Tendrá una sección como esta.
resources:
requests:
cpu: 4
memory: 4Gi Como sabe, las solicitudes son la cantidad de CPU y memoria reservada en el host para pods específicos con solicitudes. Si tenemos un host de cuatro núcleos en un clúster de Kubernetes y cuatro pods de CPU llegan allí con solicitudes, significa que no podrán llegar más pods con solicitudes a este host.
Si ejecuto un pod de este tipo, ejecutaré el comando:
$ kubectl scale special-pod --replicas=...Entonces nadie más podrá realizar la implementación en el clúster de Kubernetes. Porque todos los nodos se quedarán sin solicitudes. Y así detendré su clúster de Kubernetes. Si hago esto por la noche, puedo detener las implementaciones durante bastante tiempo.
Si volvemos a mirar la documentación de Kubernetes, veremos algo llamado Rango límite. Establece recursos para objetos del clúster. Puede escribir un objeto de rango límite en yaml, aplicarlo a ciertos espacios de nombres y luego, en este espacio de nombres, puede decir que tiene recursos predeterminados, máximos y mínimos para los pods.
Con la ayuda de tal cosa, podemos limitar a los usuarios en espacios de nombres de productos específicos de equipos en la capacidad de indicar todo tipo de cosas desagradables en sus pods. Pero desafortunadamente, incluso si le dice al usuario que no puede iniciar pods con solicitudes para más de una CPU, existe un comando de escala maravilloso, o puede escalar a través del tablero.
Y de aquí surge el método número dos. Lanzamos 11 pods. Eso son once mil millones. Esto no se debe a que se me ocurrió ese número, sino a que lo vi yo mismo.
Historia real. A última hora de la tarde estaba a punto de salir de la oficina. Veo a un grupo de desarrolladores sentados en un rincón, haciendo algo frenéticamente con sus portátiles. Me acerco a los chicos y les pregunto: "¿Qué les pasó?"
Un poco antes, alrededor de las nueve de la noche, uno de los desarrolladores se disponía a irse a casa. Y decidí: "Ahora reduciré mi solicitud a una". Presioné uno, pero Internet se ralentizó un poco. Presionó el uno nuevamente, presionó el uno y hizo clic en Entrar. Toqué todo lo que pude. Entonces Internet cobró vida y todo empezó a reducirse a este número.
Es cierto que esta historia no ocurrió en Kubernetes, en ese momento era Nomad. Terminó con el hecho de que después de una hora de nuestros intentos de detener a Nomad de sus persistentes intentos de escalar, Nomad respondió que no dejaría de escalar y que no haría nada más. "Estoy cansado, me voy". Y se acurrucó.
Naturalmente, intenté hacer lo mismo en Kubernetes. Kubernetes no estaba contento con once mil millones de pods y dijo: “No puedo. Supera los protectores bucales internos." Pero 1 de cápsulas podrían hacerlo.
En respuesta a mil millones, el Cubo no se encerró en sí mismo. Realmente comenzó a escalar. Cuanto más avanzaba el proceso, más tiempo le llevaba crear nuevas cápsulas. Pero aun así el proceso continuó. El único problema es que si puedo lanzar pods ilimitadamente en mi espacio de nombres, incluso sin solicitudes ni límites puedo lanzar tantos pods con algunas tareas que con la ayuda de estas tareas los nodos comenzarán a acumularse en la memoria, en la CPU. Cuando lanzo tantos pods, la información de ellos debería almacenarse, es decir, etcd. Y cuando llega demasiada información, el almacenamiento comienza a regresar demasiado lentamente y Kubernetes comienza a volverse aburrido.
Y un problema más... Como saben, los elementos de control de Kubernetes no son un elemento central, sino varios componentes. En particular, hay un administrador de controladores, un programador, etc. Todos estos muchachos comenzarán a hacer un trabajo estúpido e innecesario al mismo tiempo, que con el tiempo comenzará a tomar cada vez más tiempo. El administrador del controlador creará nuevos pods. El programador intentará encontrar un nuevo nodo para ellos. Lo más probable es que pronto se quede sin nuevos nodos en su clúster. El clúster de Kubernetes comenzará a funcionar cada vez más lento.
Pero decidí ir aún más lejos. Como sabes, en Kubernetes existe algo llamado servicio. Bueno, de forma predeterminada en sus clústeres, lo más probable es que el servicio funcione utilizando tablas de IP.
Si ejecuta mil millones de pods, por ejemplo, y luego usa un script para obligar a Kubernetis a crear nuevos servicios:
for i in {1..1111111}; do
kubectl expose deployment test --port 80
--overrides="{"apiVersion": "v1",
"metadata": {"name": "nginx$i"}}";
done En todos los nodos del clúster, se generarán cada vez más reglas de iptables nuevas de forma aproximadamente simultánea. Además, se generarán mil millones de reglas de iptables para cada servicio.
Revisé todo esto en varios miles, hasta diez. Y el problema es que ya en este umbral es bastante problemático hacer ssh al nodo. Porque los paquetes, al pasar por tantas cadenas, empiezan a no sentirse muy bien.
Y esto también se resuelve con la ayuda de Kubernetes. Existe un objeto de cuota de recursos de este tipo. Establece la cantidad de recursos y objetos disponibles para el espacio de nombres en el clúster. Podemos crear un objeto yaml en cada espacio de nombres del clúster de Kubernetes. Usando este objeto, podemos decir que tenemos una cierta cantidad de solicitudes y límites asignados para este espacio de nombres, y luego podemos decir que en este espacio de nombres es posible crear 10 servicios y 10 pods. Y un solo desarrollador puede al menos ahogarse por las noches. Kubernetes le dirá: "No puedes escalar tus pods a esa cantidad porque el recurso excede la cuota". Eso es todo, problema resuelto. .
A este respecto surge un punto problemático. Sientes lo difícil que se está volviendo crear un espacio de nombres en Kubernetes. Para crearlo debemos tener en cuenta muchas cosas.
Cuota de recursos + Rango límite + RBAC
• Crear un espacio de nombres
• Crear un rango límite dentro
• Crear una cuota de recursos interna
• Crear una cuenta de servicio para CI
• Crear vinculación de roles para CI y usuarios
• Opcionalmente, inicie los pods de servicio necesarios
Por lo tanto, me gustaría aprovechar esta oportunidad para compartir mis desarrollos. Existe algo llamado operador SDK. Esta es una forma que tiene un clúster de Kubernetes de escribir operadores para él. Puede escribir declaraciones usando Ansible.
Al principio estaba escrito en Ansible, y luego vi que había un operador de SDK y reescribí la función de Ansible en un operador. Esta declaración le permite crear un objeto en el clúster de Kubernetes llamado comando. Dentro de un comando, le permite describir el entorno para este comando en yaml. Y dentro del ambiente de equipo, nos permite describir que estamos asignando tantos recursos.
Chiquita .
Y en conclusión. ¿Qué hacer con todo esto?
Primero. La política de seguridad del pod es buena. Y a pesar de que ninguno de los instaladores de Kubernetes los usa hasta el día de hoy, aún necesita usarlos en sus clústeres.
La política de red no es sólo otra característica innecesaria. Esto es lo que realmente se necesita en un cluster.
LimitRange/ResourceQuota: es hora de usarlo. Empezamos a usar esto hace mucho tiempo y durante mucho tiempo estuve seguro de que todos lo estaban usando. Resultó que esto es raro.
Además de lo que mencioné durante el informe, existen características no documentadas que le permiten atacar el clúster. Publicado recientemente .
Algunas cosas son muy tristes e hirientes. Por ejemplo, bajo ciertas condiciones, los cubelets en un clúster de Kubernetes pueden entregar el contenido del directorio de brujos a un usuario no autorizado.
Hay instrucciones sobre cómo reproducir todo lo que te dije. Hay archivos con ejemplos de producción de cómo se ven ResourceQuota y Pod Security Policy. Y puedes tocar todo esto.
Gracias a todos
Fuente: habr.com