‫Utilizo los secretos de Docker para mis contraseñas, pero esto
‫solo crea un archivo RAM en el contenedor.
‫Si alguien hackeó el contenedor, podría ver el
‫archivo tal como lo hace mi aplicación.
‫Si y no.
‫Excelente. Seguiremos hablando. ¿Hay alguna
‫forma mejor de hacer esto? Cifrar el contenido del secreto?
‫Luego descifrar dentro de la aplicación de una manera que un
‫hacker no pudo entender.
‫La realidad aquí
‫es que su aplicación tiene que tener su secreto en algún
‫lugar, y no se cifrarán en la memoria, ¿verdad?
‫Todo lo que sé es descifrar cosas cifradas,
‫descifrarlas en la memoria. Si un hacker
‫tiene root en su contenedor, entonces
‫podrá obtener esas cosas.
‫Si son lo suficientemente inteligentes, podrán obtener
‫esas cosas, ¿verdad?
‫El primer paso es no ejecutar su aplicación como
‫root en el contenedor.
‫Entonces, no pueden jugar con nada fuera
‫de la aplicación. No pueden ejecutar otras utilidades
‫del sistema en el contenedor que puedan leer toda la memoria, correcto.
‫La segunda cosa es que realmente, la
‫forma más segura que creo que hemos visto es algo así
‫como contraseñas y contraseñas de una sola vez donde se
‫crean, son utilizadas por su aplicación, y luego se
‫desechan y ya no bueno. La realidad es que la mayoría de la
‫gente no está lista para eso. Las aplicaciones de la mayoría de las personas no pueden manejar eso.
‫Sabes, no puedes rotar una clave API de Twitter cada cinco minutos
‫por cada aplicación que se inicie, correcto.
‫Cosas como esta. La siguiente mejor
‫opción es evitar que ese archivo permanezca permanentemente en
‫el disco.
‫Una seguridad Kubernetes
‫y seguridad Docker, esos ... Lo siento, los secretos, los secretos
‫de Kubernetes y los secretos de Swarm son algunas de
‫las mejores formas que he visto para encontrar una
‫forma de almacenar contraseñas en un archivo
‫falso en RAM. Puede configurar esos permisos para que
‫su aplicación solo pueda leerlos, de acuerdo.
‫Entonces, si alguien ingresa de alguna manera con un usuario diferente,
‫no es que tenga un usuario
‫diferente necesariamente en el contenedor, pero puede bloquearlos para que sean de solo
‫lectura, que solo puedan ser leídos por el usuario Esa
‫es tu aplicación. Ese es el tipo de cosas, correcto.
‫Entonces, eso es realmente todo.
‫Lo único que he visto mejor todavía los almacena en la
‫memoria, todavía los almacena sin cifrar.
‫Simplemente no los almacena localmente.
‫Por lo tanto, debe usar una API remota
‫como Vault, HashiCorp's Vault o algún otro sistema que ofrezca contraseñas
‫de un solo uso. Pero, de nuevo, esas cosas tendrían que
‫construirse en todo su sistema. Tendrías que diseñar
‫todo. Y eso es mucho trabajo, cierto.
‫Mientras que, usando los secretos de Kubernetes y
‫Swarm, normalmente puedes hacer esas cosas en el
‫mismo día, correcto. Puede implementar eso para casi
‫cualquier aplicación, incluso si tiene que establecerlas como variables de entorno porque las
‫aplicaciones más antiguas requieren elementos en las variables de entorno.
‫Por lo tanto, puede tenerlos en secretos y luego, en el
‫tiempo de ejecución, tener esos secretos vertidos en variables
‫de entorno si es necesario. Pero, diría que el
‫99% del tiempo, mis clientes de consultoría, están tratando con aplicaciones heredadas.
‫Cuando digo legado, me refiero a todo antes de los
‫contenedores, que es la mayoría de las aplicaciones, ¿verdad?
‫Llevamos 30 años creando aplicaciones sin
‫contenedores antes de tenerlas.
‫Entonces, tenemos muchas cosas regulares.
‫Por lo tanto, la mayoría de los equipos solo están buscando cómo colocar
‫cosas en contenedores y almacenarlas encriptadas en el disco, ¿verdad?
‫Si están en el disco, están encriptados.
‫Kubernetes y Swarm pueden hacer eso.
‫Creo que si estás usando secretos, ya eres mejor
‫que el 99% de las personas que veo, porque muy
‫pocas personas usan orquestación y también usan secretos.
‫Es un grupo muy, muy pequeño, un montón de personas.
‫Entonces, sí, creo que eres bastante bueno allí.