¿Puppet o Chef es adecuado para administrar configuraciones de servidor muy básicas en un entorno de múltiples inquilinos?

Esto se relaciona con entornos de múltiples inquilinos, como una pequeña empresa de alojamiento.

¿Es Puppet (o similar) una tecnología adecuada para ocuparse de los cambios de masa básicos pero críticos? Por ejemplo:

• Actualización de resolvers de DNS (resolv.conf)
• Configuración de claves SSH
• Actualización de la configuración de NTP
• Configurando snmpd
• Implementación de scripts de supervisión, como extensiones SNMP Perl o scripts de Nagios

Mis preocupaciones están relacionadas con la seguridad y la invasividad:

1. No quiero que ningún servidor pueda ver ninguna configuración que no debería
2. Me preocupa que un Puppet master pueda ser vulnerable al ataque de un servidor comprometido
3. No quiero que Puppet haga ningún cambio que no debería, o revierta cualquier cambio manual realizado en el servidor.

Debo advertir esto diciendo que nunca he usado Puppet en producción, solo he jugado rápidamente en un laboratorio de pruebas, ¡así que es posible que esté pensando en esto de la manera incorrecta!

Prueba Ansible (ansible.cc). Puede ser que sea para ti. No hay ningún agente ejecutándose en sus clientes. Está creciendo muy rápido.

Otra muy buena alternativa es Salt Stack.

Ansible y Salt son fáciles de entender, puede usarlos como una herramienta de línea de comandos si lo desea, como shell distribuido.

Sí, esto es ciertamente posible. Sin embargo, decidir si debe hacerlo o no depende de usted.

En cuanto a sus consultas:

1) lo suficientemente justo. El tráfico se basa en SSL, por lo que la gestión de certificados es importante. Tampoco confíe en ningún "hecho" que el cliente proporcione en relación con su identidad, ya que el cliente puede modificarlos. Desea confiar en el certificado SSL del cliente para proporcionar la autenticación de quién es el servidor. Para ser sincero, si está utilizando cosas como hiera correctamente y evitando enormes bloques de if basados ​​en el nombre de host en su código (que realmente debería), estará bien.

2) No debería serlo, suponiendo que lo mantengas parcheado. Configurado correctamente, solo hay un pequeño vector para que los clientes ataquen al titiritero. Dicho esto, los efectos si se comprometió son grandes, así que tenga cuidado de bloquearlo.

3) Eso es realmente un problema de prueba e implementación. Si tiene un código títere sólido, no arruinará sus archivos. Toma un poco de tiempo ordenar eso, pero para lo básico (como lo necesitas) no mucho.

¿Es Puppet (o similar) una tecnología adecuada para ocuparse de los cambios de masa básicos pero críticos?

Sí, se puede usar de esta manera. Lo uso para soportar sistemas de clientes externos.

No quiero que ningún servidor pueda ver ninguna configuración que no debería

Si está utilizando una marioneta, no debe habilitar el autofirmado. Autosign permite a los hosts solicitar automáticamente un certificado. Su configuración y permisos seguramente estarán vinculados directamente al CN en el certificado. No desea que una computadora aleatoria se conecte y pueda afirmar que en realidad es el sistema con todas las cosas secretas de alta seguridad.

Si eres realmente paranoico, puedes ajustar la configuración del servidor de archivos de títeres para crear recursos compartidos a los que solo algunos sistemas pueden acceder. El acceso al servidor de archivos se basa en los certificados.

No quiero que Puppet haga ningún cambio que no debería, o revierta cualquier cambio manual realizado en el servidor.

Hay un par de enfoques diferentes para permitir cambios locales.

Un método que uso con frecuencia es el siguiente. Básicamente, si pasa una lista a un source, entonces el títere prueba cada elemento de la lista. Entonces agrego el primer elemento de la lista para apuntar a un archivo local.

  file { '/etc/ssh/sshd_config':
    ensure => present,
    source => ["/etc/ssh/sshd_config_local",
               "puppet:///modules/ssh/$ssh_config_file"],
    ...
  }

Otra opción sería hacer uso de enlaces simbólicos. Si alguien quiere usar la versión títere, hace un enlace simbólico a la versión títere de un archivo. Si quieren mantener su configuración localmente, entonces no crean un enlace simbólico.

  file { '/etc/ssh/sshd_config_puppet':
    ensure => present,
    source => "puppet:///modules/ssh/$ssh_config_file",
    ...
  }

La otra posibilidad es usar augeas para hacer cambios a nivel de línea en lugar de cambiar archivos completos. Sea muy conservador sobre lo que cambia.

3> No hay deshacer automáticamente en Puppet o en cualquiera de esas herramientas. Tienes que escribir código explícito para deshacer. Además, puede investigar la función de entornos de Puppet, tener un laboratorio de pruebas donde se prueba el nuevo código (podrían ser máquinas virtuales) y utilizar la revisión de código.

No quiero que Puppet realice ningún cambio que no debería, ni revierta ningún cambio manual realizado en el servidor.

Para los archivos de configuración que se crean con el tipo de archivo Puppets, esto se puede lograr configurando:

replace => false,

Lo uso para generar algunos archivos de configuración la primera vez que se implementa una aplicación en un servidor, pero Puppet no sobrescribirá las ediciones en ese archivo de configuración.

Sin embargo, esto va en contra de la filosofía de Puppet de ser un script de despliegue idempotente.

Puede ser mejor si puede, tener archivos separados editables por el administrador que no sean administrados por puppet que se incluyan desde los archivos que son administrados por puppet.

Puppet funciona mejor para muchos servidores con configuración idéntica. Por ejemplo, escribe toda la configuración de un servidor web compartido proporcionado por su empresa, luego crea N instancias de ese servidor. Después, hacer cambios en todas las instancias a la vez (por ejemplo, descubres que es necesario cambiar AllowOverride para todos los hosts virtuales de apache) será realmente fácil. También podrá almacenar toda la información de configuración en un solo lugar y tenerla bajo control de versión. En el caso perfecto, podrá manejar una falla de hardware desechando el host roto, reemplazándolo por uno nuevo, configurando el mismo nombre de host y firmando el certificado necesario. Puppet podría hacer todo lo demás.

Pero si termina casi sin compartir la configuración entre dos hosts, usar Puppet puede ser menos productivo que hacer la configuración manualmente. Además, administrar la mitad de la configuración del servidor con Puppet y la otra mitad manualmente puede no tener mucho sentido.

Resumen : si puede crear una configuración uniforme y estructurada para los hosts que va a administrar, Puppet es su mejor amigo, pero si tendrá que manejar cada servicio (host, host virtual, base de datos) especialmente Puppet no agregará Mucho valor.