Назад | Перейти на главную страницу

Отделение компонента CA от мастера марионетки

Мы масштабируем нашу марионеточную инфраструктуру и хотели бы отделить компонент CA от главного сервера марионетки на другой сервер. Частично изменение включает в себя изменение имени сервера и для кукловода.

Я столкнулся с проблемой, из-за которой я не могу заставить директиву ca_server правильно работать ни в разделе [main], ни в [agent]. Это просто не действует. Поэтому, когда я меняю server = на новое имя сервера, это нарушает способность агентов регистрироваться, потому что имя сервера изменилось и больше не соответствует сертификату.

Я не эксперт по марионеткам, но, как мне кажется, мне нужно создать сертификат SAN со старым и новым именами в нем (на всякий случай), а затем заново подписать все узлы агентов, что является будет королевской PITA.

Есть ли более быстрый / умный способ сделать это? У нас уже есть сотни агентских узлов, и индивидуальное повторное подписание их будет сложной задачей.

Мы подошли к этому по-другому, который в долгосрочной перспективе кажется более гибким и надежным.

Мы создали внешний сервер apache, на котором запущены mod_proxy и mod_balancer. Затем он идентифицирует входящий URL-запрос и направляет запросы, связанные с CA, на локальный сервер CA, а запросы puppetmaster - к пулу мастеров марионеток. Это имеет дополнительное преимущество, заключающееся в том, что у нас может быть отдельный сервер (ы) для обработки различных сред.

Марионеточные мастера должны быть настроены таким образом, чтобы они принимали информацию аутентификации от внешнего сервера.

Определите балансировщик (обратите внимание, важен тайм-аут 600):

<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>

Теперь определите интерфейс:

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>

Теперь мы можем определить Puppetmaster, обрабатывающий запросы на сервере CA и на Puppetmaster. Обратите внимание, как мы передаем информацию об аутентификации в дополнительных полях заголовка:

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>

В puppet.conf вам понадобится еще пара строк, чтобы получить информацию для аутентификации из среды:

[master]
    ssl_client_header = HTTP_X_CLIENT_DN
    ssl_client_verify_header = HTTP_X_CLIENT_VERIFY

Это более сложно, но позволяет нам расширяться по горизонтали и разделять среды на их собственные серверы puppetmaster сколько угодно. Один отдельный сервер содержит внешний интерфейс отчета и CA (хотя его можно разделить на несколько внутренних серверов CA, если вы настроили какую-то репликацию сертификата).