Cómo asegurar tus contenedores Node.js en Kubernetes con las mejores prácticas

Hola a todos. Bienvenidos a mi charla. Hoy hablaré sobre cómo asegurar tus contenedores de Kubernetes, especialmente para Node.js. Si eres un ingeniero de DevOps, es muy probable que estés manteniendo ya sea un clúster de Kubernetes local o una plataforma como EKS, AKS o GKE. Pero independientemente de cómo ejecutes tus clústeres de Kubernetes, debes asegurarte de que estén seguros.

Pero primero, las presentaciones. Mi nombre es Deepu K. Sashidharan. Soy el co-líder de jHipster. También creé un panel muy útil llamado kdash para Kubernetes. Soy un aficionado del código abierto, un desarrollador políglota y un campeón de Java. Trabajo como defensor del desarrollo en Okta, con un enfoque en DevOps. También escribo con frecuencia sobre lenguajes y tecnología en mi blog. Puedes encontrarlo en deepu.tech. Por favor, sígueme en Twitter si te interesa mi contenido. He escrito un libro sobre jHipster. Si te gusta esta charla, es posible que también te guste el libro. Así que por favor, échale un vistazo.

Antes de hablar sobre cómo asegurar Kubernetes o antes de hablar sobre las mejores prácticas de seguridad en Kubernetes, es importante tener una comprensión básica de la seguridad de Kubernetes. Al igual que cualquier otro software complejo, la seguridad en Kubernetes es multifacética. Se puede categorizar en cuatro capas: seguridad del transporte, autenticación, autorización y control de admisión.

Se utiliza TLS para garantizar la seguridad del transporte y se puede realizar la autenticación y autorización utilizando múltiples mecanismos en Kubernetes. También es posible agregar módulos de control de admisión personalizados para agregar políticas y seguridad adicionales en Kubernetes. Estas son las cosas que están disponibles de forma predeterminada en Kubernetes.

Kubernetes viene con muchas opciones de seguridad predefinidas, como hemos visto. Pero para proteger al máximo tu infraestructura, debes considerar muchas más mejores prácticas de seguridad. Hoy veremos algunas de las mejores prácticas de seguridad vitales. También puedes encontrar un blog similar en el enlace proporcionado en esta diapositiva. Así que por favor, échale un vistazo si quieres leer un poco más de información al respecto.

Entonces, primero, la primera mejor práctica sería usar RBAC. Kubernetes admite múltiples modelos de autorización para su servidor API. Existe el control de acceso basado en atributos, o ABAC, el control de acceso basado en roles, o RBAC, la autorización de nodos y el modo de webhook. De todos estos, RBAC es el más seguro y el más utilizado, y es ideal para empresas y organizaciones medianas y grandes.

Con RBAC puedes definir un control de acceso basado en roles que se asemeja estrechamente a los roles empresariales de tu organización. RBAC también funciona muy bien con la autenticación OIDC. Entonces, con RBAC, puedes tener un control mucho más flexible sobre quién tiene acceso a qué, y puedes modelarlo según cómo está estructurada tu organización, según tus departamentos y todas estas cosas. La mayoría de las distribuciones de Kubernetes tienen RBAC habilitado de forma predeterminada. Puedes verificar esto ejecutando el comando kubectl clusterinfo down, luego busca la bandera de modo de autorización en la salida, que mostrará algo como modo de autorización igual a RBAC. Si no es así, puedes habilitarlo usando la bandera de modo de autorización para el servidor API. Sería hyphen-authorization mode. Puedes hacer esto al crear un clúster o puedes hacerlo parchando un clúster. Por ejemplo, si estableces hyphen-authorization-mode igual a RBAC, command-node, habilitará tanto RBAC como la autorización de nodos en el clúster. También puedes tener múltiples autorizaciones en el mismo clúster. Una vez que se habilita RBAC, puedes crear roles de clúster y asignaciones de roles y asignaciones de roles de clúster para controlar el acceso a tus recursos. Aquí tienes un pequeño ejemplo de un rol y una asignación de roles que permite a los usuarios ver puertos y servicios. Te recomendaría que consultes la documentación de Kubernetes sobre RBAC y roles de clúster y asignaciones de roles para aprender más a fondo, ya que verás muchas más explicaciones, muchos más ejemplos sobre cómo puedes usar esto de manera flexible para gestionar requisitos de autorización complejos.

La siguiente mejor práctica sería usar OpenID Connect o OIDC para asegurar tu clúster. Esto es para la parte de autenticación. RBAC fue para la parte de autorización y OIDC sería para la parte de autenticación. Kubernetes admite múltiples mecanismos de autenticación. Algunos de los más comunes son certificados de cliente, tokens de autenticación básicos que incluyen tokens de cuenta de servicio, tokens de portador, etc. OpenID Connect o OIDC y también autenticación basada en proxy. Estos son todos los mecanismos de autenticación que son compatibles con Kubernetes de forma predeterminada.

De todos estos mecanismos de autenticación, OIDC es la solución más segura y escalable. Es ideal para clústeres a los que acceden equipos grandes, ya que proporciona una solución de inicio de sesión único para todos los usuarios y facilita la incorporación y desincorporación de usuarios, porque una vez que aseguras tu clúster usando OIDC, no tendrías que ingresar a los clústeres de Kubernetes para realizar ninguna administración de usuarios. Puedes hacer todo desde tu proveedor de OpenID Connect. Puedes hacer la incorporación de usuarios, desincorporación, todo desde allí. No tienes que asegurarte de no tener que preocuparte por tener que borrar nombres de usuario, contraseñas o tokens y certificados de las máquinas de los usuarios, etc. Todo será atendido por el proveedor de OIDC, el mecanismo de OIDC. Por lo tanto, también es mucho más seguro que otros mecanismos, ya que no tienes que almacenar ninguna información sensible en la computadora de un usuario, como secretos de cliente o contraseñas, con los mecanismos tradicionales que tendrías que hacer. También puedes usar características como autenticación multifactor, tokens, llaves Yubi, etc., según lo admita tu proveedor de OIDC, por supuesto, pero todos estos mecanismos estarían disponibles para acceder a tu clúster de Kubernetes. Eso significa que puedes agregar capas adicionales de seguridad que no son posibles con ningún otro mecanismo de autenticación admitido por Kubernetes. También puedes consultar esta publicación de blog que escribí sobre cómo asegurar tus clústeres con OIDC para obtener más detalles y ver cómo puedes hacer esto para tu clúster. El blog muestra cómo configurar esto usando Okta, pero los pasos son similares para cualquier proveedor de OIDC. Por lo tanto, puedes cambiar fácilmente de Okta a Key Clock o cualquier proveedor de OIDC que prefieras. Así que consulta este blog para ver cómo puedes hacer esto.

Así es como funciona OIDC con Kubernetes. Cuando ejecutas un comando con kubectl, utiliza kubelogin y abre un navegador para autenticarte con el proveedor de OIDC. Luego utiliza la respuesta de autenticación obtenida del proveedor de OIDC para obtener tokens del servidor de autenticación y pasa los tokens al servidor de API de Kubernetes, que se utilizarán para autenticar al usuario. Por lo tanto, la siguiente mejor práctica sería usar secrets. Por supuesto, esta debería ser una opción obvia. Kubernetes tiene un recurso de secret que se puede utilizar para almacenar datos sensibles. Esta es una excelente manera de almacenar contraseñas, claves y otros datos sensibles. Los secrets se pueden usar para almacenar datos de cadena, configuración de Docker, certificados, tokens, archivos, etc. Los secrets se pueden montar como volúmenes de datos o exponer como variables de entorno para ser utilizados en los contenedores. Los secrets pueden ser texto plano o codificados.

Así que por favor, no seas esa persona que utiliza texto sin formato para secretos sensibles. Los secretos son flexibles y nativos de Kubernetes. Por lo tanto, no hay razón para no utilizarlos. Además, asegúrate de implementar RBAC adecuado para los secretos también, para que no todos en tu organización tengan acceso a los secretos. Porque no creo que tengas que exponer secretos a todos los que tienen acceso al clúster.

Lo siguiente sería mantener Kubernetes actualizado. Al igual que cualquier otro software, Kubernetes también tiene errores y problemas y CVEs. Y de vez en cuando, puede haber un error de alta gravedad que requiera un CVE. Como, por ejemplo, problemas relacionados con la seguridad de la memoria. Por lo tanto, es una excelente idea mantener actualizada la versión de Kubernetes tanto para el servidor como para el cliente CLI. Puedes consultar el sitio web de información de seguridad y divulgación de Kubernetes para ver si hay errores de seguridad conocidos para tu versión de Kubernetes. Si estás utilizando un clúster administrado, debería ser bastante fácil de actualizar. Y para instalaciones locales, hay herramientas como Kops, Kubadmin, y demás. Estas herramientas facilitan la actualización de tus clústeres locales.

Lo siguiente sería restringir el acceso de administrador. Kubelet es el agente primario del nodo que se ejecuta en cada nodo. Y por defecto, los puntos finales HTTP de Kubelet no son seguros. Esto podría permitir un acceso no deseado y, por lo tanto, debería restringirse. Además, cuando alguien tiene acceso a un clúster de Kubernetes, puede acceder al servidor de API de Kubernetes y también puede hacer SSH en los nodos del clúster. Esto tampoco es muy seguro. Para limitar el acceso a los nodos, el acceso al clúster debe limitarse tanto como sea posible. Desactiva el acceso SSH para usuarios no administradores. Asegura tu servidor de API utilizando OIDC y RBAC, como vimos anteriormente, para que solo los usuarios autenticados con roles suficientes puedan acceder a la API.

Lo siguiente sería controlar el tráfico entre pods y clústeres. Por lo general, los pods dentro del mismo clúster podrán comunicarse entre sí. Y si tienes varios clústeres en la misma red, también puede haber tráfico entre estos clústeres. Por lo tanto, no dejes todo esto abierto, ya que aumentaría la superficie de ataque. Y podría llevar a un clúster comprometido cuando otro en la red se vea afectado. Utiliza políticas de red de Kubernetes para controlar el tráfico entre pods y clústeres y permite solo el tráfico mínimo necesario, para que incluso si se compromete un clúster o un contenedor, no termines comprometiendo todo el clúster o tu red. Lo siguiente sería, esto también es un poco similar, así que lo siguiente sería aislar las cargas de trabajo por espacio de nombres.

Así que no ejecutes todas tus cargas de trabajo en un solo espacio de nombres. Aislar las cargas de trabajo en diferentes espacios de nombres según las necesidades comerciales es más seguro y también es más fácil de administrar con RBAC. De esta manera, puedes ajustar aún más RBAC para permitir que los usuarios accedan solo a lo que necesitan ver. También puedes usar políticas de red de Kubernetes para aislar el tráfico entre espacios de nombres si corresponde y si es necesario. Aislar tus cargas de trabajo con diferentes espacios de nombres siempre es una buena idea.

Al asegurar las API y el propio clúster, también es esencial establecer límites de recursos en cuanto a cuánta CPU, memoria y espacio de disco persistente se utiliza en los espacios de nombres y recursos. Esto protege tu clúster de ataques de denegación de servicio. Cuando un contenedor en particular utiliza todos los recursos, podría afectar y comprometer todo tu clúster. Por lo tanto, para evitar eso, utiliza cuotas de recursos y rangos de límites para establecer límites a nivel de espacio de nombres. Y también puedes usar solicitudes y límites a nivel de contenedor para establecer algunos límites también.

Finalmente, también es extremadamente importante monitorear y auditar tus clústeres. Habilita el registro de auditoría para el clúster y utiliza herramientas de monitoreo para vigilar el tráfico de red hacia, desde y dentro del clúster. El monitoreo se puede realizar utilizando herramientas de código abierto como Prometheus, Grafana o con herramientas propietarias. Es muy importante que monitorees este tráfico para poder prevenir violaciones antes de que ocurran. Puedes configurar alarmas y otras cosas si la herramienta lo admite para prevenir de manera proactiva cualquier violación de seguridad. Además, ten en cuenta estas mejores prácticas de infraestructura al asegurar un clúster de Kubernetes. Asegúrate de que toda la comunicación se realice a través de TLS. Protege etcd con firewall y cifrado TLS y restringe el acceso a él utilizando credenciales sólidas. Configura políticas de IAM, políticas de acceso de IAM en un entorno compatible como, ya sabes, AWS, GKE o Azure. Asegura el plano de control de Kubernetes, no lo dejes abierto. Rota tus credenciales de infraestructura con frecuencia. Y si estás utilizando una cloud o PaaS, restringe el acceso a la API de metadatos de la cloud porque PaaS como AWS, Azure, GCP proporcionan estas API de metadatos que podrían tener información que no deseas que sea pública. Así que asegurar los contenedores es tan importante como asegurar el clúster. Hasta ahora, vimos qué se puede hacer a nivel de clúster para asegurar la configuración de tu Kubernetes, pero también es muy importante que sigamos las mejores prácticas a nivel de contenedor. Entonces, veamos cuáles son. Así que no ejecutes tus contenedores como usuario root, ya que esto daría al contenedor acceso ilimitado al host. En caso de que un contenedor comprometido, esto daría al atacante acceso de root y ampliaría la superficie de ataque. Siempre ejecuta los contenedores utilizando un usuario no root para limitar el acceso y utiliza el usuario con los privilegios mínimos tanto como sea posible. Quiero decir, utiliza estos privilegios tanto como sea posible. Para los contenedores de Node.js específicamente, las imágenes base oficiales tienen un usuario con los privilegios mínimos llamado node.

Entonces, podemos usar eso en lugar de root para mayor seguridad. A continuación, sería utilizar imágenes base oficiales mínimas y actualizadas. Por lo tanto, eliminar todas las dependencias, paquetes y herramientas de depuración no deseadas de la imagen, ya que la hará más segura, reducirá la superficie de ataque y también hará que la imagen sea más liviana. Y asegúrate de utilizar imágenes verificadas oficialmente para software popular y preferir versiones LTS cuando sea posible ya que tendrán parches y actualizaciones de seguridad más prolongados. Y finalmente, utilizar un registro confiable para imágenes no oficiales o para imágenes no oficiales, incluso considerar construir las imágenes desde el código fuente propio y alojarlas en tus registros privados. Y si estás utilizando registros de terceros, siempre verifica el editor de la imagen y asegúrate de que sea de un editor reputado. No confíes en todos los registros o editores que encuentres.

A continuación, sería evitar cargar módulos de kernel no deseados en los contenedores, especialmente durante el desarrollo. Podría terminar usando más de los kernels de Linux subyacentes con fines de depuración o pruebas. Pero para producción, asegúrate de no cargar ningún módulo de kernel no deseado. Esto se puede restringir utilizando reglas en ETCModProb o desinstalando los módulos no deseados del propio nodo. Esto reduce las superficies de ataque y también reduce el uso de recursos de ese contenedor en particular. A continuación, habilita el escaneo de imágenes de contenedor en tu fase de CACD. Esto te ayudará a detectar vulnerabilidades conocidas antes de que se conviertan en un vector de ataque. Puedes utilizar herramientas de código abierto como Clio o Anchor para esto, o herramientas comerciales como Deluxe o Acid. Estas son bastante fáciles de configurar y admiten la mayoría de las soluciones de CACD de forma predeterminada. Otra buena práctica para los contenedores sería utilizar Docker Bench for Security para auditar tus imágenes de contenedor personalizadas y seguir las mejores prácticas de seguridad. Por lo tanto, si estás construyendo imágenes de contenedor para tu aplicación, es una buena idea ejecutarlas a través de Docker Bench for Security para asegurarte de que estás siguiendo todas las mejores prácticas de seguridad y descubrir prácticas adicionales de seguridad que puedas implementar para tu contenedor en particular. Es una excelente herramienta para garantizar que las imágenes personalizadas que construyes para producción sigan todas las mejores prácticas posibles.

Otra buena práctica para los contenedores sería utilizar Pod Security Admission. Esta es la sucesora de Pod Security Policies. A partir de la versión 1.21 de Kubernetes, las Pod Security Policies se duplican y la sucesora es Pod Security Admission, por lo que puedes utilizar este módulo para limitar el acceso del contenedor al host. Esto ayudará a reducir la superficie de ataque y también ayudará a prevenir la escalada de privilegios en caso de que un contenedor sea comprometido.

Y ya que estamos hablando de asegurar clústeres de Kubernetes en un ecosistema de JavaScript, hay algunas cosas específicas de Node.js que debes tener en cuenta al asegurar tus contenedores de Node.js que se ejecutan en Kubernetes. Solo instala dependencias de producción. En tus imágenes, cuando estés instalando una dependencia de producción, asegúrate de pasar la bandera de producción para no terminar instalando dependencias de desarrollo u otras dependencias que no sean de producción ya que esto reduciría la superficie de ataque. Optimiza para producción configurando Node en modo de producción. Las aplicaciones de Node.js tienen algunas optimizaciones cuando se ejecutan en modo de producción y son mucho más seguras. Finaliza las aplicaciones de forma segura utilizando un sistema de inicio como dump init. En su mayoría, solo ejecutamos Node server.js o Node nombreArchivo.js, pero eso no es ideal. En caso de que la aplicación se bloquee, las cosas no se limpian, la aplicación no se finaliza correctamente, por lo que utiliza un sistema como dump init para que todas las señales de tu host se transmitan correctamente a la aplicación misma. Y finalmente, utiliza un archivo Docker Ignore para ignorar archivos sensibles como .n, .npmrc, etc., porque estos archivos contendrán información sensible como contraseñas o tokens, y no hay razón para exponer eso al contenedor, lo que también podría terminar en dominios públicos si son contenedores públicos.

Eso es todo, amigos. Espero que la charla haya valido la pena y gracias por asistir. Puedes ponerte en contacto conmigo a través de Twitter y visita mi sitio web para obtener más contenido. Gracias.

Entonces, la pregunta fue, ¿qué tipo de autenticación utilizas para tus clústeres de Kubernetes? Bueno, tenemos un gran ganador, y creo que esto no es una sorpresa con un 63% de tokens. Sí, definitivamente. ¿Esperabas una victoria tan abrumadora? Sí, esto es algo que esperaba. Porque eso es lo que la mayoría de las personas haría de forma predeterminada. Estoy bastante sorprendido por la cantidad que tiene OIDC. ¿Sabemos cuántos votos hay en total? No puedo ver eso, pero no, solo vemos porcentajes, sí. De acuerdo. Porque no esperaba OIDC. No, está bien. Sería la forma más segura, por supuesto. Así que está bien. Está creciendo. Pero, sí, es... ¿Perdón? Está creciendo, sí. De 16 a 19. Sí. Así que, sí, definitivamente no es una sorpresa que la gente use tokens como el mecanismo de autenticación predeterminado, porque en la mayoría de las configuraciones, también es el predeterminado, así que tiene sentido. Así que no creo que mucha gente cambie esto a menos que tenga requisitos específicos y dependiendo de su equipo y demás, pero sí, eso es interesante, definitivamente.

Oh, está creciendo. Creciendo de nuevo. Oh, súper rápido. E incluso 0% para autenticación básica. Así que supongo que eso sería solo nombre de usuario y contraseña. Sí, sí, definitivamente. Esa es una buena tendencia, sin duda. Pero, sí. Quiero decir, los tokens no están tan mal. Pero, sí, para organizaciones más grandes, para equipos más pequeños, creo que los tokens están perfectamente bien. No necesitas OADC para todos. Pero si estás en un equipo más grande donde hay mucha rotación, y especialmente si estás tratando de hacer R-back, lo cual debe reflejar la composición de tu organización, y demás, entonces creo que OADC es la mejor elección.

De lo contrario, es demasiado complicado administrar tokens todo el tiempo y cosas así. Sí. Creo que deberíamos seguir hablando durante unos cinco o diez minutos, y luego OADC será el ganador, ya que está creciendo y creciendo. Probablemente. Sí. Justo ahí.

Pasemos a las preguntas reales de la audiencia. La primera, ¿qué opinas de que OADC es el mecanismo de autenticación más seguro y flexible para Kubernetes? ¿Cómo facilita el proceso de incorporación? Sí, eso es algo de lo que estaba hablando. Creo que el aspecto más agradable de OADC, aparte de la seguridad y todo eso, es la flexibilidad, porque una vez que hayas configurado tu clúster para la autenticación de OADC, y una vez que hayas establecido eso, agregar nuevos usuarios y eliminarlos se vuelve muy fácil, porque no vas a guardar nada en la computadora de un usuario, porque con la autenticación basada en certificados, aún necesitas tener esos tokens y esos certificados en tu computadora portátil. Tienes que hacer esa autenticación, tienes que mantenerla. Y si quieres eliminar a alguien del acceso al clúster, tendrías que asegurarte de que lo hayan eliminado, o tendrías que cambiar tus credenciales y cosas así. Así que eso se vuelve muy molesto. Solía trabajar en una empresa donde hacíamos mucho DevOps, no éramos un equipo enorme. Éramos como 6-7 personas, pero aún así era molesto cada vez que había un nuevo miembro en el equipo o cuando alguien se iba, tenías que asegurarte de que todo eso se borrara y cosas así. Entonces, OADC hace que eso sea extremadamente flexible porque no tienes que tocar la configuración de tu Kubernetes en absoluto. Puedes hacer todo desde la administración de usuarios de OADC, puedes agregar nuevos usuarios, puedes eliminarlos. Simplemente se traduce en tu acceso. Entonces, si alguien es eliminado, ya no tendrán acceso, porque puedes hacerlo desde tu proveedor de autenticación o desde la propia aplicación de OADC. Entonces, eso lo hace extremadamente flexible, especialmente para organizaciones más grandes, donde habrá cambios en el equipo o si vas a tener rotación. Y también facilita RBAC. Porque con OADC y RBAC juntos se vuelve tan flexible que puedes gestionar el acceso y la autorización especialmente a un nivel muy granular. Puedes reflejar eso en función de cómo esté configurada tu empresa. Entonces, lo hace muy seguro y extremadamente flexible. Sí, eso es todo. Gracias.

Pregunta de CC Miller. Oh, espera, lo siento, eso no fue una pregunta. Eso fue una nota sobre la encuesta. Pero él no ha hecho una pregunta. Si estás trabajando con alguien que dice, ¿por qué molestarse, tenemos seguridad en la aplicación?

¿Cuál es tu respuesta a eso? Lo siento, ¿puedes repetir la pregunta de nuevo? Si estás trabajando con alguien que dice, ¿por qué molestarse, tenemos seguridad en la aplicación, entonces, ¿cuál es tu respuesta a eso? Eso es algo completamente diferente. La seguridad en la aplicación es la autenticación o lo que sea para tus aplicaciones, pero si tu clúster no está seguro, si cualquiera puede acceder a tu clúster, entonces estás en una situación muy mala porque no importa si tu aplicación tiene seguridad o no. Si puedo acceder a tu clúster, si puedo hacer SSH en tu clúster, puedo hacer cualquier cosa. No importa si tu aplicación está segura o no. Primero debes asegurar tu clúster. Un clúster de Kubernetes es equivalente a tu infraestructura. No tendrías tu infraestructura sin seguridad porque si tu aplicación está segura. Diría que asegurar tu clúster de Kubernetes es más importante que la seguridad de tu aplicación porque es la llave del reino. Puedes acceder a todo. Puedes acceder a la base de datos desde allí dependiendo de tu configuración. Puedes hacer mucho si tienes acceso a tu clúster de Kubernetes. Espero que para CC Miller no tengas realmente a alguien en el equipo que no le importe la seguridad. Sí. Estaría muy feliz si alguien dice eso. Oremos para que no sea un escenario real.

La siguiente pregunta es de Ravi. ¿Qué hay de los mecanismos de seguridad para clústeres de Kubernetes basados en la nube? Para los basados en la nube, por ejemplo, si estás hablando de AWS o AKS o GKE, básicamente puedes usar OADC con cualquiera de ellos. Incluso todos ellos facilitan la configuración de los proveedores de OADC. Algunos de ellos proporcionan los suyos propios. Por ejemplo, con Google, incluso puedes usar Google OADC o puedes usar un proveedor de terceros como Octa o incluso Key Clause o cualquier otro. Lo que prefieras. Proporcionan mecanismos para integrar y facilitar. Algunos de ellos también proporcionan formas adicionales de autenticación porque Kubernetes también te permite, ahí es donde entra la otra cosa. Puedes agregar otras formas de autenticación como en GCP, por ejemplo en GCP, agregan su propio mecanismo de autenticación cuando configuras tus clústeres. De forma predeterminada, es una especie de mecanismo de token, pero lo hacen de una manera muy... No diré que es transparente, pero es fácil de configurar. No tienes que configurar todo manualmente. Puedes iniciar sesión a través de tu consola de Google, pero se traduce en una especie de autenticación de token, pero es una autenticación personalizada. Si observas cómo funciona, es personalizado. No es la autenticación de token predeterminada, sino una autenticación personalizada que han creado. Con todos estos proveedores, también puedes usar OADC. Aún así, diría que OADC es el mejor mecanismo de autenticación incluso con proveedores de la nube, si deseas flexibilidad, pero si eres un equipo pequeño, de una o dos personas, entonces probablemente no importa. Puedes usar el mecanismo de autenticación predeterminado proporcionado por el proveedor de la nube. Por favor, no uses autenticación básica. Cualquier cosa que no sea autenticación básica está bien, para equipos más pequeños. Todos estos mecanismos deberían funcionar de la misma manera en los proveedores de la nube.

¿Cuál dirías que es el punto de inflexión en el tamaño del equipo, o depende de cuántos cambios haya en tu equipo? Sí, realmente depende. Si tienes un equipo estable de 10 personas que no va a cambiar durante un tiempo, entonces probablemente no sea un gran problema, Pero si va a haber cambios constantes, entonces creo que es una buena idea y también depende del tamaño de tu empresa. Si estás en empresas, entonces tiene mucho sentido seguir este camino, porque se adapta realmente a la forma en que operan las empresas. Pero si estás en una startup o en equipos pequeños, entonces probablemente no sea un problema tan grande porque aún puedes gestionar la rotación manualmente, porque espero que no suceda todos los días o algo así. Pero estuve en un equipo pequeño donde fue un poco molesto para nosotros, pero no fue un factor decisivo, pero aún así fue molesto. Así que realmente depende. Siempre depende. Supongo que depende de cuánto tiempo dediques a hacer cosas manualmente en comparación con configurarlo, ¿verdad? Sí, exactamente. Porque es como hacer clic e instalar, y ya está hecho.

Siguiente pregunta, ¿se puede utilizar RBAC junto con otros modos de autenticación? Sí, definitivamente. RBAC se puede utilizar con otros modos. Por ejemplo, es muy común ver RBAC siendo utilizado con la autenticación de nodo. Entonces ABAC no se duplica exactamente, pero es como si no se estuviera eliminando gradualmente, pero el equipo de Kubernetes prefiere RBAC, y no están destinando recursos para desarrollar aún más ABAC. Así que está en un modo pseudo duplicado, diría yo. Pero los otros mecanismos como la autenticación de nodo o webhook, se pueden utilizar con RBAC, y a veces las combinaciones pueden hacer que tu autorización sea aún más flexible o más segura según tus necesidades. Pero sí, se pueden utilizar juntos. Muy bien. Gracias. Entonces CC Miller comentó sobre su pregunta anterior. Lo hice hace mucho tiempo, y como era de esperar, ya no es miembro del equipo. Así que eso probablemente se refiere a nuestro comentario de que esperamos que no tengas un miembro del equipo que no se preocupe por la seguridad. Sí, bueno, felicitaciones a CC Miller. Me alegra escuchar eso. Sí, puedo imaginar que es una lucha si tienes filosofías tan diferentes sobre la seguridad para trabajar con alguien en un equipo. También es una historia interesante ver cómo resultó eso o, bueno, tal vez no resultó. Pero sí, eso también es parte de trabajar juntos, ¿verdad? Lidiar con personas que tienen diferentes filosofías. Lo cual es interesante, seamos honestos. Por el momento no hay ninguna pregunta, pero tenemos a Jessica escribiendo algo. Ya no. Ella se decidió. No quería hacer una pregunta. De acuerdo. Pero eso es un buen puente hacia la siguiente parte porque Dipu va a ir a su sala de ponentes en Spatial Chat ahora. Así que si quieres... Oh, llegó la pregunta de Jessica. ¿Hay alguna limitación al optar por una implementación de código abierto de Sansibar? ¿Perdón? ¿De qué? De Sansibar. ¿Qué? ¿Qué es Sansibar? No lo sé. Sé que es como una isla, creo, pero no creo que esté hablando de una isla. Realmente no entiendo la pregunta.

Bueno, Jessica, entonces te invito a responder eso para que aún podamos repasar esta pregunta. Ella está escribiendo. Así que démosle un minuto para escribir. Busca en Google Sansibar. Oh sí. Y ella quiere discutirlo en el chat espacial. Así que hagámoslo porque no nos queda mucho tiempo.

Entonces, Deepu, muchas gracias por unirte a nosotros. Ha sido muy divertido tenerte aquí. Sí, gracias por tenerme. Y gracias a todos los que se unieron, y gracias por todas las preguntas. Espero que la charla haya sido útil y hayas podido sacar algo de esto. Así que, gracias.