{"id":39203,"date":"2019-10-31T22:28:25","date_gmt":"2019-10-31T19:28:25","guid":{"rendered":"https:\/\/prohoster.info\/blog\/zadelyvaem-dyry-v-klastere-kubernetes-doklad-i-rasshifrovka-s-devopsconf\/"},"modified":"2019-10-31T22:28:25","modified_gmt":"2019-10-31T19:28:25","slug":"zadelyvaem-dyry-v-klastere-kubernetes-doklad-i-rasshifrovka-s-devopsconf","status":"publish","type":"post","link":"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/zadelyvaem-dyry-v-klastere-kubernetes-doklad-i-rasshifrovka-s-devopsconf","title":{"rendered":"Sellando agujeros en el cl\u00faster de Kubernetes. Informe y transcripci\u00f3n de DevOpsConf.","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Pavel Selivanov, arquitecto de soluciones de Southbridge y docente de Slyurm, present\u00f3 una charla en DevOpsConf 2019. Esta charla es parte de uno de los temas del curso avanzado sobre Kubernetes \"Slyurm Mega\".<\/p>\n

<\/p>\n

Slyurm B\u00e1sico: introducci\u00f3n a Kubernetes<\/a><\/noindex> se llevar\u00e1 a cabo en Mosc\u00fa del 18 al 20 de noviembre.
\nSlyurm Mega: echamos un vistazo bajo el cap\u00f3 de Kubernetes<\/a><\/noindex> \u2014 Mosc\u00fa, del 22 al 24 de noviembre.
\nSlyurm Online: ambos cursos sobre Kubernetes<\/a><\/noindex> est\u00e1n disponibles siempre.<\/p>\n

\n

\r\n \"Reproducir\r\n
<\/div>\r\n <\/div><\/center><\/p>\n

Debajo de la l\u00ednea \u2014 transcripci\u00f3n de la charla.<\/p>\n

<\/a><\/noindex><\/p>\n

Buenos d\u00edas, colegas y simpatizantes. Hoy hablar\u00e9 sobre seguridad.<\/p>\n

<\/p>\n

Veo que hay muchos especialistas en seguridad en la sala hoy. Me disculpo de antemano si utilizo t\u00e9rminos del mundo de la seguridad de una manera que no es est\u00e1ndar para ustedes. <\/p>\n

<\/p>\n

Sucedi\u00f3 que hace aproximadamente seis meses me encontr\u00e9 con un cl\u00faster p\u00fablico de Kubernetes. P\u00fablico significa que hay una cantidad n de namespaces, en estos namespaces hay usuarios, aislados en su propio namespace. Todos estos usuarios pertenecen a diferentes empresas. Se supon\u00eda que este cl\u00faster deb\u00eda utilizarse como CDN. Es decir, se te proporciona un cl\u00faster, se te asigna un usuario, t\u00fa entras en tu namespace y despliegas tus frontales. <\/p>\n

<\/p>\n

A mi empresa anterior intentaron venderle un servicio as\u00ed. Y me pidieron que probara el cl\u00faster para ver si tal soluci\u00f3n era adecuada o no. <\/p>\n

<\/p>\n

Entr\u00e9 en este cl\u00faster. Me dieron permisos limitados, un namespace restringido. All\u00ed los chicos entend\u00edan qu\u00e9 era la seguridad. Hab\u00edan le\u00eddo sobre el control de acceso basado en roles (RBAC) de Kubernetes, y lo configuraron de tal manera que no pod\u00eda lanzar pods por separado de los deployments. No recuerdo qu\u00e9 tarea estaba intentando resolver al lanzar un pod sin un deployment, pero realmente quer\u00eda lanzar simplemente un pod. Decid\u00ed ver por suerte qu\u00e9 permisos ten\u00eda en el cl\u00faster, qu\u00e9 pod\u00eda hacer, qu\u00e9 no pod\u00eda hacer, qu\u00e9 hab\u00edan configurado all\u00ed. Tambi\u00e9n comentar\u00e9 lo que ten\u00edan mal configurado en RBAC. <\/p>\n

<\/p>\n

Sucedi\u00f3 que en dos minutos obtuve acceso de administrador a su cl\u00faster, mir\u00e9 en todos los namespaces vecinos y vi all\u00ed frontales de producci\u00f3n de empresas que ya hab\u00edan adquirido el servicio y se hab\u00edan desplegado. Me cost\u00f3 mucho detenerme para no entrar en el frontal de alguien y no colocar una palabra obscena en la p\u00e1gina principal. <\/p>\n

<\/p>\n

Voy a contar con ejemplos c\u00f3mo lo hice y c\u00f3mo se debe proteger de esto. <\/p>\n

<\/p>\n

Pero primero d\u00e9jenme presentarme. Mi nombre es Pavel Selivanov. Soy arquitecto en la empresa Southbridge. Entiendo de Kubernetes, DevOps y todo tipo de tendencias. Junto a los ingenieros de Southbridge, construimos todo esto, mientras que yo ofrezco consultor\u00eda. <\/p>\n

<\/p>\n

Adem\u00e1s de nuestras actividades principales, recientemente lanzamos proyectos llamados Sl\u00ebrmy. Intentamos llevar nuestra habilidad en el trabajo con Kubernetes a las masas, ense\u00f1ando a otros a trabajar tambi\u00e9n con K8s. <\/p>\n

<\/p>\n

Sobre lo que hablar\u00e9 hoy. El tema de la presentaci\u00f3n es evidente: la seguridad de un cl\u00faster de Kubernetes. Pero quiero aclarar desde el principio que este es un tema muy amplio y, por lo tanto, debo especificar lo que no abordar\u00e9. No hablar\u00e9 de t\u00e9rminos ya manidos que han sido tratados en Internet muchas veces, como RBAC y certificados. <\/p>\n

<\/p>\n

Voy a hablar sobre lo que a m\u00ed y a mis colegas nos preocupa respecto a la seguridad en un cl\u00faster de Kubernetes. Vemos estos problemas tanto en los proveedores que ofrecen cl\u00fasteres de Kubernetes como en los clientes que vienen a nosotros. E incluso en clientes que llegan a nosotros de otras empresas de consultor\u00eda administrativa. As\u00ed que, en realidad, la magnitud de la tragedia es bastante grande. <\/p>\n

<\/p>\n

Literalmente tres puntos que abordar\u00e9 hoy: <\/p>\n

<\/p>\n

    \n
  1. Derechos de los usuarios vs derechos de los pods. Los derechos de los usuarios y los derechos de los pods no son lo mismo. <\/li>\n
  2. Recopilaci\u00f3n de informaci\u00f3n sobre el cl\u00faster. Mostrar\u00e9 c\u00f3mo se puede recopilar toda la informaci\u00f3n del cl\u00faster que sea necesaria sin tener derechos especiales en este cl\u00faster. <\/li>\n
  3. Ataque DoS al cl\u00faster. Si no podemos recopilar informaci\u00f3n, a\u00fan as\u00ed podemos colapsar el cl\u00faster. Hablar\u00e9 sobre ataques DoS a los componentes de control del cl\u00faster. <\/li>\n<\/ol>\n

    <\/p>\n

    Otra cosa general que mencionar\u00e9 es sobre qu\u00e9 he estado realizando todas estas pruebas, y de lo que puedo afirmar que funciona.<\/p>\n

    <\/p>\n

    Tomamos como base la instalaci\u00f3n de un cl\u00faster de Kubernetes usando Kubespray. Si alguien no lo sabe, es, de hecho, un conjunto de roles para Ansible. Lo utilizamos constantemente en nuestro trabajo. Es bueno porque se puede implementar en cualquier lugar: en hardware local o en la nube. Un m\u00e9todo de instalaci\u00f3n es adecuado en principio para todo. <\/p>\n

    <\/p>\n

    En este cl\u00faster tendr\u00e9 Kubernetes v1.14.5. Todo el cl\u00faster de Kube que vamos a considerar est\u00e1 dividido en namespaces, cada namespace pertenece a un equipo distinto y solo los miembros de ese equipo tienen acceso a su namespace. No pueden acceder a otros namespaces, solo al suyo. Pero hay una cuenta de administrador que tiene derechos sobre todo el cl\u00faster. <\/p>\n

    <\/p>\n

    \"Sellando<\/p>\n

    <\/p>\n

    Promet\u00ed que lo primero que har\u00edamos ser\u00eda obtener derechos de administrador en el cl\u00faster. Necesitamos un pod espec\u00edficamente preparado que romper\u00e1 el cl\u00faster de Kubernetes. Todo lo que necesitamos hacer es aplicarlo en el cl\u00faster de Kubernetes. <\/p>\n

    <\/p>\n

    kubectl apply -f pod.yaml<\/code><\/pre>\n
    <\/p>\n
    Este pod llegar\u00e1 a uno de los masters del cl\u00faster de Kubernetes. Y despu\u00e9s de esto, el cl\u00faster felizmente nos devolver\u00e1 un archivo llamado admin.conf. En Kube, este archivo almacena todos los certificados del administrador y adem\u00e1s configura la API del cl\u00faster. As\u00ed de f\u00e1cil se puede obtener acceso de administrador, creo que en el 98% de los cl\u00fasteres de Kubernetes. <\/p>\n
    <\/p>\n
    Reitero, este pod fue creado por un desarrollador en su cl\u00faster, que tiene acceso para desplegar sus propuestas en un peque\u00f1o namespace, y est\u00e1 totalmente restringido por RBAC. No ten\u00eda ning\u00fan permiso. Sin embargo, el certificado fue devuelto. <\/p>\n
    <\/p>\n
    Ahora hablemos del pod especialmente preparado. Lo ejecutamos en cualquier imagen. Para este ejemplo, tomaremos debian:jessie. <\/p>\n
    <\/p>\n
    Tenemos algo as\u00ed: <\/p>\n
    <\/p>\n
    tolerations:\n-   effect: NoSchedule \n    operator: Exists \nnodeSelector: \n    node-role.kubernetes.io\/master: \"\" <\/code><\/pre>\n
    <\/p>\n
    \u00bfQu\u00e9 es una tolerancia? Los masters en el cl\u00faster de Kubernetes generalmente est\u00e1n marcados con algo que se llama taint (\"contaminaci\u00f3n\" en ingl\u00e9s). Y la esencia de esta \"contaminaci\u00f3n\" es que no se pueden asignar pods a los nodos master. Pero nadie impide que se indique en cualquier pod que es tolerante a esta \"contaminaci\u00f3n\". La secci\u00f3n Toleration dice que si en alg\u00fan nodo hay NoSchedule, nuestro pod es tolerante a esta contaminaci\u00f3n \u2014 y no habr\u00e1 problema. <\/p>\n
    <\/p>\n
    Luego, decimos que nuestro pod no solo es tolerante, sino que tambi\u00e9n quiere ser asignado espec\u00edficamente a un master. Porque en los masters se encuentra lo m\u00e1s valioso que necesitamos: todos los certificados. Por lo tanto, indicamos nodeSelector \u2014 y tenemos una etiqueta est\u00e1ndar en los masters que permite seleccionar entre todos los nodos del cl\u00faster aquellos que son masters. <\/p>\n
    <\/p>\n
    Con esas dos secciones, el pod definitivamente llegar\u00e1 al master. Y se le permitir\u00e1 residir all\u00ed. <\/p>\n
    <\/p>\n
    Pero simplemente llegar al master no es suficiente. Eso no nos dar\u00e1 nada. Por lo tanto, a continuaci\u00f3n tenemos estas dos cosas:<\/p>\n
    <\/p>\n
    hostNetwork: true \nhostPID: true <\/code><\/pre>\n
    <\/p>\n
    Indicamos que nuestro pod, que vamos a ejecutar, vivir\u00e1 en el espacio de nombres del n\u00facleo, en el espacio de nombres de la red y en el espacio de nombres de PID. Una vez que el pod se inicie en el maestro, podr\u00e1 ver todas las interfaces reales y activas de este nodo, escuchar todo el tr\u00e1fico y ver el PID de todos los procesos.<\/p>\n
    <\/p>\n
    Luego, solo queda poco. Toma etcd y lee lo que quieras. <\/p>\n
    <\/p>\n
    Lo m\u00e1s interesante es esta capacidad de Kubernetes, que est\u00e1 presente por defecto. <\/p>\n
    <\/p>\n
    volumeMounts:\n- mountPath: \/host \n  name: host \nvolumes:\n- hostPath: \n    path: \/ \n    type: Directory \n  name: host <\/code><\/pre>\n
    <\/p>\n
    Y la esencia de esto es que podemos en el pod que estamos ejecutando, incluso sin tener derechos en este cl\u00faster, decir que queremos crear un volumen de tipo hostPath. Es decir, tomar la ruta del host en el que vamos a ejecutarnos y usarla como volumen. Luego lo llamamos name: host. Montamos todo este hostPath dentro del pod. En este ejemplo, en el directorio \/host. <\/p>\n
    <\/p>\n
    Reitero. Hemos dicho al pod que venga al maestro, obtenga hostNetwork y hostPID, y monte todo el root del maestro dentro de este pod. <\/p>\n
    <\/p>\n
    Entiendes que en Debian tenemos bash en ejecuci\u00f3n, y este bash trabaja bajo root. Es decir, acabamos de obtener acceso root en el maestro, sin tener alg\u00fan tipo de derechos en el cl\u00faster de Kubernetes.<\/p>\n
    <\/p>\n
    Luego, la tarea es entrar en el pod en el directorio \/host \/etc\/kubernetes\/pki, si no me equivoco, y recoger todos los certificados maestros del cl\u00faster y, por lo tanto, convertirnos en administradores del cl\u00faster. <\/p>\n
    <\/p>\n
    Si lo miramos as\u00ed, estos son algunos de los permisos m\u00e1s peligrosos en los pods, a pesar de los derechos que tenga el usuario:
    \n\"Sellando<\/p>\n
    <\/p>\n
    Si tengo permiso para ejecutar un pod en alg\u00fan espacio de nombres del cl\u00faster, entonces el pod tiene esos permisos por defecto. Puedo ejecutar pods privilegiados, y eso es pr\u00e1cticamente tener acceso root en el nodo. <\/p>\n
    <\/p>\n
    Mi favorito es el usuario root. Y Kubernetes tiene una opci\u00f3n llamada Run As Non-Root. Es una especie de protecci\u00f3n contra hackers. \u00bfSaben qu\u00e9 es el 'virus moldavo'? Si eres un hacker y llegas a mi cl\u00faster de Kubernetes, nosotros, los pobres administradores, pedimos: 'Por favor, especifiquen en sus pods, que usar\u00e1n para hackear mi cl\u00faster, run as non-root. De lo contrario, podr\u00edas iniciar un proceso en tu pod como root y ser\u00eda muy f\u00e1cil hackearme. Prot\u00e9gete, por favor, a ti mismo'. <\/p>\n
    <\/p>\n
    El volumen de ruta del host, en mi opini\u00f3n, es la forma m\u00e1s r\u00e1pida de obtener el resultado deseado del cl\u00faster de Kubernetes. <\/p>\n
    <\/p>\n
    \u00bfPero qu\u00e9 hacer con todo esto? <\/p>\n
    <\/p>\n
    Pensamientos que deber\u00edan venir a cualquier administrador normal que se enfrenta a Kubernetes: \"Ah, ya lo dije, Kubernetes no funciona. Tiene fallos. Y todo Kubernetes es una tonter\u00eda\". En realidad, hay algo llamado documentaci\u00f3n, y si se mira, hay una secci\u00f3n Pol\u00edtica de Seguridad de Pods<\/a><\/noindex>. <\/p>\n
    <\/p>\n
    Es un objeto yaml que podemos crear en el cl\u00faster de Kubernetes, que controla los aspectos de seguridad espec\u00edficamente en la descripci\u00f3n de los pods. Es decir, de hecho, controla los derechos para utilizar diversos hostNetwork, hostPID y ciertos tipos de vol\u00famenes que existen en los pods al iniciar. Con la Pol\u00edtica de Seguridad de Pods todo esto se puede describir. <\/p>\n
    <\/p>\n
    Lo m\u00e1s interesante de la Pol\u00edtica de Seguridad de Pods es que en el cl\u00faster de Kubernetes, la PSP no est\u00e1 simplemente descrita en ninguna parte, est\u00e1 desactivada por defecto. La Pol\u00edtica de Seguridad de Pods se activa a trav\u00e9s de un plugin de admisi\u00f3n.<\/p>\n
    <\/p>\n
    Bien, desplegaremos la Pol\u00edtica de Seguridad de Pods en el cl\u00faster, digamos que tenemos ciertos pods de servicio en un namespace al que solo tienen acceso los administradores. Digamos que en todos los dem\u00e1s, los pods tienen derechos limitados. Porque probablemente los desarrolladores no necesitan ejecutar pods privilegiados en su cl\u00faster. <\/p>\n
    <\/p>\n
    Y parece que todo va bien. Y nuestro cl\u00faster de Kubernetes no puede ser hackeado en dos minutos. <\/p>\n
    <\/p>\n
    Hay un problema. Lo m\u00e1s probable es que si tienes un cl\u00faster de Kubernetes, tienes alg\u00fan tipo de monitoreo instalado. Me atrevo a predecir que si hay un monitoreo en tu cl\u00faster, se llama Prometheus. <\/p>\n
    <\/p>\n
    Lo que voy a contar ahora ser\u00e1 v\u00e1lido tanto para el operador de Prometheus como para Prometheus instalado en su forma pura. La cuesti\u00f3n es que si no puedo conseguir un administrador r\u00e1pidamente en el cl\u00faster, significa que necesito buscar m\u00e1s. Y puedo buscar usando tu monitoreo.<\/p>\n
    <\/p>\n
    Probablemente todos han le\u00eddo los mismos art\u00edculos en Habr, y el monitoreo se encuentra en el namespace monitoring. El gr\u00e1fico de Helm de todos se llama aproximadamente igual. Supongo que si haces helm install stable\/prometheus, tendr\u00e1s nombres aproximadamente iguales. Y es muy probable que no tenga que adivinar el nombre DNS en tu cl\u00faster. Porque es est\u00e1ndar. <\/p>\n
    <\/p>\n
    \"Sellando<\/p>\n
    <\/p>\n
    Luego tenemos alg\u00fan namespace dev, en el que se puede lanzar un pod. Y desde ese pod es muy f\u00e1cil hacer lo siguiente: <\/p>\n
    <\/p>\n
    $ curl http:\/\/prometheus-kube-state-metrics.monitoring <\/code><\/pre>\n
    <\/p>\n
    prometheus-kube-state-metrics es un exportador de Prometheus que recopila m\u00e9tricas de la API de Kubernetes. Hay mucha informaci\u00f3n sobre lo que est\u00e1 ejecut\u00e1ndose en su cl\u00faster, qu\u00e9 es y qu\u00e9 problemas puede tener. <\/p>\n
    <\/p>\n
    Como un ejemplo sencillo: <\/p>\n
    <\/p>\n
    kube_pod_container_info{namespace=\u00abkube-system\u00bb,pod=\u00abkube-apiserver-k8s-1\u00bb,container=\u00abkube-apiserver\u00bb,image= <\/p>\n
    <\/p>\n
    \u00abgcr.io\/google-containers\/kube-apiserver:v1.14.5\u00bb <\/strong><\/p>\n
    <\/p>\n
    ,image_id=\u00abdocker-pullable:\/\/gcr.io\/google-containers\/kube-apiserver@sha256:e29561119a52adad9edc72bfe0e7fcab308501313b09bf99df4a9638ee634989\u00bb,container_id=\u00abdocker:\/\/7cbe7b1fea33f811fdd8f7e0e079191110268f2853397d7daf08e72c22d3cf8b\u00bb} 1 <\/p>\n
    <\/p>\n
    Al realizar una simple solicitud curl desde un pod no privilegiado, se puede obtener esta informaci\u00f3n. Si no sabes en qu\u00e9 versi\u00f3n de Kubernetes est\u00e1s ejecutando, \u00e9l te lo dir\u00e1 f\u00e1cilmente. <\/p>\n
    <\/p>\n
    Y lo m\u00e1s interesante es que, adem\u00e1s de consultar kube-state-metrics, puedes consultar Prometheus directamente con el mismo \u00e9xito. Puedes recopilar m\u00e9tricas de all\u00ed. Incluso puedes construir m\u00e9tricas desde all\u00ed. Te\u00f3ricamente, podr\u00edas hacer una consulta desde el cl\u00faster a Prometheus que simplemente lo apague. Y tu monitoreo dejar\u00eda de funcionar completamente. <\/p>\n
    <\/p>\n
    Y aqu\u00ed surge la pregunta: \u00bfmonitorea alg\u00fan monitoreo externo tu monitoreo? Acabo de obtener la capacidad de actuar en el cl\u00faster de Kubernetes sin ninguna consecuencia para m\u00ed. Ni siquiera te dar\u00e1s cuenta de que estoy actuando all\u00ed, ya que no hay monitoreo. <\/p>\n
    <\/p>\n
    De la misma manera que con PSP, da la sensaci\u00f3n de que el problema es que todas estas tecnolog\u00edas de moda \u2014 Kubernetes, Prometheus \u2014 simplemente no funcionan y est\u00e1n llenas de fallas. En realidad, no es as\u00ed. <\/p>\n
    <\/p>\n
    Hay algo llamado \u2014 Pol\u00edtica de Red<\/a><\/noindex>.<\/p>\n
    <\/p>\n
    Si eres un administrador normal, probablemente sepas que la Pol\u00edtica de Red es otro yaml m\u00e1s, de los que hay much\u00edsimos en el cl\u00faster. Y algunas Pol\u00edticas de Red definitivamente no son necesarias. Y aunque hayas le\u00eddo qu\u00e9 es una Pol\u00edtica de Red, que es un cortafuegos yaml de Kubernetes que permite limitar los permisos de acceso entre espacios de nombres y entre pods, definitivamente decidir\u00edas que un cortafuegos en formato yaml en Kubernetes es solo otra abstracci\u00f3n... No, no. Esto definitivamente no es necesario. <\/p>\n
    <\/p>\n
    Incluso si sus especialistas en seguridad no les han dicho que se puede construir un firewall muy granular de manera muy f\u00e1cil y sencilla con su Kubernetes. Si a\u00fan no lo saben y no les est\u00e1n diciendo: \u00abBueno, denme, denme...\u00bb. De todos modos, necesita la Network Policy para restringir el acceso a ciertos lugares de servicio, que se pueden consultar desde su cl\u00faster sin ning\u00fan tipo de autorizaci\u00f3n. <\/p>\n
    <\/p>\n
    Como en el ejemplo que mencion\u00e9, se puede consultar kube state metrics desde cualquier namespace en el cl\u00faster de Kubernetes sin tener derechos para ello. Las pol\u00edticas de red cerraron el acceso desde todos los dem\u00e1s namespaces al namespace de monitoreo y as\u00ed es todo: sin acceso, sin problemas. En todos los charts que est\u00e1n, tanto en el Prometheus est\u00e1ndar como en aquel que est\u00e1 en el operador, simplemente hay una opci\u00f3n en los values del helm para activar las pol\u00edticas de red para ellos. Solo es necesario activarlas y funcionar\u00e1n. <\/p>\n
    <\/p>\n
    Sin embargo, hay un problema aqu\u00ed. Siendo un buen administrador con barba, probablemente decidi\u00f3 que las pol\u00edticas de red no son necesarias. Y tras leer varios art\u00edculos en recursos como Habr, decidi\u00f3 que flannel, especialmente en modo host-gateway, es lo mejor que puede elegir. <\/p>\n
    <\/p>\n
    \u00bfQu\u00e9 hacer? <\/p>\n
    <\/p>\n
    Puede intentar redeplegar la soluci\u00f3n de red que tiene en su cl\u00faster de Kubernetes, intentar reemplazarla por algo m\u00e1s funcional. Por ejemplo, Calico. Pero quiero decir de inmediato que cambiar la soluci\u00f3n de red en un cl\u00faster de Kubernetes en producci\u00f3n es una tarea bastante no trivial. Yo lo he hecho dos veces (ambas veces, sin embargo, de manera te\u00f3rica), pero incluso en Slurm mostramos c\u00f3mo hacerlo. A nuestros estudiantes les mostramos c\u00f3mo cambiar la soluci\u00f3n de red en el cl\u00faster de Kubernetes. En principio, puede intentar hacerlo de tal manera que en el cl\u00faster de producci\u00f3n no haya tiempo de inactividad. Pero probablemente no tendr\u00e1 \u00e9xito. <\/p>\n
    <\/p>\n
    Y el problema, en realidad, se resuelve de manera muy simple. En el cl\u00faster hay certificados, y usted sabe que los certificados se caducar\u00e1n en un a\u00f1o. Bueno, y generalmente la soluci\u00f3n normal con certificados en el cl\u00faster es: \u00bfpor qu\u00e9 molestarnos?, levantaremos un nuevo cl\u00faster al lado, dejaremos que el antiguo se caduque, y lo reaplicaremos todo. Es cierto que, cuando se caduque, estaremos un d\u00eda sin nada, pero al menos tendremos un nuevo cl\u00faster. <\/p>\n
    <\/p>\n
    Cuando levante el nuevo cl\u00faster, tambi\u00e9n inserte Calico en lugar de flannel. <\/p>\n
    <\/p>\n
    \u00bfQu\u00e9 hacer si tiene certificados emitidos por cien a\u00f1os y no tiene planes de redeplegar el cl\u00faster? Hay una herramienta llamada Kube-RBAC-Proxy. Es un desarrollo excelente que permite integrarse como un contenedor sidecar a cualquier pod en el cl\u00faster de Kubernetes. Y, de hecho, agrega autorizaci\u00f3n a ese pod a trav\u00e9s del RBAC de Kubernetes. <\/p>\n
    <\/p>\n
    Sin embargo, hay un problema. Antes, la soluci\u00f3n Kube-RBAC-Proxy estaba integrada en el operador de Prometheus. Pero luego desapareci\u00f3. Actualmente, las versiones modernas se basan en que tenga pol\u00edticas de red y las use para cerrarlas. Por lo tanto, ser\u00e1 necesario reescribir un poco el chart. De hecho, si accede a este repositorio<\/a><\/noindex>, hay ejemplos de c\u00f3mo utilizarlo como sidecars, y los charts tendr\u00e1n que ser reescritos de forma m\u00ednima. <\/p>\n
    <\/p>\n
    Hay otro peque\u00f1o problema. No solo Prometheus entrega sus m\u00e9tricas a cualquiera. Todos los componentes del cl\u00faster de Kubernetes tambi\u00e9n pueden emitir sus propias m\u00e9tricas. <\/p>\n
    <\/p>\n
    Pero como ya mencion\u00e9, si no puede acceder al cl\u00faster y recopilar informaci\u00f3n, al menos puede causar algo de da\u00f1o. <\/p>\n
    <\/p>\n
    As\u00ed que r\u00e1pidamente mostrar\u00e9 dos formas en las que se puede perjudicar la salud de un cl\u00faster de Kubernetes. <\/p>\n
    <\/p>\n
    Se reir\u00e1 cuando le cuente esto, son dos casos de la vida real. <\/p>\n
    <\/p>\n
    M\u00e9todo uno. Agotamiento de recursos. <\/p>\n
    <\/p>\n
    Iniciamos otro pod especial. Tendr\u00e1 la siguiente secci\u00f3n. <\/p>\n
    <\/p>\n
    resources: \n    requests: \n        cpu: 4 \n        memory: 4Gi <\/code><\/pre>\n
    <\/p>\n
    Como saben, los requests son la cantidad de CPU y memoria que se reserva en el host para los pods espec\u00edficos con requests. Si tenemos un host de cuatro n\u00facleos en el cl\u00faster de Kubernetes, y llega un pod con requests de cuatro por CPU, significa que no podr\u00e1 llegar ning\u00fan otro pod con requests a este host. <\/p>\n
    <\/p>\n
    Si inicio este pod, luego ejecutar\u00e9 el comando: <\/p>\n
    <\/p>\n
    $ kubectl scale special-pod --replicas=...<\/code><\/pre>\n
    <\/p>\n
    Entonces, nadie m\u00e1s podr\u00e1 desplegarse en el cl\u00faster de Kubernetes. Porque en todos los nodos se agotar\u00e1n los requests. Y de esta manera detendr\u00e9 su cl\u00faster de Kubernetes. Si hago esto por la noche, puedo detener los despliegues por un tiempo bastante largo. <\/p>\n
    <\/p>\n
    Si volvemos a consultar la documentaci\u00f3n de Kubernetes, veremos algo que se llama Limit Range. Establece los recursos para los objetos del cl\u00faster. Puede escribir un objeto Limit Range en yaml, aplicarlo a ciertos namespaces y, a partir de ah\u00ed, en ese namespace puede decir que tiene recursos predeterminados, m\u00e1ximos y m\u00ednimos para los pods.<\/p>\n
    <\/p>\n
    Con esta herramienta, podemos restringir a los usuarios en ciertos namespaces de producto de las capacidades de especificar en sus pods cualquier cosa no deseada. Pero, desafortunadamente, incluso si le dice al usuario que no puede lanzar pods con solicitudes superiores a un CPU, hay un comando maravilloso llamado scale, o a trav\u00e9s del dashboard pueden escalar.<\/p>\n
    <\/p>\n
    Y de aqu\u00ed surge la segunda forma. Lanzamos 11 111 111 111 111 pods. Eso son once mil millones. No es porque haya inventado ese n\u00famero, sino porque lo he visto. <\/p>\n
    <\/p>\n
    Una historia real. Tarde en la noche, ya estaba preparado para salir de la oficina. Mir\u00e9 y vi a un grupo de desarrolladores en una esquina haciendo algo apresuradamente con sus computadoras port\u00e1tiles. Me acerqu\u00e9 a ellos y pregunt\u00e9: \"\u00bfQu\u00e9 les sucedi\u00f3?\"<\/p>\n
    <\/p>\n
    Un poco antes, alrededor de las nueve de la noche, uno de los desarrolladores se estaba preparando para irse a casa. Y decidi\u00f3: \"Ahora escalar\u00e9 mi aplicaci\u00f3n a uno\". Presion\u00f3 uno, pero internet se ralentiz\u00f3 un poco. Volvi\u00f3 a presionar uno, presion\u00f3 con fuerza uno, hizo clic en Enter. Toc\u00f3 todo lo que pudo. En ese momento, internet revivi\u00f3 y todo comenz\u00f3 a escalar hasta ese n\u00famero. <\/p>\n
    <\/p>\n
    De hecho, esta historia no ocurri\u00f3 en Kubernetes, en ese momento era Nomad. Termin\u00f3 con que despu\u00e9s de una hora de intentos de detener a Nomad de sus tenaces intentos de escalar, Nomad respondi\u00f3 que no dejar\u00eda de escalar y no har\u00eda nada m\u00e1s. \"Estoy cansado, me voy\". Y se cerr\u00f3. <\/p>\n
    <\/p>\n
    Naturalmente, intent\u00e9 hacer lo mismo en Kubernetes. Once mil millones de pods no le agradaron, dijo: \"No puedo. Supera las limitaciones internas\". Pero 1 000 000 000 de pods fue capaz de manejar. <\/p>\n
    <\/p>\n
    En respuesta a un mill\u00f3n de Pods en s\u00ed mismo no se fue. Realmente comenz\u00f3 a escalar. Cuanto m\u00e1s avanzaba el proceso, m\u00e1s tiempo le llevaba crear nuevos Pods. Pero a\u00fan as\u00ed, el proceso segu\u00eda adelante. El \u00fanico problema es que si puedo lanzar Pods sin limitaciones en mi espacio de nombres, incluso sin solicitudes y l\u00edmites, puedo lanzar una cantidad de Pods con ciertas tareas que har\u00e1 que los nodos comiencen a colapsar en memoria y CPU. Cuando inicio tantos Pods, la informaci\u00f3n de ellos debe llegar al almacenamiento, es decir, etcd. Y cuando llega demasiada informaci\u00f3n all\u00ed, el almacenamiento comienza a dar resultados muy lentamente, y Kubernetes empieza a tener problemas. <\/p>\n
    <\/p>\n
    Y otro problema... Como saben, los componentes de gesti\u00f3n de Kubernetes no son una sola cosa central, sino varios componentes. En particular, hay un controlador de gesti\u00f3n, un programador, etc\u00e9tera. Todos estos chicos comenzar\u00e1n a realizar simult\u00e1neamente trabajos in\u00fatiles y sin sentido que con el tiempo ocupar\u00e1n cada vez m\u00e1s y m\u00e1s tiempo. El controlador de gesti\u00f3n crear\u00e1 nuevos Pods. El programador intentar\u00e1 encontrarles un nuevo nodo. Es probable que pronto se acaben los nuevos nodos en tu cl\u00faster. El cl\u00faster de Kubernetes comenzar\u00e1 a funcionar cada vez m\u00e1s lento.<\/p>\n
    <\/p>\n
    Pero decid\u00ed ir un paso m\u00e1s all\u00e1. Como saben, en Kubernetes hay algo que se llama servicio. Bueno, en sus cl\u00fasteres, por defecto, el servicio probablemente funciona mediante IP tables. <\/p>\n
    <\/p>\n
    Si lanzas miles de millones de Pods, por ejemplo, y luego con un peque\u00f1o script haces que Kubernetes cree nuevos servicios: <\/p>\n
    <\/p>\n
    for i in {1..1111111}; do\n    kubectl expose deployment test --port 80  \n        --overrides=\"{\"apiVersion\": \"v1\", \n           \"metadata\": {\"name\": \"nginx$i\"}}\"; \ndone <\/code><\/pre>\n
    <\/p>\n
    En todos los nodos del cl\u00faster, aproximadamente al mismo tiempo, se generar\u00e1n continuamente m\u00e1s y m\u00e1s reglas de iptables. Y se generar\u00e1n mil millones de reglas de iptables por cada servicio. <\/p>\n
    <\/p>\n
    Verifiqu\u00e9 todo esto con varios miles, hasta decenas. Y el problema es que ya en ese umbral, hacer un ssh en el nodo se vuelve bastante problem\u00e1tico. Porque los paquetes, al pasar por tal cantidad de cadenas, comienzan a no sentirse muy bien. <\/p>\n
    <\/p>\n
    Y esto tambi\u00e9n se resuelve con Kubernetes. Hay un objeto llamado Resource quota. Establece la cantidad de recursos y objetos disponibles para el namespace en el cl\u00faster. Podemos crear un objeto yaml en cada namespace del cl\u00faster de Kubernetes. Con este objeto, podemos decir que hemos asignado una cierta cantidad de requests y limits para este namespace, y luego podemos indicar que en este namespace se pueden crear 10 servicios y 10 pods. Y el desarrollador podr\u00eda intentar asustarse por las noches. Kubernetes le dir\u00e1: \"No se puede escalar tus pods a esa cantidad, porque excede la cuota de recursos\". Listo, problema resuelto. Documentaci\u00f3n aqu\u00ed<\/a><\/noindex>.<\/p>\n
    <\/p>\n
    Surge un problema relacionado con esto. Sientes lo dif\u00edcil que se vuelve crear un namespace en Kubernetes. Para crearlo, necesitamos tomar en cuenta un mont\u00f3n de cosas.<\/p>\n
    <\/p>\n
    Resource quota + Limit Range + RBAC
    \n\u2022 Creamos el namespace
    \n\u2022 Creamos dentro el limitrange
    \n\u2022 Creamos dentro el resourcequota
    \n\u2022 Creamos un serviceaccount para CI
    \n\u2022 Creamos un rolebinding para CI y usuarios
    \n\u2022 Opcionalmente, lanzamos los pods de servicio necesarios <\/p>\n
    <\/p>\n
    Por lo tanto, aprovechando la ocasi\u00f3n, me gustar\u00eda compartir mis desarrollos. Hay una herramienta llamada operador SDK. Es una manera de escribir operadores para el cl\u00faster de Kubernetes. Puedes escribir operadores usando Ansible.<\/p>\n
    <\/p>\n
    Primero escribimos usando Ansible, y luego vi que existe el operador SDK y reescrib\u00ed el rol de Ansible como un operador. Este operador permite crear dentro del cl\u00faster de Kubernetes un objeto llamado comando. Dentro del comando, permite describir en yaml el entorno para este comando. Y dentro del entorno del comando permite describir cu\u00e1ntos recursos estamos asignando. <\/p>\n
    <\/p>\n
    Peque\u00f1a facilitaci\u00f3n de todo este complicado proceso<\/a><\/noindex>. <\/p>\n
    <\/p>\n
    Y en conclusi\u00f3n. \u00bfQu\u00e9 hacer con todo esto?
    \nPrimero. Pod Security Policy \u2014 esto es bueno. Y a pesar de que ninguno de los instaladores de Kubernetes los utiliza hasta ahora, a\u00fan as\u00ed deber\u00edas usarlos en tus cl\u00fasteres. <\/p>\n
    <\/p>\n
    Network Policy \u2014 no es otra caracter\u00edstica innecesaria. Es algo realmente necesario en el cl\u00faster. <\/p>\n
    <\/p>\n
    LimitRange\/ResourceQuota \u2014 ya es hora de usarlos. Hace tiempo que comenzamos a utilizarlos y estaba seguro de que todos los aplicaban. Result\u00f3 ser bastante raro. <\/p>\n
    <\/p>\n
    Adem\u00e1s de lo que mencion\u00e9 durante la presentaci\u00f3n, hay caracter\u00edsticas no documentadas que permiten atacar el cl\u00faster. Sali\u00f3 recientemente un gran an\u00e1lisis de vulnerabilidades de Kubernetes<\/a><\/noindex>. <\/p>\n
    <\/p>\n
    Algunas cosas son tan tristes y dolorosas. Como, por ejemplo, en ciertas condiciones, los kubelets en el cl\u00faster de Kubernetes pueden entregar el contenido del directorio de warlocks a un usuario no autorizado. <\/p>\n
    <\/p>\n
    Aqu\u00ed<\/a><\/noindex> hay instrucciones sobre c\u00f3mo reproducir todo lo que cont\u00e9. All\u00ed est\u00e1n los archivos con ejemplos de producci\u00f3n, como se ven ResourceQuota y Pod Security Policy. Y todo esto se puede tocar. <\/p>\n
    <\/p>\n
    Gracias a todos.<\/p>\n
    Fuente: habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"
    \u041f\u0430\u0432\u0435\u043b \u0421\u0435\u043b\u0438\u0432\u0430\u043d\u043e\u0432, \u0430\u0440\u0445\u0438\u0442\u0435\u043a\u0442\u043e\u0440 \u0440\u0435\u0448\u0435\u043d\u0438\u0439 Southbridge \u0438 \u043f\u0440\u0435\u043f\u043e\u0434\u0430\u0432\u0430\u0442\u0435\u043b\u044c \u0421\u043b\u0451\u0440\u043c\u0430, \u0432\u044b\u0441\u0442\u0443\u043f\u0438\u043b \u0441 \u0434\u043e\u043a\u043b\u0430\u0434\u043e\u043c \u043d\u0430 DevOpsConf 2019. \u042d\u0442\u043e\u0442 \u0434\u043e\u043a\u043b\u0430\u0434 \u2014 \u0447\u0430\u0441\u0442\u044c \u043e\u0434\u043d\u043e\u0439 \u0438\u0437 \u0442\u0435\u043c \u0443\u0433\u043b\u0443\u0431\u043b\u0435\u043d\u043d\u043e\u0433\u043e \u043a\u0443\u0440\u0441\u0430 \u043f\u043e Kubernetes \u00ab\u0421\u043b\u0451\u0440\u043c \u041c\u0435\u0433\u0430\u00bb. \u0421\u043b\u0451\u0440\u043c \u0411\u0430\u0437\u043e\u0432\u044b\u0439: \u0432\u0432\u0435\u0434\u0435\u043d\u0438\u0435 \u0432 Kubernetes \u043f\u0440\u043e\u0445\u043e\u0434\u0438\u0442 \u0432 \u041c\u043e\u0441\u043a\u0432\u0435 18-20 \u043d\u043e\u044f\u0431\u0440\u044f. \u0421\u043b\u0451\u0440\u043c \u041c\u0435\u0433\u0430: \u0437\u0430\u0433\u043b\u044f\u0434\u044b\u0432\u0430\u0435\u043c \u043f\u043e\u0434 \u043a\u0430\u043f\u043e\u0442 Kubernetes \u2014 \u041c\u043e\u0441\u043a\u0432\u0430, 22-24 \u043d\u043e\u044f\u0431\u0440\u044f. \u0421\u043b\u0451\u0440\u043c \u041e\u043d\u043b\u0430\u0439\u043d: \u043e\u0431\u0430 \u043a\u0443\u0440\u0441\u0430 \u043f\u043e Kubernetes \u0434\u043e\u0441\u0442\u0443\u043f\u0435\u043d \u0432\u0441\u0435\u0433\u0434\u0430. […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":29423,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-39203","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\n","aioseo_head_json":{"title":"\ud83e\udd47Tapamos los agujeros en el cl\u00faster de Kubernetes. Charla y transcripci\u00f3n de DevOpsConf | ProHoster","description":"Pavel Selivanov, arquitecto de soluciones en Southbridge y profesor en Slyerma, present\u00f3 una charla en DevOpsConf 2019.","canonical_url":"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/zadelyvaem-dyry-v-klastere-kubernetes-doklad-i-rasshifrovka-s-devopsconf","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"es_ES","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u0417\u0430\u0434\u0435\u043b\u044b\u0432\u0430\u0435\u043c \u0434\u044b\u0440\u044b \u0432 \u043a\u043b\u0430\u0441\u0442\u0435\u0440\u0435 Kubernetes. \u0414\u043e\u043a\u043b\u0430\u0434 \u0438 \u0440\u0430\u0441\u0448\u0438\u0444\u0440\u043e\u0432\u043a\u0430 \u0441 DevOpsConf | ProHoster","og:description":"\u041f\u0430\u0432\u0435\u043b \u0421\u0435\u043b\u0438\u0432\u0430\u043d\u043e\u0432, \u0430\u0440\u0445\u0438\u0442\u0435\u043a\u0442\u043e\u0440 \u0440\u0435\u0448\u0435\u043d\u0438\u0439 Southbridge \u0438 \u043f\u0440\u0435\u043f\u043e\u0434\u0430\u0432\u0430\u0442\u0435\u043b\u044c \u0421\u043b\u0451\u0440\u043c\u0430, \u0432\u044b\u0441\u0442\u0443\u043f\u0438\u043b \u0441 \u0434\u043e\u043a\u043b\u0430\u0434\u043e\u043c \u043d\u0430 DevOpsConf 2019.","og:url":"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/zadelyvaem-dyry-v-klastere-kubernetes-doklad-i-rasshifrovka-s-devopsconf","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2019-10-31T19:28:25+00:00","article:modified_time":"2019-10-31T19:28:25+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"39203","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":"2026-01-24 01:15:20","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-03-01 00:54:43","updated":"2026-01-24 01:15:20","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/posts\/39203","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/comments?post=39203"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/posts\/39203\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/media\/29423"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/media?parent=39203"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/categories?post=39203"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/tags?post=39203"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}