Dividindo o componente CA fora do mestre de marionetes

Question

Estamos ampliando nossa infra-estrutura de fantoches e gostaríamos de dividir o componente CA do servidor mestre de marionetes para outro servidor. Parte da mudança envolve também uma mudança de nome de servidor para o mestre de fantoches.

Estou com um problema no qual não consigo fazer com que a diretiva ca_server funcione corretamente na seção [main] ou [agent]. Apenas não está fazendo efeito. Então, quando eu mudo server = para o novo servername, ele quebra a capacidade dos agentes de fazer check-in, porque o nome do servidor foi alterado e não corresponde mais ao certificado.

Eu não sou um especialista em marionetes, mas o que eu preciso fazer é criar um certificado SAN com os nomes antigos e novos (por segurança) e assinar novamente todos os nós do agente em todo novamente, que vai ser um PITA real.

Existe uma maneira mais rápida / inteligente de fazer isso? Já temos centenas de nós de agentes por aí e, individualmente, assiná-los novamente será uma tarefa árdua.

    

Answer 1

Nós abordamos isso de uma maneira diferente, que parece ser mais flexível e confiável a longo prazo.

Criamos um servidor apache frontend, rodando mod_proxy e mod_balancer. Em seguida, identifica a solicitação de URL recebida e roteia as solicitações relacionadas à autoridade de certificação para um servidor de autoridade de certificação local, e as solicitações de mestre de fantoches para um pool de mestre de fantoche. Isso tem o benefício adicional de podermos ter um servidor separado lidando com diferentes ambientes.

Os fantoches precisam ser configurados para aceitar as informações de autenticação do servidor front-end.

Defina o balanceador (note, 600 timeout é importante):

<Proxy balancer://puppetmaster>
  BalancerMember http://pupappprd01.its.auckland.ac.nz:18140 timeout=600
  BalancerMember http://pupappprd02.its.auckland.ac.nz:18140 timeout=600
  BalancerMember http://pupappprd03.its.auckland.ac.nz:18140 timeout=600
</Proxy>
# CA, facts and filebucket server
<Proxy balancer://puppetmasterca>
  BalancerMember http://puprepprd01.its.auckland.ac.nz:18140
</Proxy>

Agora defina o frontend:

Listen 8140
<VirtualHost *:8140>
  SSLEngine on
  SSLProtocol -ALL +SSLv3 +TLSv1
  SSLCipherSuite ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM:-LOW:-SSLv2:-EXP
  SSLCertificateKeyFile /var/lib/puppet/ssl/private_keys/puppet.auckland.ac.nz.pem
  SSLCertificateFile /var/lib/puppet/ssl/certs/puppet.auckland.ac.nz.pem
  SSLCACertificateFile /var/lib/puppet/ssl/ca/ca_crt.pem
  SSLCertificateChainFile /var/lib/puppet/ssl/ca/ca_crt.pem
  SSLCARevocationFile     /var/lib/puppet/ssl/ca/ca_crl.pem
  SSLVerifyClient optional
  SSLVerifyDepth  1
  SSLOptions +StdEnvVars

  # Send info to downstream workers
  RequestHeader set X-SSL-Subject %{SSL_CLIENT_S_DN}e
  RequestHeader set X-Client-DN %{SSL_CLIENT_S_DN}e
  RequestHeader set X-Client-Verify %{SSL_CLIENT_VERIFY}e

  <Location / >
    SetHandler balancer-manager
    Order allow,deny
    Allow from all
  </Location>

  # The manifest can take up to 10min to build (default timeout is 2min)
  Timeout 600
  ProxyTimeout 600
  # This is required to prevent a race condition that can cause
  # the puppet agent to lock up
  SetEnv proxy-nokeepalive 1
  SetEnv proxy-initial-not-pooled 1

  ProxyPreserveHost On

  # CA - centralise the authentication
  # members of the puppetmasterca cluster will rsync the cert stores
  ProxyPassMatch   ^(/.*?)/(certificate.*?)/(.*)$ balancer://puppetmasterca
  ProxyPassReverse ^(/.*?)/(certificate.*?)/(.*)$ balancer://puppetmasterca

  # Filebucket - this be on the central server to minimise duplication
  # members of the puppetmasterca cluster will rsync the file bucket
  ProxyPassMatch   ^(/.*?)/file_bucket_file/(.*)$ balancer://puppetmasterca
  ProxyPassReverse ^(/.*?)/file_bucket_file/(.*)$ balancer://puppetmasterca

  # ALL Report uploads handled by central servers
  # These will in turn upload reports to dashboard, depending on settings
  # in the puppet.conf for that environment
  ProxyPassMatch   ^(/.*?)/report/(.*)$ balancer://puppetmasterca
  ProxyPassReverse ^(/.*?)/report/(.*)$ balancer://puppetmasterca

  # Production servers - catalogue, cache, facts, file metadata and fetch
  # These servers all synchronise with subversion every 15 min
  # Need the extended timeout because some manifest generation can
  # be slow. 5min should be sufficient.
  ProxyPassMatch   ^/production/ balancer://puppetmaster timeout=600
  ProxyPassReverse ^/production/ balancer://puppetmaster timeout=600

</VirtualHost>

Agora, podemos definir o mestre de fantoches responsável pelas solicitações no servidor da CA e no Puppetmaster. Observe como passamos as informações de autenticação nos campos de cabeçalho adicionais:

Listen 18140
<VirtualHost *:18140>
  SSLEngine off

  # Obtain Authentication Information from Client Request headers
  SetEnvIf X-Client-Verify "(.*)" SSL_CLIENT_VERIFY=$1
  SetEnvIf X-Client-DN "(.*)" SSL_CLIENT_S_DN=$1

  RackAutoDetect On
  DocumentRoot /usr/share/puppet/rack/puppetmasterd/public
  <Directory /usr/share/puppet/rack/puppetmasterd/>
      Options None
      AllowOverride None
      Order allow,deny
      allow from 127.0.0.1
      allow from puprepprd01.its.auckland.ac.nz
      deny from all
    </Directory>

    LogLevel warn
    ErrorLog /var/log/httpd/puppetmaster_error.log
    CustomLog /var/log/httpd/puppetmaster_access.log combined
</VirtualHost>

No arquivo puppet.conf, você precisa de mais algumas linhas para extrair as informações de autenticação do ambiente:

[master]
    ssl_client_header = HTTP_X_CLIENT_DN
    ssl_client_verify_header = HTTP_X_CLIENT_VERIFY

Isso é mais complexo, mas nos permite expandir horizontalmente e dividir ambientes para seus próprios servidores fantoches, tanto quanto desejamos. Um servidor separado mantém a interface do relatório e a autoridade de certificação (embora isso possa ser dividido em vários back-ends da autoridade de certificação se você configurar algum tipo de replicação cert).