Seguridad de marionetas y topologías de red

Fondo:

Finalmente estoy reservando algo de tiempo para unirme al siglo XXI y mirar a Puppet.

Tal como está hoy, controlamos la versión de todas las configuraciones del servidor en un repositorio que se mantiene internamente en la oficina. Cuando es necesario realizar una actualización, los cambios se vuelven a registrar en los repositorios y se envían manualmente a la máquina en cuestión. Esto generalmente significa SFTP'ing a la máquina remota y luego mover archivos a su lugar, con los permisos pertinentes, desde un shell.

Así que tengo la esperanza de que Puppet sea una extensión simple pero sorprendente de lo que ya tenemos.

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

• El proceso es siempre unidireccional. Los cambios pasan de un entorno seguro a inseguro y nunca al revés.

• La tienda principal está en el lugar más seguro posible. El riesgo de compromiso, ya sea robando configuraciones o enviando modificaciones maliciosas, se reduce considerablemente.

Pregunta:

Por lo que entiendo del modelo de servidor / cliente de Puppet es que los clientes sondean y extraen actualizaciones directamente desde el servidor. El tráfico está envuelto en SSL, por lo que no se puede interceptar ni falsificar. Pero difiere de lo que hacemos actualmente porque los servidores Puppet necesitarían estar alojados en una ubicación pública. Ya sea centralmente o uno para cada sitio de centro de datos que mantenemos.

Entonces me pregunto:

• ¿Estoy siendo innecesariamente paranoico sobre el cambio de empujar a tirar?

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

• ¿Cómo mantienen otros redes múltiples: un servidor separado para cada sitio?

Actualización 30/07/09:

Supongo que una de mis otras grandes preocupaciones es colocar, por lo que debo confiar en una sola máquina. El (los) titiritero (s) tendrían un cortafuegos, seguro y tal. Pero aun así, cualquier máquina pública con servicios de escucha tiene una superficie de ataque de cierto tamaño.

Presumiblemente, si el maestro tiene permiso para actualizar cualquier archivo en cualquiera de los clientes de títeres, entonces su compromiso finalmente resultaría en el compromiso de todos sus clientes. Los "reyes del reino", por así decirlo.

• ¿Es correcta esa hipótesis?

• ¿Hay alguna forma de mitigarlo?

Debido a que a veces almaceno contraseñas en variables en mis módulos, para poder implementar aplicaciones sin tener que finalizar la configuración manualmente, significa que no puedo colocar decentemente mi repositorio de títeres en un servidor público. Hacerlo significaría que atacar al puppetmaster permitiría obtener algunas contraseñas de aplicación o db de todas nuestras diferentes aplicaciones en todos nuestros servidores.

Mi puppetmaster está en la red privada de nuestra oficina y no ejecuto puppetd daemon en los servidores. Cuando necesito implementar, uso ssh desde la red privada a los servidores, creando un túnel y llamando de forma remota a puppetd.
El truco no es configurar el túnel remoto y el cliente de marionetas para que se conecten al puppetmaster, sino a un proxy que acepte la conexión http y pueda llegar al servidor de puppetmaster en una red privada. De lo contrario, Puppet se negará a tirar debido a un conflicto de nombre de host con 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

Funciona para mí, espero que te ayude

Tenemos dos sitios, nuestra oficina y nuestro colo. Cada sitio tiene su propio titiritero. Configuramos 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 debajo de cada sitio es un directorio svn: externals de regreso al directorio de módulos de nivel superior. Esto significa que comparten exactamente el mismo directorio de módulos. Luego nos aseguramos de que la gran mayoría de las clases que escribimos estén bajo el directorio de módulos y sean utilizadas por ambos sitios. Esto tiene la buena ventaja de obligarnos a pensar genéricamente y no vincular una clase a un sitio en particular.

En cuanto a la seguridad, alojamos a nuestro puppetmaster (y al resto de nuestra red) detrás de nuestro firewall, por lo que no estamos tan preocupados por almacenar la configuración de forma centralizada. El puppetmaster solo enviará la configuración a los hosts en los que confía. Obviamente, necesitas mantener ese servidor seguro.

No puedo juzgar cuán necesaria es tu paranoia, depende en gran medida de tu entorno. Sin embargo, puedo decir con confianza que los dos puntos principales de su configuración existente aún pueden aplicarse. Puede asegurarse de que su cambio pase de un entorno seguro (el repositorio de su oficina) al entorno menos seguro, donde sea que se encuentre su puppetmaster. Cambia el proceso de SFTP'ing a un grupo de servidores y coloca manualmente los archivos en su lugar para SFTP'ing a su puppetmaster y deja que Puppet distribuya los archivos y los coloque en el lugar correcto. Su tienda maestra sigue siendo el repositorio, y sus riesgos se mitigan.

No creo que empujar o tirar sean inherentemente más seguros que el otro modelo. Puppet hace un gran trabajo al asegurar las configuraciones en tránsito, además de autenticar tanto al cliente como al servidor para garantizar que exista una confianza bidireccional.

En cuanto a las redes múltiples, lo manejamos con un maestro de marionetas "maestro" central con maestros de marionetas satélites en cada ubicación que actúan como clientes del maestro central.

Un enfoque de diseño es tener un puppetmaster local para cada sitio de sistemas y usar una herramienta de implementación para impulsar los cambios a los puppetmasters. (Usar git con ganchos git también podría funcionar).

Esto preservaría su preocupación por los servicios de escucha en una red pública, ya que el tráfico de la red de títeres solo sería interno.

También es posible enviar los manifiestos a cada servidor y hacer que el cliente puppet analice los manifiestos y aplique las configuraciones relevantes.

aunque diga "externo", dudo mucho que las personas arbitrarias necesiten conectarse con su titiritero. siempre puedes lanzar una VPN a la mezcla. un amigo mío una vez me preguntó "¿necesita preocuparse por la seguridad del protocolo si la conexión es segura?" Si bien no estoy de acuerdo con esa actitud, una capa adicional nunca está de más y ciertamente hace maravillas en mi paranoia personal. Además, es divertido hacer túneles en túneles.

Mark Burgess, autor de cfengine y profesor universitario (a quien la marioneta parece deberle su herencia) ha escrito mucho sobre empujar y halar. Afirma que la atracción es inherentemente más segura. Si miras el sitio web de cfengine, solo han tenido como 1 incidente de seguridad de red en 17 años. Burgess afirma que se debe al diseño de extracción. Creo que un único punto de compromiso es inevitable. Estaría más preocupado por las rutas de ataque hasta ese punto.

Puede ejecutar una marioneta sin un maestro central si lo desea. Un método que he visto es usar un repositorio git y tener scripts que solo fusionarán e implementarán una actualización solo si la etiqueta está firmada por una de una lista preestablecida de claves gpg. La gente incluso resolvió cómo obtener configuraciones almacenadas (utilizadas, por ejemplo, para configurar la supervisión de nagios en un servidor central desde un recurso procesado en otro servidor).

Entonces, si el servidor central de git se vio comprometido, los otros servidores no aplicarían más actualizaciones de él. Las claves gpg estarían en las computadoras portátiles de administración del sistema o algo así, junto con alguna forma de revocar las claves.

Lea más en http://current.workingdirectory.net/posts/2011/puppet-without-masters/