¶ 1. Подготовка SSL-сертификата и закрытого ключа
В результатом выполнения операций представленных в данном разделе является пара ключ, сертификат которые используются в разделе 2.
¶ 1.1 Устанавливаем Active Directory Certificate Services
Чтобы установить Службы сертификации AD (Active Directory Certificate Services) на вашем Server 2016, воспользуйтесь следующим набором инструкций:
1. Откройте Диспетчер сервера и кликните ссылку Add roles and features (см. Рис.1).
2. Пройдите шаги, выбрав настройки по умолчанию. Когда вы дойдёте до экрана Server Roles, выберите Active Directory Certificate Services.
3. В процессе выбора этой роли вы будете запрошены подтвердить установку дополнительных функций. Пройдите далее и кликните Add Features.
Рис. 1. Форма «Add roles and features»
4. Пару раз кликните Next пока не достигните экрана Role Services (см. Рис. 2). В нём вы увидите несколько различных вариантов которые могут быть применены для вашего сервера CA. Так как мы хотели бы иметь возможность запрашивать сертификаты через веб- интерфейс в этом CA, я собираюсь отметить дополнительный блок для Certification Authority Web Enrollment. После выбора этого блока, вы получите дополнительный всплывающий блок, запрашивающий вас добавить свойства. Проверьте что разрешили эти свойства для установки.
Рис. 2. Форма «Role Services»
5. Кликните Next по оставшимся экранам пока не достигните смой последней страницы, в которой кликните кнопку Install для начала установки этой роли.
6. Когда она завершится, вы увидите ссылку внутри итогового окна установки, которое сообщит Configure Active Directory Certificate Services on the destination server (Настройте Службы сертификации AD на сервере назначения). Вы можете кликнуть либо на эту ссылку, либо на уведомление маркера жёлтого восклицания Диспетчера сервера рядом с верхней частью экрана самого Диспетчера сервера чтобы продолжить настройку роли CA. На первом экране настроек, мастер вероятно вставит автоматически имя пользователя зарегистрированного в настоящее время пользователя. Как следует из текста на этом экране, убедитесь, что пользователь, с которым вы зарегистрировались, имеет права администратора Корпорации (Enterprise Admin) для данного домена, так как мы планируем установить этот сервер CA в качестве Корпоративного Корня CA.
7. Для раскрутки служб сертификации на нашем сервере пройдите далее и пометьте два верхних параметра для настройки Certification Authority and Certification Authority Web Enrollment (см. Рис. 3).
Рис. 3. Форма выбора конфигурации Role Services
8. Выберите Enterprise CA.
9. Выберите Root CA; так как это наш первый сервер CA, нам нужно реализовать корень до того, как мы сможем думать об субординации.
10. Выберите Create a new private key (Создать новый частный ключ).
11. В экране Cryptography (см. Рис. 4) вы имеете возможность выбрать вариант криптографии, который вы можете предоставить вашему серверу CA. Обычно, если вы не уверены в этих параметрах, опции по умолчанию являются наилучшим выбором. Только убедитесь, что ваше поле Key length установлено, как минимум, в значение 2048. Это новый стандарт отрасли для минимальной длины ключа. Аналогично, стандарт хэширования должен соответственно измениться на SHA256, на самом деле, вы не должны более применять SHA1 ни для каких своих сертификатов, поскольку в настоящее время существует оценка, что SHA1 может быть скомпрометирован в следующие пару лет.
Рис. 4. Форма «Cryptography»
12. Если пожелаете, вы можете изменить свои Common name for this CA (см. Рис. 5). Имейте в виду, что оно не должно соответствовать каким-либо образом имени хоста. Это имя вашего CA, которое будет показываться внутри Active Directory, а также внутри сертификатов, которые вы выпускаете из этого CA. Обычно я вижу, что администраторы оставляют только Distinguished name suffix (Суффикс отличительного имени).
Рис. 5. Форма «CA Name»
13. Измените Validity Period (период действия) вашего сертификата корня, если пожелаете. Часто администраторы проскакивают через это окно и оставляют значение по умолчанию пять лет, однако это означает, что всего через пять коротких лет у вас внезапно станут несостоятельными все отдельные сертификаты, которые только были выпущены из этого сервера CA. Я рекомендую это значение до 10, или даже до 20 лет, с тем, чтобы вы не беспокоились об этом истечении этого уровня сертификации длительное время. Период действия определяет, как часто должен обновляться сертификат корня.
14. Продолжите идти по оставшимся окнам, оставляя на месте установленные значения по умолчанию. Когда этот мастер завершится, ваш сервер CA теперь оживёт (см. Рис. 6).
15. Обычно хорошей мыслью является перезагрузка данного сервера после установки столь значительной роли. Пройдите далее и перезагрузитесь, как только позволит время.
Рис. 6. Сообщение об успешном завершении конфигурации
¶ 1.2 Включаем Web Server certificate template
Включение шаблона сертификата веб-сервера – это простой и не нарушающий работу процесс. Из Administrative Tools откройте инструмент Certification Authority. Затем щелкните правой кнопкой мыши папку Certificate Templates и выберите Manage:
Это откроет консоль шаблонов сертификатов, как показано ниже. Дважды щелкните по шаблону веб-сервера:
Теперь откроется окно свойств веб-сервера. Щелкните вкладку Безопасность и выберите Прошедшие проверку пользователи в разделе Группы или имена пользователей. В разделе Разрешения для Прошедших проверку пользователей отметьте действие Разрешить для разрешения Зарегистрироваться. Когда все будет готово, щелкните ОК:
Поздравляем – вы успешно включили опцию шаблона сертификата веб-сервера. Ваш сервер Windows CA теперь должен представить предыдущую опцию миссии, как показано ниже:
¶ 1.3 Создаем закрытый ключ (на каждом сервере)
openssl genrsa -out private.key 2048
¶ 1.4 Создаем файл с описанием запроса (на каждом сервере)
[root@centos-5 adcs]# cat openssl.conf
[треб]
различающееся_имя = требуемое_различающееся_имя
req_extensions = v3_req
подсказка = нет
[req_distinguished_name]
С = РУ
СТ = СПБ
Л = ЛО
О = РТК
OU = Платформа данных
CN = FQDN сервера
[v3_req]
keyUsage = keyEncipherment, dataEncipherment
extendedKeyUsage = serverAuth, clientAuth
SubjectAltName = @alt_names
[альтернативные_имена]
DNS .1 = полное доменное имя сервера¶ 1.5 Создаем ключ запроса сертификата
openssl req -new -key private.key -out request.csr -config openssl.conf
[root@centos-5 adcs]# cat запрос.csr
-----НАЧАТЬ ЗАПРОС СЕРТИФИКАТА-----
******
-----КОНЕЦ ЗАПРОСА СЕРТИФИКАТА-----¶ 1.6 Выпускаем сертификат
http:// AD сервер/certsrv
¶ 1.7 Складываем сертификаты и закрытые ключи
¶ 1.8 Скачиваем СА сертификат
¶ 1.9 Пробрасываем собранные файлы в RT.ClusterManager
¶ 1.10 Применяем конфигурации для SSL
- На форме “Провайдеры→<выбранный провайдер>→<выбранный хост>→ Конфигурация”:
2. На форме “Кластеры→<выбранный кластер>→Конфигурация”, вкладка kerberos:
3. На форме “Кластеры→<выбранный кластер>→<компонент требующий ssl>→Конфигурация”, вкладка ssl:
4. На форме “Кластеры→<выбранный кластер>→<компонент требующий ssl>→Конфигурация”, вкладка <компонент требующий ssl>_sire:
Проверяем неймноду:
¶ 2. Предварительные условия для генерации trusstore.jks/keystore.jks (SSL/PKI/LDAPS)
Значения ключ и сертификат полученные в результате действий описанных в разделе 1 используются в данном разделе.
¶ 2.1 Хранение ключей и сертификатов сервера
В inventory фале добавляется два параметра для сервера во всех hostgroups:
- ssl_cert – путь к сертификату, в формате BASE64,
- ssl_key – путь к частному ключу, в формате BASE64.
Для каждого host в inventory файле должны быть прописаны пути к сертификату и приватному ключу хоста, сохраненного на сервере с RT.ClusterManager.
Пример:
{
"vm-dcp-hdp-s-2.dcp.local": {
"ansible_user": "ansible",
"ansible_host": null,
"ansible_become": true,
"ansible_ssh_common_args": "-o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null",
"ansible_ssh_pass": null,
"ansible_ssh_port": "22",
"host_id": "4",
"ansible_ssh_private_key_file": "/home/ansible/.ssh/id_rsa",
"ansible_become_pass": null,
"ssl_cert": "/home/ansible/ssl/vm-dcp-hdp-s-2.dcp.local.cer", - путь к сертификату, в формате BASE64
"ssl_key": "/home/ansible/ssl/vm-dcp-hdp-s-2.dcp.local.key" - путь к приватному ключу, в формате BASE64
}
}На форме “Провайдеры→<выбранный провайдер>→<выбранный хост>→ Конфигурация”:
Важно: При необходимости включения SSL необходимо предварительно внести эти параметры (ssl_key/ssl_cert) в обязательные для заполнения.
Важно: Необходимо реализовать из RT.ClusterManager сохранение сертификата и ключа в файлы, для того чтобы исключить необходимость загрузки сертификатов на хостовую машину с RT.ClusterManager из консоли.
¶ 2.2 Дополнительные параметры в файле inventory
Пример с добавленным блоком "pki":
{
"all": {
"children": {
"CLUSTER": {
"hosts": {},
"vars": {
"cluster": {
"id": 1,
"name": "rt-hadoop",
"kerberized": true,
"config": {
"repos": {},
"java": {},
"kerberos": {},
"pki": {
"keystore_pass": "password", - пароль к private/public хранилищам (JKS)
"keystore_path": "/etc/security/serverkeys/keystore.jks", - путь к private хранилищу, которое будет сформировано на управляемых серверах
"truststore_path": "/etc/security/serverkeys/truststore.jks", - путь к public хранилищу, которое будет сформировано на управляемых серверах
"ca_certificate_path": {
"root": "/home/ansible/ssl/root.cer" - путь к сертификату ЦС (центра сертификации), сохранённому на сервере с RT.ClusterManager
}
}
}
}
}
}
}
}
}На форме “Кластеры→<выбранный кластер>→Конфигурация”, вкладка pki:
¶ 2.3 Настройка взаимодействия ролей RT.ClusterManager с LDAPS сервером
Для настройки в ролях, необходимо указать параметры:
"kerberos": {
"ssl": true, - разрешаем ssl
"ldap_cacert_path": "cacert_file_path", - путь к сертификату доверенного центра сертификаций
"ca_trust_dir": "pki_ca-trust_source_anchors", - путь к хранилищу доверенных сертификатов на сервере сервисов (/etc/pki/ca-trust/source/anchors/cacert.pem для centos)
...
}Аналогичные настройки для RT.ClusterManager (“Кластеры→<выбранный кластер>→Конфигурация”, вкладка kerberos):
¶ 2.4 Включение SSL/PKI для каждого из компонентов RT.Datalake (пример: hdfs)
На форме “Кластеры→<выбранный кластер>→<компонент требующий ssl>→Конфигурация”, вкладка ssl, выберите True:
