Los contenedores de hoy no sorprenderán a nadie. Te sorprenderá la pregunta sobre la seguridad de los contenedores. Es especialmente interesante preguntar a los colegas que usan contenedores y microservicios en la producción con toda seriedad acerca de esto: a menudo veo caras de sorpresa y una pregunta perpleja, dicen: "¿Qué, por qué es esto?" Resulta que ya sabemos sobre tecnología (y cómo no podemos saberlo: parece que incluso los niños en edad escolar pronto podrán construir el cluster Kubernetes en su conjunto en lecciones de tecnología), pero aún no han aprendido cómo proteger sus componentes. Quizás simplemente no había nadie a quien enseñar.
En este artículo y en
DevOops , tendremos oradores que se comieron un perro sobre el tema de las soluciones de seguridad amigables con los contenedores. Acudimos a ellos para obtener respuestas a las preguntas de seguridad en la nube más simples. ¿Es necesario comenzar la autoeducación con algo?
Los participantes:
Seth Vargo dirige el Developer Advocate en Google. Anteriormente trabajó en HashiCorp, Chef Software, CustomInk y varias otras startups en Pittsburgh. Es autor de Learning Chef y aboga por reducir las desigualdades tecnológicas.
Liz Rice es evangelista técnica en Aqua Security, una solución empresarial de seguridad y contenedores de implementación de aplicaciones basada en la nube. Liz es una persona muy famosa en la comunidad, el presidente de Kubeon-s .
Oleg Chirukhin, editores del grupo JUG.ru
Comencemos con una pregunta que determinará nuestra discusión adicional. ¿Qué significa DevOps para ti? ¿En qué se diferencia del SRE menos conocido?
Por ejemplo, en un trabajo anterior, cuando me pidieron "implementar DevOps", simplemente caminé por la tabla de contenido del Libro SRE , agarré ideas y las apliqué una por una. Bueno, o al menos intenté transmitirlos a otros. ¿Qué dices? ¿Es este el enfoque correcto?
Si hablamos de DevOps, estamos hablando de evitar el abismo, de la brecha que generalmente existía entre los procesos de desarrollo de código (Dev) y su posterior mantenimiento (Ops). Imagine que tenemos un muro alto, en un lado del cual se sientan los desarrolladores, él crea un código y lo arroja sobre el muro. En el otro lado del muro hay personas comprometidas con el apoyo. Capturan la aplicación transferida y comienzan a iniciarse y mantenerse. Y estas personas conocen los detalles necesarios durante la operación. Por ejemplo, qué puertos y dónde se asignarán y abrirán.
En lugar de tener dos grupos separados de personas con intereses diferentes, quiero hacer que se comuniquen entre sí, decidir qué hacer a continuación, juntos determinar qué objetivos tratarán de lograr juntos durante la jornada laboral. De modo que DevOps es un cambio en la cultura de la comunicación que ayuda a los colegas de diferentes equipos técnicos a trabajar por el bien común: crear valor para el negocio, implementar software y mantenerlo funcionando. Creo que estos son cambios muy importantes, y traen consigo nuevas herramientas relacionadas: si no tienes una cultura de comunicación, entonces no tiene mucho sentido introducir los mismos procesos de CI / CD.
A menudo hay confusión con los conceptos de DevOps y SRE. Algunas personas piensan que SRE compite con DevOps, otras consideran que son conceptos completamente diferentes y superpuestos. En mi opinión, no son competidores, sino amigos cercanos. Piense en los enfoques que subyacen a DevOps: reducir los costos organizacionales, tratar las fallas como una parte normal del flujo de trabajo, introducir cambios gradualmente, automatizar e implementar las herramientas necesarias para esto y usar métricas para evaluar los procesos. Como puede ver, todo esto es muy abstracto: DevOps no nos dice cómo reducir los costos organizacionales o introducir cambios graduales, solo le dice que sería bueno si se implementaran.
Ahora echemos un vistazo a SRE. Aunque el enfoque SRE ha evolucionado independientemente del enfoque DevOps, SRE es, podría decirse, una implementación de los principios de DevOps: si imagina DevOps como una clase o interfaz abstracta en programación, SRE será una clase concreta que implementará esta interfaz. SRE tiene enfoques claramente definidos para una serie de cosas y conceptos: copropiedad, compartir riesgos, autopsia, recopilación y acumulación de valores métricos y mucho más. Por lo tanto, es más conveniente para las organizaciones hablar sobre la adopción de SRE debido a la presencia de procesos y entidades muy comprensibles.
¿Crees que el término "ingeniero DevOps" es correcto? ¿Se puede reemplazar de alguna manera?
Personalmente, no creo que exista el concepto de "ingeniero de DevOps". Puede leer con más detalle en mi artículo "10 mitos de DevOps" que "DevOps" es en realidad una ideología: más comunicación y cooperación entre unidades organizativas diferentes, pero esencialmente conectadas. Aunque hoy parece bastante robusto y familiar, al principio tal enfoque suscitó elogios y críticas severas. Desde entonces, muchas organizaciones, incluidas Etsy, Facebook y Flick, han implementado sorprendentemente con éxito los principios de DevOps.
Entonces, ninguna de estas organizaciones contrató a "ingenieros de DevOps". El éxito de la implementación se puede atribuir a la cooperación interna emergente de los equipos y la voluntad de cambiar sus procesos y procedimientos existentes para lograr un objetivo común. El papel del llamado "ingeniero DevOps" era alentar la colaboración entre grupos y garantizar que las unidades organizativas intercambien ideas y objetivos con regularidad. En realidad, ya tenemos a estas personas hoy, y las llamamos "gerentes".
Agregaré un momento más. Cuando designamos a alguien para un puesto o rol específico, comenzamos a esperar cosas y acciones bastante específicas de él, por lo que es importante elegir un puesto de trabajo. Pero los nombres exactos de las publicaciones pueden diferir debido a las realidades y tradiciones locales adoptadas por la organización, por lo que es importante no el nombre como tal, sino el equilibrio entre las publicaciones de todas las personas que trabajan en la empresa.
No hace mucho, hablé con una persona que trabajaba en una organización bastante grande, por lo que crearon un equipo de varios empleados y lo llamaron, digamos, un equipo de infraestructura. Luego, se cambió el nombre de este equipo a otro, y después de un tiempo se creó otro equipo, y ahora se llamaba el equipo de infraestructura; como resultado, todos estaban confundidos: quiénes son la "infraestructura" y cuál es su función.
En mi opinión, lo más importante no es la existencia de un equipo o puesto con un nombre específico, sino la presencia dentro de la organización de una comprensión clara de quién es responsable de qué. No importa si los llaman SRE o DevOps: lo principal es entender qué significa un nombre específico para esta organización en particular.
Liz, estás consultando, ¿cómo explicas los principios de DevOps a las empresas clientes? Suenan bastante abstractos y algo difíciles de explicar. ¿O tal vez ha desarrollado algún tipo de enfoque que le permita transmitir estas ideas a los clientes?
Depende del propósito. Muchas personas y empresas con las que me comunico como parte de las consultas acuden a nosotros y nos dicen que quieren implementar Kubernetes y contenedores. Pero antes de hablar sobre tecnología, debe comprender por qué están tratando de dar esos pasos. Y resulta que los beneficios esperados del cambio a menudo se reducen al deseo de ser más flexibles. De ahí el movimiento en la dirección en que los equipos técnicos podrían publicar los resultados de su trabajo más rápido, algo así, explicado "en los dedos". En este punto, es útil cambiar la conversación al lado de que el problema de la falta de cultura (hábitos, si lo desea) de comunicación entre los miembros del equipo no será ayudado por ningún "lanzamiento" de nuevas tecnologías, esa comunicación es un recurso importante.
Además, dado que a menudo me encuentro involucrado en mejorar la seguridad de las soluciones, nuestra conversación cambia hacia "Dev - ** Sec ** - Ops", y resulta que la construcción del sistema debe llevarse a cabo de tal manera que En las primeras etapas de los procesos, y no solo abordamos la cuestión a la antigua usanza: primero escribimos el código de la aplicación, luego lo implementamos, luego lo transferimos al servicio de operación, y solo al final alguien comienza a pensar en la seguridad de la ejecución.
De hecho, muchos problemas de seguridad son más baratos y fáciles de resolver al comienzo del proceso, pero debe establecer muchos puntos en el proyecto desde el principio. Por ejemplo, si tiene la intención de trabajar con contenedores, debe preocuparse de que las imágenes se recopilen de manera bastante segura. Puede ser útil escanearlos en busca de vulnerabilidades para evitar al menos la implementación de software con problemas de seguridad ya conocidos. Quizás intente configurar los contenedores para que el software en ellos no se inicie de forma predeterminada por la raíz (a menudo por simplicidad, sin necesidad especial, se realizan al ensamblar los contenedores). Si sigue estos pasos, al final recibirá un aumento en la seguridad de su aplicación y, en el contexto de todo este DevOps, puede hablar sobre la cultura SecOps.
Sin embargo, esto significa que los desarrolladores, de hecho no siendo expertos en seguridad de aplicaciones, se ven obligados a pensar no solo en el código de la aplicación, sino también en crear sus propios sistemas de seguridad. ¿Cuál debería ser, en su opinión, el conjunto mínimo de habilidades para un desarrollador de software moderno o un ingeniero operativo?
Usted y yo, nos guste o no, vemos constantemente la aparición de nuevas reglas y requisitos que en algún momento resulta necesario cumplir y cumplir: tomemos el mismo GDPR como ejemplo. La aparición y existencia de estas regulaciones significa que un número creciente de personas debe tener una sensación de seguridad. Por ejemplo, hoy ya no puede almacenar nombres de usuario y contraseñas en texto sin formato en los campos de la base de datos; esto ya no se considera al menos tolerable. Yo diría que en la industria ya hay requisitos para "higiene" bastante claros para todos.
Los fabricantes de herramientas e infraestructuras tienen un impacto significativo en este proceso, al tratar de diseñar y cambiar los sistemas para que los usuarios puedan crear aplicaciones y sistemas más seguros desde el principio. Por ejemplo, en Kubernetes durante el año pasado, muchas de las configuraciones predeterminadas y los valores de los parámetros han cambiado hacia una mayor seguridad, y esto es realmente genial. Anteriormente, de manera predeterminada, el servidor API estaba abierto para acceso anónimo; esto no es exactamente lo que espera ver "listo para usar". Ahora han aparecido cosas como el control de acceso basado en roles, por lo que ahora tenemos permisos (sí, "listos para usar"), y cuando inicia Kubernetes por primera vez, no está abierto a todo el mundo, está protegido de forma predeterminada. Creo que esta es una buena manera de hacer que la seguridad esté disponible para todos en el transcurso de procesos familiares, porque no tenemos que cambiar constantemente los valores predeterminados a valores seguros (que, además, debían tenerse en cuenta).
Personalmente, creo que todo ingeniero de software debe tener al menos una comprensión básica de la seguridad. Cosas como los enfoques de OWASP (Open Web Application Security Project) vienen al rescate, pero en última instancia, los ingenieros deben ser autodidactas. Es poco probable que todos los ingenieros tengan un doctorado en criptografía, pero si queremos que nuestros colegas tomen en serio la seguridad, deberíamos facilitarles la toma de decisiones correctas. Aquí es donde herramientas como Vault pueden ayudar, y los equipos y profesionales de seguridad pueden tomar decisiones y proporcionar "seguridad como API".
Si entiendo correctamente, hay una tendencia a convertir todo en código. Todo como código. Infraestructura como código, procesos como código, código como código. ¿Cuáles son las implicaciones?
Antes de hablar sobre las consecuencias, necesitamos hablar sobre los beneficios. El código ha existido por mucho tiempo. Las aplicaciones siempre han sido "código", y durante este tiempo se ha creado un extenso ecosistema de herramientas y procesos para apoyar y mejorar el proceso de desarrollo de aplicaciones (CI / CD, linting, herramientas para el desarrollo conjunto, etc.). Habiendo descrito la infraestructura como código, los procesos como código, la seguridad como código, podemos usar el mismo ecosistema, sin pagar nada adicional por esto. Puede desarrollar conjuntamente cambios de infraestructura, hacer revisiones de políticas, etc. Puede probar los cambios de infraestructura antes de implementarlos. Estos son solo algunos de los beneficios que vienen con la traducción de algo en código.
Creo que las mayores consecuencias son el tiempo y la complejidad. Cuando trabajas con algo "como el código" (por ejemplo, a través de Terraform, Vault, CloudFormation, Deployment Manager, etc.), a veces tienes que encontrar discrepancias entre lo que está escrito en el código y lo que realmente sucede. en la nube Modelar relaciones complejas a veces es difícil de hacer visualmente, especialmente teniendo en cuenta la escala. Además, podemos encontrar imprecisiones de abstracciones; por ejemplo, un script que funciona a través de la API puede no percibir el estado actual de las cosas tal como se muestra a los usuarios a través de la interfaz web. Sin embargo, con el tiempo, la complejidad disminuye y la flexibilidad vuelve.
El código y otros modelos formales son un campo adecuado para el análisis automático y el aprendizaje automático. ¿Cuándo exactamente nos reemplazarán los robots? ¿Cómo debemos responder?
¿Pueden los robots configurar Kubernetes sin humanos? En particular, puede suceder que algunas profesiones (como un administrador del sistema o un probador de software con un alto nivel de interactividad, una palabra socialmente aceptable para un "probador manual") simplemente desaparezcan.
No creo que las personas desaparezcan, pero sospecho que algunos de los trabajos que tenemos hoy no se salvarán en el futuro. Vivo en Pittsburgh, la capital mundial de los sistemas autónomos de control de automóviles, y veo autos autónomos literalmente todos los días. En el futuro, por supuesto, los taxistas serán reemplazados por tecnologías de conducción robótica. Quizás no de inmediato, pero después de 10 o más años, pero este futuro inevitablemente llegará. Sin embargo, creo que los taxistas no desaparecerán. La humanidad se reinventa constantemente.
Creo que lo mismo se puede decir sobre el aprendizaje automático en el campo de la gestión. Espero contar con más IA para que nuestros sistemas sean más estables y resistentes, y creo que podemos decidir luchar contra este enfoque, o aceptarlo. El rol de los administradores de sistemas tradicionales puede ser reemplazado por alguien que controla el sistema de inteligencia artificial, pero esto no significa que las personas desaparezcan. Experimentamos los mismos cambios en varias industrias donde la tecnología y la innovación proporcionaron mayor velocidad y precisión que las personas, pero al final, alguien necesita seguir a los robots :).
Imagine que un equipo de desarrollo regular crea una aplicación web y la coloca en un clúster de Kubernetes. ¿Cómo podemos asegurarnos de que la aplicación sea segura? Contrata a un hacker blackhat o especialista que esté tratando de encontrar debilidades de seguridad, ¿o hay formas menos complicadas?
Nosotros en Aqua Security lanzamos recientemente una herramienta de código abierto llamada kube-hunter . Es capaz de probar Kubernetes en busca de piratería o penetración, por lo que es una prueba bastante simple. Puede tomar esta herramienta y probar su propio clúster, y seguramente encontrará algo interesante para usted, especialmente si su instalación se basó en la versión anterior de Kubernetes, donde la configuración predeterminada era menos segura; es posible que, por ejemplo, Puertos abiertos.
Todos escuchamos historias sobre personas que "olvidaron" cerrar el panel de control de su clúster por el acceso libre a todo Internet, por lo que el objetivo de crear kube-hunter era verificar nuestro propio sistema y asegurarse de que esté protegido. En nuestra opinión, los piratas informáticos llevan mucho tiempo escaneando hosts en Internet en busca de recursos y puertos abiertos y conocidos, por lo que su panel de control de Kubernetes, que por casualidad no está protegido (y, por lo tanto, abierto a todos), puede no ser tan difícil de encontrar, especialmente con herramientas que Están acostumbrados a usar.
Queremos que hunter ayude a los administradores comunes de Kubernetes a comprender mejor si hay problemas de configuración en su implementación, por lo que está diseñado exclusivamente para Kubernetes e informa que se encontró en un idioma que los usuarios de Kubernetes entienden. Entonces le informaremos que no ha abierto ningún puerto 6443, pero, digamos, acceso a este componente particular de Kubernetes. De esta manera, es más fácil para las personas determinar si lo que encontraron es un problema con una configuración que debilita la seguridad y si vale la pena solucionarlo de inmediato, sin ser un experto en seguridad de Kubernetes. Queremos intentar que estos controles estén disponibles en cualquier momento, sin la necesidad de expertos externos.
Hay una observación: muchos ya no están interesados en lo que hay dentro de los contenedores que lanzan.
Sí, y no tienen idea de qué dependencias se integraron en estos contenedores. Sin embargo, si hace planes para utilizar el enfoque de contenedor para implementar el servicio, parece razonable averiguar qué tipo de software hay dentro de esta o aquella imagen. Pero este no es un problema del enfoque del contenedor en sí mismo, es solo una actitud hacia la seguridad por parte de quienes utilizan el enfoque.
No es tan difícil hacer todo de manera correcta y confiable. Digamos que, a medida que avanza en el mundo de la nube, debe comenzar a usar herramientas adicionales, que casi con seguridad agregarán niveles adicionales de seguridad.
Las nubes tienen sus propios detalles. Por ejemplo, a menudo encuentro la idea errónea de que en el mundo de la nube, una herramienta a la que la gente está acostumbrada en los viejos tiempos hará automáticamente todo lo que necesita. De alguna manera, tienen razón: supongamos que puede usar la lista habitual (y siempre funciona) de la configuración del firewall, y esto mejorará la seguridad, pero algunas de las herramientas antiguas ya no son adecuadas hoy en día. Por ejemplo, si implementa una imagen de contenedor y usa la herramienta familiar anterior para escanear vulnerabilidades, si el escáner no sabe cómo mirar dentro de la imagen, simplemente no encontrará nada y obtendrá (posiblemente falsa) confianza de que todo está en orden.
Realmente me gusta que cuando pasas a la arquitectura de microservicios, obtienes una cantidad bastante grande de pequeñas piezas de funciones dispuestas en contenedores (cuyo contenido está en la palma de tu mano) y puedes ver el tráfico entre ellos. Cada uno de los contenedores se puede percibir como una especie de caja negra, desde la cual se esperan acciones estrictamente definidas. Y tan pronto como este o aquel contenedor comience a comportarse de manera inesperada o produzca resultados extraños, será posible responder a esto. Cuanto mejor se ensamblen y configuren las imágenes específicas de los contenedores, más comprensible será si funcionan correctamente.
¿Y cómo atrapar anomalías? ¿Usa algo como heurística antivirus, redes neuronales?
A lo largo del ciclo de vida del software, utilizamos varias herramientas de seguridad. runtime enforcer — , , . «», , , nginx, , nginx . , , «» , . , , . : , , .
. Serverless , , . . « »? , ?
, severless , , , . serverless — . severless-, «», . , «- ». severless. serverless- . «» , ( «» ) .
serverless – « ». serverless- pub/sub, , Redis . , , - () .
severless- , . , , , serverless- . - . , , , . serverless, - .
, serverless- . , , . ?
, , — , , , DevOps. , , , , .
, , : YAML. , Kubernetes Kubernetes, YAML. , 30 000 YAML. , , , 30 000 YAML, , , .
, Kubernetes . , , ?
Kubernetes , . , , , , - , . , , YAML- , , Kubernetes . , . , .
, Kubernetes — , . . , Kubernetes CNCF graduated, , , , , CNCF .
, : YAML, , . , YAML Kubernetes.
, YAML, , , , YAML. , , , - YAML .
, Kubernetes, , ?
Buena pregunta , , , , . – Istio ( service mesh), 1.0. , , , «».
, - , .
, ?
C . , , , , !
! , : — .
DevOops 2018 «Modern security with microservices and the cloud» , «Practical steps for securing your container deployment» . .