La seguridad nativa de la nube estuvo en el aire en KubeCon/CloudNativeCon 2022

Como cinéfilo autoidentificado, algunas líneas de películas de alguna manera se quedan conmigo a lo largo de los años. Uno de ellos es de Ridley Scott. Gladiator (2000), cuando un senador romano dice: “El corazón palpitante de Roma no es el mármol del Senado, es la arena del Coliseo”.

Esa frase apareció en mi cabeza mientras caminaba por los pasillos de KubeCon/CloudNativeCon (“KubeCon”), el evento principal de la Fundación de computación nativa en la nube (CNCF). Para mí, el corazón de la seguridad nativa de la nube es definitivamente KubeCon.

La edición norteamericana del evento de este año tuvo lugar la semana pasada en Detroit y reunió a miles de participantes en el lugar y a muchos otros de forma remota. Además del evento principal de tres días, el creciente interés en proyectos específicos ha llevado a la Cloud Native Computing Foundation a organizar varios “eventos compartidos” antes de la conferencia principal.

Para el evento de 2022, no solo hubo un evento específico de dos días de CloudNativeSecurityCon, sino también una gran cantidad de contenido de seguridad en otros eventos, incluido el Día de redes de aplicaciones, EnvoyCon, Día de políticas con OPA, ServiceMeshCon y más, lo que refleja el amplio interés en la nube. Temas de seguridad nativos. Curiosamente, el evento CloudNativeSecurityCon ahora se ha "graduado" a un evento independiente que se realizará por separado en febrero.

Seguridad nativa de la nube: desarrollo frente a operaciones

Entonces, ¿dónde está el estado actual de las conversaciones sobre seguridad nativa de la nube? Para Omdia, existe una fuerte bifurcación: preocupaciones centradas en el desarrollo y preocupaciones centradas en las operaciones. No es tan útil llamarlos “Dev” y “Ops” porque la estructura del equipo está cambiando en muchas organizaciones: algunas pueden tener equipos de ingeniería de confiabilidad del sitio (SRE), otras pueden llamarlos operaciones, equipos de plataforma y más.

En el lado del desarrollo del libro mayor, tres temas de interés son la procedencia, el ruido y la exposición.

Provenance plantea la pregunta fundamental: ¿Podemos confiar en la integridad del componente externo que estamos incorporando a nuestra cartera de software? Si bien existen muchos ejemplos, el ataque a SolarWinds de 2020 fue un punto de inflexión en el interés por la integridad de la cadena de suministro de software. En KubeCon, hubo un impulso palpable detrás de la idea de firmar imágenes de software: tienda de firmas El proyecto se anunció como disponibilidad general y está siendo utilizado por Kubernetes y otros proyectos clave.

El ruido se refiere a reducir la cantidad de vulnerabilidades que existen en el entorno, comenzando por reducir las imágenes base del contenedor que se están utilizando. Esto puede incluir el uso de bases de imágenes como Alpine o Debian Slim o considerar alternativas "sin distribución" que sean incluso más pequeñas. El beneficio es que estas imágenes más pequeñas ocupan un espacio mínimo y, por lo tanto, reducen la posibilidad de que surjan vulnerabilidades.

Exposición: Para cualquier vulnerabilidad dada, ¿qué tan expuestos estamos como organización? Por supuesto, no hay mejor ejemplo de esto en la historia reciente de la industria que Log4j. Este es el ámbito de las discusiones sobre listas de materiales de software (SBOM), en lo que se refiere a saber dónde se pueden usar los componentes, ya sea como imágenes almacenadas en un registro en algún lugar o ejecutándose en producción. Curiosamente, mientras se escribe este ensayo, hay un aviso previo de que la información sobre vulnerabilidades críticas en OpenSSL 3.x se divulgará de manera inminente, lo que probablemente será otro buen caso de uso para los SBOM: ¿dónde se usa OpenSSL 3.x en nuestra organización? Dado que la cobertura de SBOM aún no está generalizada, Omdia espera un uso mínimo de SBOM esta vez, desafortunadamente.

Naturalmente, los equipos de operaciones se centran en proporcionar y operar una plataforma subyacente cada vez más compleja y hacerlo de forma segura. La palabra "plataforma" es particularmente relevante aquí: hubo un interés notable en organizar Kubernetes y muchos de la creciente lista de proyectos CNCF (140 al momento de escribir este artículo, entre las distintas etapas de incubación de proyectos: sandbox, incubación, graduado) en formas más fáciles. plataformas de consumo. De interés específico para las audiencias de seguridad, proyectos como Cilium (que utiliza la funcionalidad subyacente eBPF) para redes y observabilidad, SPIFFE/SPIRE (para establecer identidades), Falco (para seguridad en tiempo de ejecución), Open Policy Agent (para políticas como código) , Cloud Custodian (para gobernanza) y otros que vale la pena considerar. La expectativa es que estos proyectos colaboren cada vez más con aspectos de "observabilidad" de la nube nativa y también se implementarán utilizando prácticas como GitOps.

Razones para el optimismo sobre la seguridad nativa de la nube

¿A dónde vamos desde aquí? Quedó muy claro que la comunidad nativa de la nube se preocupa profundamente por la seguridad y está avanzando a toda velocidad para abordar los numerosos temas que la rodean. La orientación para los equipos de seguridad es ponerse al día rápidamente sobre cómo se están implementando estos diferentes proyectos e iniciativas. Es importante tener en cuenta que para muchas organizaciones, esto no se realizará mediante el uso explícito del proyecto comunitario (aunque algunas lo harán), sino más bien como parte de una plataforma empaquetada de proveedores como Red Hat, SUSE, Canonical y otros. o directamente desde los proveedores de la nube como AWS, Google Cloud, Azure, Oracle y otros.

Tenga en cuenta que, en el contexto del uso de código abierto, no existe nada realmente “gratuito”; incluso si uno elige utilizar la versión original de los proyectos, existen costos inherentes al mantenimiento de esos paquetes y a la participación en el desarrollo de la comunidad.