Seguridad en sistemas automatizados utilizando Puppet y Chef

5

En una presentación extremadamente interesante en Puppet Camp Londres, Tomas Doran sugirió un enfoque bastante radical para mantener todo automatizado. gestionando toneladas de contenedores Docker con Puppet.

Como persona preocupada por la seguridad, me gusta la idea de Docker, ya que todo se ejecuta en su propio LXC y configuro todos los servicios para que se ejecuten como usuarios que no sean root .

Como una persona consciente de la administración de sistemas, me gusta la idea de la gestión de Puppet, ya que puedo mantener toda la configuración en un repositorio Git e incluso mantener diferentes entornos, todo en el control de versiones. La ventaja también es que tengo entornos capaces de derrumbarse (¿es eso una palabra?) Que, en teoría, puedo reconstruir desde cero sin demasiada intervención manual.

Sin embargo, hay cosas que me gustaría que no se mantengan en un repositorio Git, a saber, certificados SSL, contraseñas de bases de datos, etc.

¿Cómo las organizaciones que administran grandes cantidades de máquinas (como CERN) utilizan servicios de aprovisionamiento como Puppet y Chef mientras mantienen la seguridad? Ciertas cosas parecen fáciles, como imponer permisos en los archivos, pero otras parecen difíciles, como instalar claves SSL o claves de host SSH, que requieren una intervención manual.

    
pregunta Naftuli Kay 13.06.2014 - 02:08
fuente

1 respuesta

6

Solía ejecutar una instalación de títeres, así que hablaré sobre lo que hice entonces.

  1. Las claves de host SSH son efímeras. Por lo tanto, cuando construimos un nuevo sistema o reconstruimos uno existente, simplemente dejamos que SSHD genere nuevas claves cuando se inició. Hubo relativamente poca gente SSHing en estas máquinas, y cuando reconstruimos las máquinas, publicamos las huellas digitales del host en una wiki interna. Por lo tanto, un atacante tendría que comprometer las conexiones del host wiki y MITM SSH, y estar en el lugar para hacerlo inmediatamente después de que se haya construido la máquina.

  2. Siempre generamos nuevas claves SSL al reinstalar la máquina. Uno de los pasos humanos en la reconstrucción de los servicios que involucraban SSL fue generar la clave, la CSR, y obtener la firma de la CA y luego instalar el certificado. Usamos una secuencia de comandos que fue rellenada previamente por una plantilla de títeres para tener el CN & otros campos correctamente configurados.

Dudo que CERN tenga muchos hosts con certificados SSL involucrados. O tal vez sí, pero tienen una CA automatizada para firmar certificados a petición de los títeres.

Tampoco considero almacenar certificados & Las claves en un repositorio git bien controlado son necesariamente malas. Simplemente tomamos el punto en el que estábamos reconstruyendo un sistema como una gran oportunidad para rotar nuestras claves.

    
respondido por el David 13.06.2014 - 02:15
fuente

Lea otras preguntas en las etiquetas