В этом разделе описывается как настроить безопасное подключение служб и утилит Shardman к хранилищу etcd.
etcd является критически важным компонентом кластера Shardman. Если злоумышленник получит доступ к хранилищу etcd, он получит полный контроль над всем кластером, включая доступ к СУБД с правами администратора. Для защиты кластера рекомендуется настроить проверку подлинности TLS между демонами etcd и службами Shardman.
Для этого можно использовать транспорт HTTPS с сертификатами, подписанными вашим локальным центром сертификации (ЦС), для шифрования трафика между кластером etcd и службами Shardman и ограничения доступа etcd. Для этого выполните действия, описанные в следующих разделах.
Чтобы создать SSL-сертификаты, выполните следующие шаги:
Если ЦС не существует, создайте самоподписанный корневой сертификат. Создавайте все сертификаты на одном доверенном узле. В примере ниже генерируются сертификаты, срок действия которых истекает через 10000 дней (можно выбрать более подходящий интервал):
#openssl genrsa -out rootCA.key 4096#openssl req -x509 -new -key rootCA.key -days 10000 -out rootCA.crt
Подготовьте следующий файл конфигурации openssl для каждого узла etcd:
[ req ] default_bits = 4096 distinguished_name = req_distinguished_name req_extensions = req_ext [ req_distinguished_name ] countryName = Country Name (2 letter code) stateOrProvinceName = State or Province Name (full name) localityName = Locality Name (eg, city) organizationName = Organization Name (eg, company) commonName = Common Name (e.g. server FQDN or YOUR name) [ req_ext ] subjectAltName = @alt_names [alt_names] DNS.1 = n1 IP.1 = 192.168.1.1 IP.2 = 127.0.0.1
В разделе [alt_names] укажите альтернативные имена субъектов для узла etcd. Эти имена должны включать имя узла сервера etcd, IP-адрес и локальный IP-адрес. Указывать локальный IP-адрес необязательно, но может оказаться полезным.
Сохраните файл. Например, имена файлов конфигурации для узлов n1 — n3 могут быть n1.san.conf — n3.san.conf.
Используя подготовленные файлы конфигурации, создайте закрытые ключи и запросы сертификатов для узлов etcd:
#openssl genrsa -out n1.etcd.key 4096#openssl req -config n1.san.conf -new -key n1.etcd.key -out n1.etcd.csr -subj "/C=RU/ST=Moscow Region/L=Moscow/O=Test/CN=n1"
Здесь «/C=RU/ST=Moscow Region/L=Moscow/O=Test/CN=n1» означает, что запрос сертификата создаётся с названием страны RU, регионом Moscow Region, населённым пунктом Moscow, организацией Test и общим именем n1. Общее имя должно совпадать с DNS-именем вашего сервера etcd.
Подпишите запрос сертификации:
#openssl x509 -extfile n1.san.conf -extensions req_ext -req -in n1.etcd.csr -CA rootCA.crt -CAkey rootCA.key -CAcreateserial -out n1.etcd.crt -days 10000
Проверьте сертификаты, чтобы убедиться, что они содержат правильные значения полей X509v3 Subject Alternative Name. Поля должны содержать список DNS-имён и IP-адресов, добавленных в файл конфигурации openssl:
#openssl x509 -in n1.etcd.crt -noout -text
Создайте клиентские сертификаты для служб Shardman и клиентских программ. Эти сертификаты не обязательно должны содержать заголовок subjectAltName, и значение переменной CN не имеет значения в приведённом ниже примере. В данном примере создаётся одна общая пара сертификат-ключ для служб и одна — для инструментов:
#openssl x509 genrsa -out shardman_services.key 4096#openssl req -new -key shardman_services.key -out shardman_services.csr -subj "/C=RU/ST=Moscow Region/L=Moscow/O=Test/CN=shardman_services"#openssl x509 -req -in shardman_services.csr -CA rootCA.crt -CAkey rootCA.key -CAcreateserial -out shardman_services.crt -days 10000#openssl x509 genrsa -out shardman_tools.key 4096#openssl req -new -key shardman_tools.key -out shardman_tools.csr -subj "/C=RU/ST=Moscow Region/L=Moscow/O=Test/CN=shardman_tools"#openssl x509 -req -in shardman_tools.csr -CA rootCA.crt -CAkey rootCA.key -CAcreateserial -out shardman_tools.crt -days 10000
Теперь настройте службы ( etcd и shardmand ) для использования сгенерированных сертификатов. Выполните следующие шаги:
На каждом узле etcd поместите файлы rootCA.crt, nX.etcd.crt и nX.etcd.key в каталог, доступный для демона etcd (например, создайте каталог /etc/etcd и поместите эти файлы в него). Убедитесь, что файл nX.etc.key доступен только пользователю демона etcd.
Укажите следующую конфигурацию для демонов etcd в /etc/default/etc:
# unqualified first name ETCD_NAME=n1 # where we actually listen for peers ETCD_LISTEN_PEER_URLS=https://0.0.0.0:2380 # where we actually listen for clients ETCD_LISTEN_CLIENT_URLS=https://0.0.0.0:2379 # advertise where this machine is listening for clients ETCD_ADVERTISE_CLIENT_URLS=https://n1:2379 # --initial flags are used during bootstrapping and ignored afterwards, so it is # ok to specify them always # advertise where this machine is listening for peer ETCD_INITIAL_ADVERTISE_PEER_URLS=https://n1:2380 ETCD_INITIAL_CLUSTER_TOKEN=etcd-cluster # ansible_nodename is fqdn ETCD_INITIAL_CLUSTER=n1=https://n1:2380,n2=https://n2:2380,n3=https://n3:2380 ETCD_INITIAL_CLUSTER_STATE=new ETCD_DATA_DIR=/var/lib/etcd/default/member ETCD_AUTO_COMPACTION_RETENTION=1 ETCD_KEY_FILE=/etc/etcd/n1.etcd.key ETCD_CERT_FILE=/etc/etcd/n1.etcd.crt ETCD_TRUSTED_CA_FILE=/etc/etcd/rootCA.crt ETCD_CLIENT_CERT_AUTH=true ETCD_PEER_CERT_FILE=/etc/etcd/n1.etcd.crt ETCD_PEER_KEY_FILE=/etc/etcd/n1.etcd.key ETCD_PEER_TRUSTED_CA_FILE=/etc/etcd/rootCA.crt ETCD_PEER_CLIENT_CERT_AUTH=true
Замените n1 на имя соответствующего узла.
Перезапустите службы etcd на всех узлах кластера etcd:
#systemctl restart etcd
Для проверки новой конфигурации используйте следующую команду:
#etcdctl --endpoints=https://n1:2379,https://n2:2379,https://n3:2379 --cacert /etc/etcd/rootCA.crt --cert /etc/etcd/n1.etcd.crt --key /etc/etcd/n1.etcd.key member list -w table+------------------+---------+------+-----------------+-----------------+------------+ | ID | STATUS | NAME | PEER ADDRS | CLIENT ADDRS | IS LEARNER | +------------------+---------+------+-----------------+-----------------+------------+ | 66ebe06d7302c3f0 | started | n2 | https://n2:2380 | https://n2:2379 | false | | b1080bf5ff059980 | started | n1 | https://n1:2380 | https://n1:2379 | false | | d98323257249fefb | started | n3 | https://n3:2380 | https://n3:2379 | false | +------------------+---------+------+-----------------+-----------------+------------+
На каждом узле кластера Shardman поместите файлы rootCA.crt, shardman_services.crt и shardman_services.key в каталог, доступный для пользователя postgres (например, создайте каталог /etc/shardman и поместите эти файлы в него). Убедитесь, что файл shardman_services.key доступен только пользователю postgres.
Отредактируйте файл конфигурации
shardmand
/etc/shardman/shardmand-cluster0.env следующим образом:
SDM_STORE_ENDPOINTS=https://n1:2379,https://n2:2379,https://n3:2379 SDM_STORE_CA_FILE=/etc/shardman/rootCA.crt SDM_STORE_CERT_FILE=/etc/shardman/shardman_services.crt SDM_STORE_KEY=/etc/shardman/shardman_services.key
Перезапустите службы shardmand@cluster0 на всех узлах Shardman:
#systemctl restart shardmand@cluster0
Перед использованием инструментов Shardman скопируйте rootCA.crt, shardman_tools.crt и shardman_tools.key в какое-либо место на узле управления Shardman, где они доступны пользователю управления. Здесь под узлом управления понимается любой узел с установленными утилитами Shardman, который используется для управления кластером Shardman. Это также может быть один из узлов кластера Shardman (или все они). Под управляющим пользователем подразумевается пользователь, запускающий инструмент
shardmanctl
. Предполагается, что сертификаты и ключ находятся в каталоге /etc/shardman.
При использовании инструментов Shardman обязательно добавьте --store-ca-file, --store-cert-file и --store-key для команды shardmanctl. Например, следующая команда получает статус кластера:
#shardmanctl --store-ca-file /etc/shardman/rootCA.crt --store-cert-file /etc/shardman/shardman_tools.crt --store-key /etc/ shardman/shardman_tools.key --store-endpoints https://n1:2379,https://n2:2379,https://n3:2379 status