Безопасность

[редактировать на GitHub]

В этом руководстве рассматриваются функции безопасности, доступные в Chef Infra Server.

Сертификаты SSL

Первоначальная настройка Chef Infra Server выполняется автоматически с использованием самоподписанного сертификата для создания файлов сертификата и закрытого ключа для Nginx. В этом разделе подробно описан процесс обновления сертификата SSL Chef Infra Server.

Автоматическая установка (рекомендуется)

Chef Infra Server можно настроить на использование сертификатов SSL, добавив следующие настройки в файл конфигурации сервера:

а затем задать их значения, определяющие пути к сертификату и ключу.

Например:

nginx['ssl_certificate'] = '/etc/pki/tls/certs/your-host.crt'
nginx['ssl_certificate_key'] = '/etc/pki/tls/private/your-host.key'

Сохраните файл и выполните следующую команду:

sudo chef-server-ctl reconfigure

Дополнительную информацию о файле конфигурации сервера см. в chef-server.rb.

Ручная установка

Сертификаты SSL можно обновить вручную, поместив файл сертификата и закрытого ключа, полученный от центра сертификации, в соответствующие файлы после первоначальной настройки Chef Infra Server.

Расположение файлов сертификата и закрытого ключа:

• /var/opt/opscode/nginx/ca/FQDN.crt
• /var/opt/opscode/nginx/ca/FQDN.key

Поскольку FQDN уже настроен, выполните следующие действия:

1. Замените содержимое /var/opt/opscode/nginx/ca/FQDN.crt и /var/opt/opscode/nginx/ca/FQDN.key на файлы центра сертификации.

2. Перенастройте Chef Infra Server:

   chef-server-ctl reconfigure
   

3. Перезапустите службу Nginx, чтобы загрузить новый ключ и сертификат:

   chef-server-ctl restart nginx
   

Протоколы SSL

Следующие настройки часто изменяются от значений по умолчанию в рамках процесса настройки службы nginx и для настройки Chef Infra Server на использование сертификатов SSL:

nginx['ssl_certificate']

Сертификат SSL, используемый для проверки связи по протоколу HTTPS. Значение по умолчанию: nil.

nginx['ssl_certificate_key']

Ключ сертификата, используемый для связи SSL. Значение по умолчанию: nil.

nginx['ssl_ciphers']

Список поддерживаемых наборов шифров, используемых для установления безопасного соединения. Для приоритета AES256 с защитой перенаправления ECDHE удалите префикс RC4-SHA:RC4-MD5:RC4:RSA . Например:

nginx['ssl_ciphers'] =  "HIGH:MEDIUM:!LOW:!kEDH: \
                         !aNULL:!ADH:!eNULL:!EXP: \
                         !SSLv2:!SEED:!CAMELLIA: \
                         !PSK"

nginx['ssl_protocols']

Версии протоколов SSL, включенные для API Chef Infra Server. Для повышения безопасности установите это значение в 'TLSv1.2'. TLS 1.2 поддерживается в Chef Infra Client 10.16.4 и более поздних версиях на Linux, Unix и macOS, а также в Chef Infra Client 12.8 и более поздних версиях на Windows. Если необходимо поддерживать более старые, устаревшие версии Chef Infra Client, установите это значение в 'TLSv1.1 TLSv1.2'. Например:

nginx['ssl_protocols'] = 'TLSv1.2'

Например, после копирования файлов сертификата SSL на сервер Chef Infra Server, обновите настройки nginx['ssl_certificate'] и nginx['ssl_certificate_key'] для указания путей к этим файлам, а затем (необязательно) обновите настройки nginx['ssl_ciphers'] и nginx['ssl_protocols'] для отображения желаемого уровня защиты сервера Chef Infra Server:

nginx['ssl_certificate'] = '/etc/pki/tls/private/name.of.pem'
nginx['ssl_certificate_key'] = '/etc/pki/tls/private/name.of.key'
nginx['ssl_ciphers'] = 'HIGH:MEDIUM:!LOW:!kEDH:!aNULL:!ADH:!eNULL:!EXP:!SSLv2:!SEED:!CAMELLIA:!PSK'
nginx['ssl_protocols'] = 'TLSv1 TLSv1.1 TLSv1.2'

Пример: Настройка ключей SSL для Nginx

В данном примере показано, как сервер Chef Infra Server настраивает и конфигурирует сертификаты SSL для Nginx. Набор шифров, используемый Nginx, можно настроить с помощью настроек ssl_protocols и ssl_ciphers.

ssl_keyfile = File.join(nginx_ca_dir, "#{node['private_chef']['nginx']['server_name']}.key")
ssl_crtfile = File.join(nginx_ca_dir, "#{node['private_chef']['nginx']['server_name']}.crt")
ssl_signing_conf = File.join(nginx_ca_dir, "#{node['private_chef']['nginx']['server_name']}-ssl.conf")

unless ::File.exist?(ssl_keyfile) && ::File.exist?(ssl_crtfile) && ::File.exist?(ssl_signing_conf)
  file ssl_keyfile do
    owner 'root'
    group 'root'
    mode '0755'
    content '/opt/opscode/embedded/bin/openssl genrsa 2048'
    not_if { ::File.exist?(ssl_keyfile) }
  end

  file ssl_signing_conf do
    owner 'root'
    group 'root'
    mode '0755'
    not_if { ::File.exist?(ssl_signing_conf) }
    content <<-EOH
  [ req ]
  distinguished_name = req_distinguished_name
  prompt = no
  [ req_distinguished_name ]
  C                      = #{node['private_chef']['nginx']['ssl_country_name']}
  ST                     = #{node['private_chef']['nginx']['ssl_state_name']}
  L                      = #{node['private_chef']['nginx']['ssl_locality_name']}
  O                      = #{node['private_chef']['nginx']['ssl_company_name']}
  OU                     = #{node['private_chef']['nginx']['ssl_organizational_unit_name']}
  CN                     = #{node['private_chef']['nginx']['server_name']}
  emailAddress           = #{node['private_chef']['nginx']['ssl_email_address']}
  EOH
  end

  ruby_block 'create crtfile' do
    block do
      r = Chef::Resource::File.new(ssl_crtfile, run_context)
      r.owner 'root'
      r.group 'root'
      r.mode '0755'
      r.content "/opt/opscode/embedded/bin/openssl req -config '#{ssl_signing_conf}' -new -x509 -nodes -sha1 -days 3650 -key '#{ssl_keyfile}'"
      r.not_if { ::File.exist?(ssl_crtfile) }
      r.run_action(:create)
    end
  end
end

Knife, Chef Infra Client

Chef Infra Server 12 и более поздние версии по умолчанию включают проверку SSL для всех запросов на сервер, таких как запросы от knife и Chef Infra Client. Сертификат, сгенерированный во время установки Chef Infra Server, является самоподписанным, что означает, что сертификат не подписан доверенным центром сертификации (CA), распознаваемым Chef Infra Client. Сертификат, сгенерированный Chef Infra Server, должен быть загружен на любой компьютер, с которого knife и/или Chef Infra Client будут отправлять запросы на Chef Infra Server.

Например, без загрузки сертификата SSL следующая команда knife:

knife client list

возвращает ошибку, подобную:

ERROR: SSL Validation failure connecting to host: chef-server.example.com ...
ERROR: OpenSSL::SSL::SSLError: SSL_connect returned=1 errno=0 state=SSLv3 ...

Это сделано по умолчанию и произойдёт до тех пор, пока верифицируемый сертификат не будет добавлен на компьютер, с которого отправляется запрос.

Дополнительную информацию о том, как knife и Chef Infra Client используют сертификаты SSL, сгенерированные сервером Chef Infra Server, см. в разделе Сертификаты SSL Chef Infra Client.

Приватный центр сертификации

Если организация использует внутренний центр сертификации, то корневой сертификат не отобразится ни в одном файле cacerts.pem по умолчанию в операционных системах и веб-браузерах. Из-за этого ни одна из развернутых систем не сможет проверить сертификаты, выпущенные таким способом. Чтобы другие системы могли доверять сертификатам из внутреннего центра сертификации, корневой сертификат необходимо настроить таким образом, чтобы другие системы могли отследить цепочку полномочий до корневого сертификата. (Промежуточный сертификат недостаточен, так как корневой сертификат не известен глобально.)

Для использования внутреннего центра сертификации добавьте сертификаты сервера (необязательно, а также любые промежуточные сертификаты) и корневой сертификат в один файл .crt. Например:

cat server.crt [intermediate.crt] root.crt >> /var/opt/opscode/nginx/ca/FQDN.crt

Проверьте действительность объединённого сертификата на сервере Chef Infra Server:

openssl verify -verbose -purpose sslserver -CAfile cacert.pem  /var/opt/opscode/nginx/ca/FQDN.crt

Файл cacert.pem должен содержать только файл сертификата вашего корневого центра сертификации. Это не стандартная процедура, но имитирует поведение Chef Workstation после knife ssl fetch и knife ssl verify.

Промежуточные сертификаты

Для использования с провайдерами сертификатов сторонних производителей, например, Verisign.

Для использования промежуточного сертификата добавьте оба сертификата сервера и промежуточный сертификат в один файл .crt. Например:

cat server.crt intermediate.crt >> /var/opt/opscode/nginx/ca/FQDN.crt

Проверка, что сертификат был подписан правильным ключом

Возможна ошибка несоответствия сертификата/ключа во время процесса CertificateSigningRequest (CSR). Во время CSR всегда должен использоваться исходный ключ для соответствующего сервера. Если вывод следующих команд не совпадает, то, возможно, CSR для нового ключа данного хоста был сгенерирован с использованием случайного ключа или нового сгенерированного ключа. Симптомы этой проблемы будут выглядеть следующим образом в файлах журналов nginx:

nginx: [emerg] SSL_CTX_use_PrivateKey_file("/var/opt/opscode/nginx/ca/YOUR_HOSTNAME.key") failed (SSL: error:0B080074:x509    certificate routines:X509_check_private_key:key values mismatch)

Вот как убедиться, что настроенный сертификат не соответствует ключу

## openssl x509 -in /var/opt/opscode/nginx/ca/chef-432.lxc.crt -noout -modulus | openssl sha1
(stdin)= 05b4f62e52fe7ce2351ff81d3e1060c0cdf1fa24

## openssl rsa -in /var/opt/opscode/nginx/ca/chef-432.lxc.key -noout -modulus | openssl sha1
(stdin)= 05b4f62e52fe7ce2351ff81d3e1060c0cdf1fa24

Чтобы исправить это, необходимо сгенерировать новый CSR, используя оригинальный ключ для сервера, тот же ключ, который использовался для создания CSR предыдущих сертификатов. Установите новые сертификаты вместе с оригинальным ключом, и ошибка несоответствия должна исчезнуть.

Перегенерировать сертификаты

Сертификаты SSL следует перегенерировать периодически. Это важная часть защиты сервера Chef Infra Server от уязвимостей и помогает предотвратить компрометацию информации, хранящейся на сервере Chef Infra Server.

Для перегенерации сертификатов SSL:

1. Выполните следующую команду:

   chef-server-ctl stop
   

2. Chef Infra Server может перегенерировать их. Эти сертификаты будут расположены в /var/opt/opscode/nginx/ca/ и будут именоваться в соответствии с FQDN сервера Chef Infra Server. Чтобы определить FQDN сервера, выполните следующую команду:

   hostname -f
   

   Пожалуйста, удалите файлы в каталоге ca с именами, подобными $FQDN.crt и $FQDN.key.

3. Если ваша организация предоставила настроенные сертификаты SSL для Chef Infra Server, расположение этого пользовательского сертификата и закрытого ключа определено в /etc/opscode/chef-server.rb как значения для настроек nginx['ssl_certificate'] и nginx['ssl_certificate_key']. Удалите файлы, на которые ссылаются эти две настройки, и перегенерируйте новые ключи, используя тот же центр сертификации.

4. Выполните следующую команду, сгенерированные сервером Chef SSL-сертификаты будут автоматически созданы, если это необходимо:

   chef-server-ctl reconfigure
   

5. Выполните следующую команду:

   chef-server-ctl start
   

Управление учетными данными сервера Chef Infra

Сервер Chef Infra Server ограничивает места, куда он записывает пароли и ключи служб на диск. В конфигурации по умолчанию учетные данные записываются только в файлы в /etc/opscode.

По умолчанию сервер Chef Infra Server по-прежнему записывает учетные данные служб в несколько мест внутри /etc/opscode. Это сделано для обеспечения совместимости с дополнениями. Параметр конфигурации insecure_addon_compat в файле /etc/opscode/chef-server.rb позволяет дополнительно ограничить места записи учетных данных. insecure_addon_compat можно использовать, если вы не используете дополнения или если вы используете последние версии дополнений. Установка insecure_addon_compat в false записывает учетные данные только в одно место: /etc/opscode/private-chef-secrets.json.

Секреты, предоставляемые пользователем (например, пароль для внешнего экземпляра PostgreSQL), по-прежнему могут быть установлены в /etc/opscode/chef-server.rb или с помощью команд Управление секретами. Эти команды позволяют вам предоставлять внешние пароли, не включая их в файл конфигурации.

Совместимость дополнений

В следующей таблице перечислены версии дополнений, которые поддерживают более ограниченное значение insecure_addon_compat false. Эти версии требуют Chef Server 12.14.0 или более поздней версии:

Эти более новые дополнения также запишут все свои секреты в /etc/opscode/private-chef-secrets.json. Более старые версии дополнений по-прежнему будут записывать свою конфигурацию в расположения /etc и /var/opt.

/etc/opscode/private-chef-secrets.json

По умолчанию, /etc/opscode/private-chef-secrets.json разрешает чтение или запись файла только пользователю root. Этот файл содержит все секреты для доступа к основным хранилищам данных сервера Chef, поэтому доступ к нему должен быть ограничен доверенными пользователями.

Хотя файл не содержит пароли в открытом виде, его не следует делиться с недоверенными пользователями. Формат файла секретов позволяет развертываниям Chef Infra Server соответствовать правилам, запрещающим появление конфиденциальных данных в открытом виде в файлах конфигурации; однако это не делает файл существенно более безопасным.

Шифрование SSL между Chef Infra Server и внешним PostgreSQL

Chef Infra Server может шифровать трафик между Chef Infra Server и внешним сервером PostgreSQL через SSL. Данные инструкции не являются исчерпывающими и предполагают некоторую осведомленность в администрировании, настройке и устранении неполадок PostgreSQL. Обратитесь к документации PostgreSQL для получения дополнительной информации.

Следующее — типичный сценарий для включения шифрования между машиной, на которой работает Chef Infra Server, и внешней машиной, на которой работает PostgreSQL. Обе машины должны быть подключены к сети и доступны пользователю.

1. Выполните следующую команду на обеих машинах, чтобы получить права root:

   sudo -i
   

2. Убедитесь, что OpenSSL установлен на машине PostgreSQL.

3. Убедитесь, что поддержка SSL скомпилирована в PostgreSQL. Это относится как к компиляции из исходного кода, так и к использованию предварительно скомпилированной двоичной версии.

4. Разместите сертификаты SSL в соответствующих каталогах на машине PostgreSQL и убедитесь, что у них правильные имена файлов, права владения и разрешения.

5. Включите SSL в PostgreSQL, отредактировав файл postgresql.conf. Установите ssl = on и укажите пути к сертификатам SSL:

   ssl=on
   
   ssl_cert_file='/path/to/cert/file'
   ssl_key_file='/path/to/key/file'
   

6. Чтобы предотвратить принятие PostgreSQL подключений без SSL, отредактируйте pg_hba.conf на машине PostgreSQL и измените соответствующие подключения Chef Infra Server на hostssl.

   Вот пример файла pg_hba.conf с подключениями hostssl для Chef Infra Server (содержимое вашего pg_hba.conf будет другим):

   # "local" is for Unix domain socket connections only
   local      all             all                                     peer
   
   # IPv4 local connections:
   hostssl    all             all             127.0.0.1/32            md5
   
   # IPv6 local connections:
   hostssl    all             all             ::1/128                 md5
   
   # nonlocal connections
   hostssl    all             all            192.168.33.100/32        md5
   

7. Перезапустите PostgreSQL. Обычно это можно сделать с помощью следующей команды на машине PostgreSQL:

   /path/to/postgresql/postgresql restart
   

8. Отредактируйте /etc/opscode/chef-server.rb на Chef Infra Server и добавьте следующую строку:

   postgresql['sslmode'] = 'require'
   

9. Выполните reconfigure на Chef Infra Server:

   chef-server-ctl reconfigure
   

10. Проверьте, что SSL включен и что подключения SSL активны между Chef Infra Server и работающим экземпляром PostgreSQL. Один из способов сделать это — войти в базу данных PostgreSQL с Chef Infra Server, выполнив chef-server-ctl psql, а затем проверить состояние SSL с помощью запросов SQL.

    Запустите сеанс psql:

    chef-server-ctl psql opscode_chef
    

    В сеансе psql введите postgres=# show ssl;, что покажет, включен ли ssl:

    postgres=#showssl;ssl-----
    on(1row)

    Затем введите postgres=# select * from pg_stat_ssl;, которое вернет true (t) в строках с подключениями SSL:

    postgres=#select*frompg_stat_ssl;pid|ssl|version|cipher|bits|compression|clientdn-------+-----+---------+-----------------------------+------+-------------+----------
    16083|t|TLSv1.2|ECDHE-RSA-AES256-GCM-SHA384|256|f|16084|t|TLSv1.2|ECDHE-RSA-AES256-GCM-SHA384|256|f|16085|t|TLSv1.2|ECDHE-RSA-AES256-GCM-SHA384|256|f|16086|t|TLSv1.2|ECDHE-RSA-AES256-GCM-SHA384|256|f|16087|t|TLSv1.2|ECDHE-RSA-AES256-GCM-SHA384|256|f|16088|t|TLSv1.2|ECDHE-RSA-AES256-GCM-SHA384|256|f|16089|t|TLSv1.2|ECDHE-RSA-AES256-GCM-SHA384|256|f|16090|t|TLSv1.2|ECDHE-RSA-AES256-GCM-SHA384|256|f|16091|t|TLSv1.2|ECDHE-RSA-AES256-GCM-SHA384|256|f|16092|t|TLSv1.2|ECDHE-RSA-AES256-GCM-SHA384|256|f|16093|t|TLSv1.2|ECDHE-RSA-AES256-GCM-SHA384|256|f|16094|t|TLSv1.2|ECDHE-RSA-AES256-GCM-SHA384|256|f|16095|t|TLSv1.2|ECDHE-RSA-AES256-GCM-SHA384|256|f|16096|t|TLSv1.2|ECDHE-RSA-AES256-GCM-SHA384|256|f|16097|t|TLSv1.2|ECDHE-RSA-AES256-GCM-SHA384|256|f|16098|t|TLSv1.2|ECDHE-RSA-AES256-GCM-SHA384|256|f|16099|t|TLSv1.2|ECDHE-RSA-AES256-GCM-SHA384|256|f|16100|t|TLSv1.2|ECDHE-RSA-AES256-GCM-SHA384|256|f|16101|t|TLSv1.2|ECDHE-RSA-AES256-GCM-SHA384|256|f|16102|t|TLSv1.2|ECDHE-RSA-AES256-GCM-SHA384|256|f|16119|f|||||(21rows)

Ротация ключей

См. команды ротации ключей chef-server-ctl для получения дополнительной информации об управлении ключами пользователей.