Безопасность кластера¶

Использование SSL¶

При подключении к Picodata рекомендуется использовать протокол SSL, который обеспечивает безопасную коммуникацию между клиентом (окном терминала или клиентским API) и сервером (инстансом Picodata).

Picodata поддерживает SSL при подключении по протоколу PostgreSQL. Безопасное соединение задействуется автоматически если оно поддерживается (и настроено) на стороне инстанса Picodata.

Примечание

Если в конфигурации инстанса включен параметр instance.pg.ssl, то небезопасные соединения (без SSL) при этом становятся запрещены.

Пример строки подключения с явным запросом безопасного режима:

psql postgres://admin:qazWSX123@192.168.101.166:5001?sslmode=require

См. также:

Режимы sslmode

Настройки при LDAP-аутентификации¶

При использовании аутентификации LDAP рекомендуется включить SSL для того, чтобы пароль пользователя не передавался по сети в открытом виде.

Чтобы настроить использование SSL, выполните следующие шаги:

Задайте в файле конфигурации параметр instance.pg.ssl: true
Добавьте в рабочую директорию инстанса <INSTANCE_DIR> SSL-сертификат и ключ server.crt, server.key
(опционально) Для включения mTLS добавьте в рабочую директорию инстанса <INSTANCE_DIR> SSL-сертификат ca.crt. В результате PostgreSQL-сервер в Picodata будет принимать подключения только в том случае, если клиент предоставит сертификат, подписанный с помощью ca.crt.

Создание сертификатов и ключей¶

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

Шаг 1. Создание директории для сертификатов для пользователя picouser

mkdir -p /home/picouser/certs && cd /home/picouser/certs

Шаг 2. Создание корневого сертификата (CA)

openssl genrsa -out ca.key 2048
openssl req -x509 -new -nodes -key ca.key -sha256 -days 365 -out ca.crt -subj "/CN=RootCA"

Шаг 3. Создание серверного закрытого ключа

openssl genrsa -out server.key 2048

Шаг 4. Создание запроса на подпись серверного сертификата (CSR)

openssl req -new -key server.key -out server.csr -subj "/CN=Server"

Шаг 5. Подпись серверного сертификата с помощью корневого сертификата (CA)

openssl x509 -req -in server.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out server.crt -days 365 -sha256

Шаг 6. Создание клиентского закрытого ключа

openssl genrsa -out client.key 2048

Шаг 7. Создание запроса на подпись клиентского сертификата (CSR)

openssl req -new -key client.key -out client.csr -subj "/CN=Client"

Шаг 8. Подпись клиентского сертификата с помощью корневого сертификата (CA)

 openssl x509 -req -in client.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out client.crt -days 365 -sha256

Шаг 9. Конвертация клиентского ключа в формат PKCS#8

openssl pkcs8 -topk8 -inform PEM -outform DER -in client.key -out client.pk8 -nocrypt

Шаг 10. Установка прав на файлы

chmod 600 ca.key server.key client.key client.pk8

Примечание

Если клиентский ключ планируется использовать от лица текущего пользователя, назначьте права 600 (u=rw), если от root — 640 (u=rw,g=r).

Если требуется использовать хранилище в формате PKCS#12, то следует:

объединить сертификат и ключ клиента в один файл (cat client.key client.crt > store.txt)
конвертировать получившийся файл в формат PKCS#12 (openssl pkcs12 -export -in store.txt -out store.pkcs12 -name myAlias -noiter -nomaciter)

Настройка mTLS для защиты кластера¶

Для защиты коммуникации внутри кластера по протоколу Iproto используйте безопасный режим mutual TLS (mTLS). Он работает следующим образом:

Администратор создает корневой сертификат (CA), набор серверных и клиентских сертификатов и ключей и подписывает их с помощью CA (см. выше).
На стороне сервера (инстанса Picodata) администратор включает режим TLS и предоставляет пути к CA, а также серверному сертификату и закрытому ключу. CA должен быть единым для всех инстансов кластера; содержимое серверных сертификатов и закрытого ключа должно быть уникальным на каждом инстансе.
После запуска инстансов кластера внутренняя коммуникация по протоколу Iproto будет происходить в зашифрованном виде. Администратор может подключиться к любому инстансу кластера, предоставив CA, клиентский сертификат и клиентский закрытый ключ. Если указан флаг --tls-auth, то при успешной проверке сертификатов и ключа на стороне сервера (инстанса), администратор получит доступ к кластеру без пароля и соответствующей ему проверки аутентификации (md5, chap-sha1, ldap). Подключение возможно в командной строке с помощью команд picodata status, picodata expel и picodata plugin configure.