26 votos

Puppet de Seguridad y Topologías de Red

Antecedentes:

Finalmente estoy dejando de lado algo de tiempo para unirse a la Siglo 21 y mirar de Puppet.

Tal y como está hoy en día tenemos la versión de control de todas las configuraciones de servidor en un repositorio que se lleva a cabo internamente en la oficina. Cuando una actualización de las necesidades de decisiones, los cambios se verifican de nuevo en los repositorios y empujado manualmente a la máquina en cuestión. Esto significa, generalmente, SFTP ing a la máquina remota y, a continuación, mover archivos en su lugar, con los pertinentes permisos, desde una shell.

Así que tengo la esperanza de que la Marioneta que va a ser una simple pero increíble extensión de lo que ya tenemos.

Ahora considero que el proceso que actualmente tenemos a ser razonablemente seguro. En el supuesto de que nuestra red interna siempre será relativamente más seguras que las redes públicas en nuestros centros de datos.

  • El proceso es siempre de una manera. Cambios de recorrido de un entorno seguro a la inseguridad y nunca al revés.

  • El maestro de la tienda está en el lugar más seguro posible. El riesgo de compromiso, ya sea por el robo de configuraciones o enviando malicioso modificaciones, es muy reducido.

Pregunta:

Por lo que yo entiendo de la Marioneta del cliente/servidor modelo es que los clientes de la encuesta y tire de las actualizaciones de abajo directamente desde el servidor. El tráfico SSL envuelto por lo que no puede ser interceptada o falso. Pero difiere de lo que tenemos actualmente, porque el Puppet servidor[s] tendría que estar alojado en un lugar público. O bien de forma centralizada, o uno para cada centro de datos del sitio que mantenemos.

Así que me pregunto:

  • Estoy siendo innecesariamente paranoico sobre el cambio de push a pull?

  • Estoy siendo innecesariamente paranoico sobre el almacenamiento centralizado de toda esa información en una red pública?

  • Cómo están los otros, el mantenimiento de múltiples redes - servidor separado para cada sitio?


Actualización 30/07/09:

Supongo que otra de mis grandes preocupaciones es la colocación debe confiar en una sola máquina. El puppetmaster(s) estaría detrás de un firewall, seguro y tal. Pero, aún así, cualquier máquina pública con servicios de escucha tiene una superficie de ataque de un cierto tamaño.

Presumiblemente, si el maestro tiene permiso para actualizar cualquier archivo en cualquier una de las marionetas de los clientes, entonces es el compromiso podría resultar en el compromiso de todos sus clientes. Los "reyes del reino" por así decirlo.

  • Es que la hipótesis correcta?

  • Hay alguna manera de que pueda ser mitigado?

10voto

Alex F Puntos 343

Porque a veces me almacenar las contraseñas en las variables en mi módulos, para poder implementar aplicaciones sin tener que finalizar la configuración de forma manual, significa que no puedo decentemente poner mi títere repo en un servidor público. Hacerlo significaría que atacar el puppetmaster permitiría obtener alguna aplicación o la base de datos de contraseñas de todos nuestros diferentes aplicaciones en todos nuestros servidores.

Así que mi puppetmaster es en nuestra oficina de la red privada, y no corro el puppetd demonio en los servidores. Cuando siento la necesidad de implementar el uso ssh privado de la red a los servidores, la creación de un túnel y de forma remota llamada puppetd.
El truco no es para establecer el túnel remoto y títere de cliente para conectarse a la puppetmaster, pero a un proxy que aceptar http connect y puede alcanzar el puppetmaster servidor en la red privada. De lo contrario, la marioneta se niegan a tirar porque el nombre del host en conflicto con los certificados

# From a machine inside privatenet.net :
ssh -R 3128:httpconnectproxy.privatenet.net:3128 \
    -t remoteclient.publicnetwork.net \
    sudo /usr/sbin/puppetd --server puppetmaster.privatenet.net \
    --http_proxy_host localhost --http_proxy_port 3128 \
    --waitforcert 60 --test –-verbose

A mí me funciona, la esperanza de que ayude a usted

4voto

David Pashley Puntos 17011

Tenemos dos sitios, la oficina y nuestro colo. Cada sitio tiene su propia puppetmaster. Hemos creado un repositorio svn con la siguiente estructura:

root/office
root/office/manifests/site.pp
root/office/modules
root/colo
root/colo/manifests/site.pp
root/colo/modules
root/modules

El directorio de módulos en cada sitio es un svn:externals directorio de vuelta a la parte superior del nivel de directorio de módulos. Esto significa que comparten exactamente el mismo directorio de módulos. Nosotros, a continuación, asegúrese de que la gran mayoría de las clases de escritura se encuentran bajo el directorio de módulos y usado por ambos sitios. Esto tiene la ventaja agradable de lo que nos obliga a pensar de forma genérica y no atar a una clase a un sitio en particular.

En cuanto a la seguridad, alojamos nuestros puppetmaster (y el resto de nuestra red) detrás de nuestro firewall, por lo que no estamos de que se trate acerca de cómo almacenar la configuración de la central. El puppetmaster sólo enviar config para que los hosts de confianza. Obviamente, usted necesita para mantener ese servidor seguro.

2voto

Armend Krasniqi Puntos 36

Yo no puedo hacer un juicio sobre lo necesario de su paranoia, que depende en gran medida de su entorno. Sin embargo, puedo decir con confianza que los dos puntos principales de su configuración existente todavía se puede aplicar. Usted puede asegurarse de que su cambio de recorrido de un entorno seguro (el repositorio en su oficina) para el entorno menos seguro, siempre que su puppetmaster se encuentra. Cambia el proceso de SFTP ing a un montón de servidores y poner manualmente los archivos en lugar de SFTP ing a su puppetmaster y dejar Puppet de distribuir los archivos y ponerlos en el lugar correcto. Su maestro de la tienda es todavía el repositorio, y sus riesgos son mitigados.

No creo que empujar o tirar son inherentemente más seguro que el otro modelo. Puppet hace un gran trabajo de protección de las configuraciones en tránsito, así como la autenticación de cliente y servidor para asegurarse de que hay una relación de confianza bidireccional en el lugar.

Como para las múltiples redes - manejamos con una central de "maestro" puppetmaster con sattelite puppetmasters en cada lugar de actuar como clientes a la central principal.

1voto

Luke Puntos 73

Un enfoque de diseño es tener un puppetmaster locales en cada sitio de los sistemas y el uso de una herramienta de despliegue para llevar los cambios a la puppetmasters. (El uso de git git ganchos podría trabajar demasiado).

Esto podría preservar su preocupación acerca de los servicios de escucha en una red pública como el títere de tráfico de la red sólo sería internos.

También es posible empujar el se manifiesta a cada servidor y hacer que el títere cliente analizar los manifiestos y aplicar las correspondientes configuraciones.

0voto

aunque se puede decir "externo", yo realmente duda de arbitraria la gente necesita para conectarse a su puppetmaster. siempre se puede tirar de una VPN en la mezcla. un amigo mío una vez me preguntó "¿usted necesita preocuparse acerca de la seguridad del protocolo, si la conexión es segura?" mientras no estoy de acuerdo con esa actitud, una capa extra nunca está de más y, ciertamente, funciona de maravilla en mi paranoia. además, es divertido túnel de túneles.

EnMiMaquinaFunciona.com

EnMiMaquinaFunciona es una comunidad de administradores de sistemas en la que puedes resolver tus problemas y dudas.
Puedes consultar las preguntas de otros sysadmin, hacer tus propias preguntas o resolver las de los demás.

Powered by: