La administración de la revocación de certificados de confianza en contenedores como "nativo de la nube" significa que es posible

Question

La administración de la revocación de certificados de confianza en contenedores como "nativo de la nube" significa que es posible

#1 de Mike Ounsworth (0 votos)
#2 de Scott Lindner (0 votos)

1

Esta es una pregunta un poco difícil de formular, así que ten paciencia un poco. Intentaré ser breve si puedo.

Declaración de problema

Estoy buscando una mejor práctica moderna para administrar e implementar la lista de certificados de CA de confianza de los contenedores de Docker. Sé que puedo hornear los certificados en cada contenedor a través de un Dockerfile. Sin embargo, esa es una nueva imagen acoplable para cada contenedor cada vez que necesitamos hacer un certificado o un cambio de CRL. Idealmente en el espíritu de "nativo de la nube" (ver 12 aplicaciones de factores) nuestros contenedores no tendrían certificados y listas CRL incorporadas en ellos y todo esto provendría del medio ambiente de alguna manera.

Para dar un poco más de contexto. Estoy ejecutando estos contenedores en Kubernetes, pero podrían ejecutarse en cualquier plataforma de contenedores como OpenShift, AWS, etc. e idealmente, mi objetivo aquí es encontrar una solución única que permita una verdadera portabilidad de contenedores.

Soluciones potenciales

Algunas ideas con las que he jugado:

1) cree otro contenedor que tenga todos los certificados y CRL y monte en volumen para cada contenedor. - Este es un enfoque común, pero requiere que el contenedor se guarde en una nueva imagen cada vez que se actualice un nuevo certificado o CRL. No es horrible, pero no se siente muy "nativo de la nube".

2) Use Spring Config Server y cree un pequeño sidecar de Spring Boot que instale todos los certificados al inicio. - La configuración centralizada externa se siente nativa de la nube. - Puede requerir una modificación importante de la orden de inicio de los servicios en el contenedor que pueda requerir esos certificados. - Se siente demasiado complicado para un contenedor.

3) Use un proxy donde se gestionen todos los certificados. - Se siente como un hack para forzar todo el tráfico a través del proxy. - Posibles problemas de rendimiento y contención cuando hay una gran carga en los recursos HTTPS. - Puede que no sea posible enrutar todo a través de HTTP directo.

4) Use variables de entorno y tenga un script de inicio que los instale - Enfoque simple y generalizado para cualquier tipo de contenedor desplegado en cualquier lugar. No estoy seguro de si es apropiado hacerlo de esta manera. Esos serían muchos valores de variables de entorno grandes. ¿Te imaginas cómo será un "printenv"?

5) Utilice los secretos de Kubernetes (no estoy seguro de que esto pueda funcionar todavía) - Es una solución exclusiva para kubernetes, que es una decepción para escribir una sola vez, usar en cualquier lugar.

Sé que esto es un poco largo sinuoso. Me disculpo por eso. No sabía cómo comprimirlo más. Espero con interés la discusión sobre esto.

certificates docker cloud-computing container

pregunta Scott Lindner 13.08.2018 - 23:15

fuente

2 respuestas

Lea otras preguntas en las etiquetas certificates docker cloud-computing container

Seguridad de AWS Lambda que se comunica con la API que no es HTTPS ¿Es este código tan inseguro como parece? [cerrado]

score 0 · Answer 1

Una solución que surgió del chat / comentarios:

Publique un tarball de lo que debería ser el almacén de confianza en alguna URL estática: tiene la capacidad de actualizar esto a su conveniencia.
Para el certificado TLS en esta URL, use un certificado en el que el contenedor de la ventana acoplable confíe en su configuración predeterminada, desde una CA de confianza pública o una CA raíz privada explícitamente para este propósito que agregue manualmente a la plantilla de la ventana acoplable. Llamemos a esto la CA de arranque.

El lugar donde debe colocar el certificado CA de arranque depende de cómo vaya a buscar el archivo comprimido. Por ejemplo, con rizo:

$ curl -O https://my.server/docker_root_cas.pem --cacert [file]

Dado que los certificados de CA son información pública, simplemente suelte el certificado de CA en cualquier lugar del sistema de archivos (por supuesto, asegúrese de que un atacante no pueda modificarlo antes del arranque. Pero si eso fuera cierto, tendría más problemas ... )

Ahora ha recuperado de forma segura la lista de certificados de CA confiables. Esto también conduce a un mecanismo de actualización fácil al hacer que los contenedores retiren la lista periódicamente desde esta URL o desde una protegida por un certificado TLS que se encadena a una de las CA que acaba de importar.

Consideraciones de seguridad

La imagen de la ventana acoplable debe estar protegida contra un atacante que reemplaza el archivo de CA de arranque con el suyo propio.
El servidor que aloja el tarball se convierte en un gran objetivo, por lo tanto, endurézcalo bien. De manera doble, si tiene un mecanismo de actualización donde los contenedores continúan extrayendo periódicamente los almacenes de confianza, porque ahora un compromiso del servidor de tarball comprometerá a todos los contenedores todos nuevos y todos existentes en uno cayó de golpe.

score 0 · Answer 2

Llegué a una conclusión que funciona bien para nuestras necesidades y que quiero ofrecer como respuesta a mi propia pregunta. Hemos implementado un script de shell que estamos inyectando en nuestros contenedores que se puede habilitar y configurar a través de variables de entorno. Lo que hace este script es descargar una bola de alquitrán o un zip de todos los certificados de CA confiables (y certificados autofirmados para propósitos de desarrollo) para instalarlos en el inicio del contenedor de la ventana acoplable. Lo que esto hace es permitirnos crear un solo contenedor que se pueda implementar en cualquier lugar sin hornear los certificados en el contenedor. Además, esto agrega los beneficios de resolver un problema de distribución de certificados y CRL. Debido a que nos esforzamos para que nuestros contenedores cumplan con los 12 factores posibles (es decir, nativos de la nube), los contenedores se pueden reiniciar de forma periódica, lo que servirá efectivamente para distribuir nuestros certificados de confianza y CRL.

Tengo una prueba del concepto de este trabajo y funciona extremadamente bien. Para aquellos que son compatibles con el DoD y el IC, esto tiene una ventaja adicional, ya que los certificados y las CRL aprobados para las redes de confianza ya se mantienen y publican en la red, de modo que puede apuntar este script directamente a los archivos tar oficiales para distribuir sus certificados y CRL. .

Estoy usando supervisord en nuestros contenedores y he configurado todos los [programas] para que no se inicien automáticamente, con la excepción de un bootstrap.sh que primero ejecuta el script de instalación del certificado y luego utiliza supervisorctl start [programa] para iniciar los programas definidos en supverisord.conf. Qué bootstrap.sh es el único programa en supervisord.conf que se inicia automáticamente. Esto garantiza que los certificados estén en su lugar antes de que comience algo más.

Un detalle esencial que puede ser esencial para aquellos que buscan implementar una solución similar. Opcionalmente, también estamos pasando un certificado al contenedor como una variable de entorno que se utilizará solo para confiar en la URL de la bola tar de certificado que también se inyecta a través de una variable de entorno. Esto resuelve la posibilidad de que la Captura 22 requiera un nuevo certificado para obtener la bola de tar de certificado.