centos7, centos8, mysql

Управление динамическими учетными записями в PostgreSQL через Hashicorp Vault

Thank you for reading this post, don't forget to subscribe!

В инструк­ции рас­смот­рим про­цесс хра­не­ния учет­ной запи­си PostgreSQL в хра­ни­ли­ще сек­ре­тов Hashicorp Vault, исполь­зуя меха­низм database, с воз­мож­но­стью авто­ма­ти­че­ской сме­ны сек­ре­та в СУБД при его смене в Vault. Так­же мы настро­им Vault для созда­ния вре­мен­ных учет­ных запи­сей в PostgreSQL.

Уста­нов­ка и запуск PostgreSQL
уда­лен­ное под­клю­че­ние к PostgreSQL
рабо­та с поль­зо­ва­те­ля­ми в PostgreSQL
Настрой­ка прав досту­па к базе с помо­щью групп
Редак­ти­ро­ва­ние пользователя
Назна­че­ние осо­бых прав поль­зо­ва­те­лям PostgreSQL
Уста­нов­ка, настрой­ка и рабо­та с Hashicorp Vault
Управ­ле­ние дина­ми­че­ски­ми учет­ны­ми запи­ся­ми в PostgreSQL через Hashicorp Vault

Установка и запуск PostgreSQL

PostgreSQL 9/10

В зави­си­мо­сти от вер­сии опе­ра­ци­он­ной систе­мы, из короб­ки будет уста­нов­ле­на вер­сия 9.2 (CentOS 7) или 10 (CentOS 8).

Про­сто вво­дим команду:

yum install postgresql-server

PostgreSQL > 9.2

Для уста­нов­ки более све­жей вер­сии PostgreSQL на CentOS необ­хо­ди­мо под­клю­чить репозиторий:

yum install https://download.postgresql.org/pub/repos/yum/reporpms/EL-`rpm -E %{rhel}`-x86_64/pgdg-redhat-repo-latest.noarch.rpm

Уста­нов­ка PostgreSQL в CentOS 8 осу­ществ­ле­на через модуль­ные репо­зи­то­рии, что поме­ша­ет нам — отклю­ча­ем их командой:

dnf module disable postgresql

И чистим кэш:

dnf clean all

После чего обнов­ля­ем спи­сок пакетов:

yum makecache -y

Уста­нав­ли­ва­ем postgres:

yum install postgresql11-server

* в дан­ном при­ме­ре будет уста­нов­лен postgresql вер­сии 11.
** систе­ма про­ве­рит репо­зи­то­рий на нали­чие нуж­но­го паке­та и задаст запрос на под­твер­жде­ние уста­нов­ки про­грам­мы — отве­ча­ем Y.

Запуск

После уста­нов­ки СУБД необходимо:

  1. Ини­ци­а­ли­зи­ро­вать базу. Это дела­ет­ся с помо­щью ути­ли­ты postgresql-setup с клю­чом initdb.
  2. Раз­ре­шить авто­за­пуск сервиса.
  3. Стар­то­вать службу.

В зави­си­мо­сти от вер­сии postgresql, эти опе­ра­ции выпол­ня­ют­ся, немно­го, по-разному.

PostgreSQL (базовый репозиторий)

Ини­ци­а­ли­за­ция базы:

postgresql-setup initdb

Запуск сер­ви­са:

systemctl enable postgresql --now

PostgreSQL (другая версия — на примере 11)

Ини­ци­а­ли­за­ция базы (син­так­сис):

/usr/pgsql-<версия>/bin/postgresql-<версия>-setup initdb

Напри­мер:

/usr/pgsql-11/bin/postgresql-11-setup initdb

Раз­ре­ша­ем запуск сер­ви­са и стар­ту­ем его:

systemctl enable postgresql-11 --now

Тестовое подключение

Зада­ем пароль для поль­зо­ва­те­ля postgres:

passwd postgres

Захо­дим в систе­му под дан­ной учет­ной записью:

su - postgres

Под­клю­ча­ем­ся к базе:

psql

Дела­ем тесто­вый запрос на полу­че­ние спис­ка таблиц:

=# \dt *

Выхо­дим из обо­лоч­ки psql:

=# \q

Отклю­ча­ем­ся от систе­мы поль­зо­ва­те­лем postgres:

exit

Настрой­ка завер­ше­на. Сле­ду­ю­щим шагом настра­и­ва­ем под­клю­че­ние к PostgreSQL и созда­ем пользователя.

 

Удаленное подключение к PostgreSQL

По умол­ча­нию, сер­вер баз дан­ных pgsql раз­ре­ша­ет под­клю­че­ние толь­ко с локаль­но­го ком­пью­те­ра. Дан­ная инструк­ция пока­зы­ва­ет, как раз­ре­шить под­клю­че­ния с уда­лен­ных систем

Для нача­ла посмот­рим путь рас­по­ло­же­ния кон­фи­гу­ра­ци­он­но­го фай­ла postgresql.conf:

# su - postgres -c "psql -c 'SHOW config_file;'"

Коман­да выдаст, при­мер­но, следующее:

-----------------------------------------
/db/pgsql/postgresql.conf
(1 row)

* нас инте­ре­су­ет строч­ка /db/pgsql/postgresql.conf — это путь рас­по­ло­же­ния нуж­но­го нам кон­фи­гу­ра­ци­он­но­го файла.

Теперь откры­ва­ем на редак­ти­ро­ва­ние основ­ной файл кон­фи­гу­ра­ции PostgreSQL:

# vi /db/pgsql/postgresql.conf

* напо­ми­наю, что нача­ло пути /db/pgsql может быть дру­гим. Мы его полу­чи­ли коман­дой ps.

Нахо­дим и редак­ти­ру­ем следующее:

listen_addresses = '*'

* по умол­ча­нию, пара­метр заком­мен­ти­ро­ван и настро­ен на про­слу­ши­ва­ние запро­сов толь­ко с локаль­но­го сете­во­го интер­фей­са. В дан­ном при­ме­ре мы раз­ре­ши­ли про­слу­ши­ва­ние запро­сов на всех IP-адре­сах (*), но, если тре­бу­ет­ся более без­опас­ная настрой­ка, мож­но про­сто пере­чис­лить послед­ние через пробел.

После откры­ва­ем на редак­ти­ро­ва­ние сле­ду­ю­щий кон­фи­гу­ра­ци­он­ный файл:

# vi /db/pgsql/pg_hba.conf

и вни­зу добав­ля­ем сле­ду­ю­щую строку:

host     all     all     192.168.0.10/32     password

* в дан­ном при­ме­ре мы раз­ре­ша­ем уда­лен­ные под­клю­че­ния к сер­ве­ру с ком­пью­те­ра 192.168.0.10. Доступ предо­став­ля­ет­ся всем учет­ным запи­сям и всем базам (зна­че­ние all). При жела­нии, вме­сто all мож­но ука­зать кон­крет­ные дан­ные для повы­ше­ния безопасности.

Что­бы изме­не­ния всту­пи­ли в силу, пере­за­пус­ка­ем служ­бу postgresql:

# systemctl restart postgresql-9.5

Про­ве­рить под­клю­че­ние мож­но с уда­лен­но­го ком­пью­те­ра сле­ду­ю­щей командой:

# psql -h 192.168.0.15 -U usersql

* где  192.168.0.15 — IP-адрес сер­ве­ра баз дан­ных; usersql — имя учет­ной запи­си, от кото­рой идет подключение.

 

работа с пользователями в PostgreSQL

Часть ниже­опи­сан­ных опе­ра­ций нуж­но выпол­нять в команд­ной обо­лоч­ке PostgreSQL. Она может быть запу­ще­на от поль­зо­ва­те­ля postgres — что­бы вой­ти в систе­му от дан­но­го поль­зо­ва­те­ля, вводим:

su - postgres

* если систе­ма выдаст ошиб­ку, свя­зан­ную с нехват­кой прав, сна­ча­ла повы­ша­ем при­ви­ле­гии коман­дой sudo su или su.

Теперь запус­ка­ем команд­ную обо­лоч­ку PostgreSQL:

$ psql -Upostgres template1

* в дан­ном при­ме­ре, вход выпол­ня­ет­ся от учет­ной запи­си postgres к шаб­лон­ной базе template1.

Для про­смот­ра всех поль­зо­ва­те­лей СУБД:

=# select * from pg_user;

Создание нового пользователя

Для того, что­бы была воз­мож­ность под­клю­че­ния к СУБД PostgreSQL от ново­го поль­зо­ва­те­ля, необ­хо­ди­мо создать дан­но­го поль­зо­ва­те­ля, назна­чить ему пра­ва, выпол­нить настрой­ку фай­ла pg_hba.conf.

1. Создание пользователя

а) Добав­ле­ние новой роли (поль­зо­ва­те­ля) из обо­лоч­ки SQL:

=# CREATE USER user1 WITH PASSWORD 'myPassword';

* в при­ме­ре созда­на роль user1 с паро­лем myPassword.

б) Добав­ле­ние новой роли (поль­зо­ва­те­ля) из команд­ной стро­ки Linux:

createuser -P user1

2. Назначение прав на использование базы данных

Даем пра­ва на базу командой:

=# GRANT ALL PRIVILEGES ON DATABASE "database1" to user1;

Теперь под­клю­ча­ем­ся к базе, к кото­рой хотим дать доступ:

=# \c database1

* в при­ме­ре под­со­еди­ним­ся к базе с назва­ни­ем database1.

а) Так мы доба­вим все пра­ва на исполь­зо­ва­ние всех таб­лиц в базе database1 учет­ной запи­си user1:

database1=# GRANT ALL PRIVILEGES ON ALL TABLES IN SCHEMA public TO "user1";

* в боль­шин­стве слу­ча­ев, исполь­зу­ет­ся схе­ма по умол­ча­нию public. Но адми­ни­стра­тор может создать новую схе­му. Это нуж­но учи­ты­вать при назна­че­нии прав.

б) Так­же мож­но дать доступ к базе для опре­де­лен­ных таблиц:

database1=# GRANT ALL PRIVILEGES ON TABLE table1 IN SCHEMA public TO "user1";

* в дан­ном при­ме­ре мы даем пра­ва на таб­ли­цу table1.

Выхо­дим из SQL-оболочки:

database1=# \q

3. Настройка файла pg_hba.conf

Для воз­мож­но­сти под­клю­чить­ся к СУБД от создан­но­го поль­зо­ва­те­ля, необ­хо­ди­мо про­ве­рить настрой­ки прав в кон­фи­гу­ра­ци­он­ном фай­ле pg_hba.conf.

Для нача­ла смот­рим путь рас­по­ло­же­ния дан­ных для PostgreSQL:

=# SHOW config_file;

В ответ мы полу­чим, что-то на подобие:

-----------------------------------------
/var/lib/pgsql/9.6/data/postgresql.conf
(1 row)

* в дан­ном при­ме­ре /var/lib/pgsql/9.6/data/ — путь рас­по­ло­же­ния кон­фи­гу­ра­ци­он­ных файлов.

Откры­ва­ем pg_hba.conf:

vi /var/lib/pgsql/9.6/data/pg_hba.conf

Добав­ля­ем пра­ва на под­клю­че­ние наше­му создан­но­му пользователю:

…
# IPv4 local connections:
host    all             user1           127.0.0.1/32            md5
…

* в дан­ном при­ме­ре мы раз­ре­ши­ли под­клю­чать­ся поль­зо­ва­те­лю user1 ко всем базам на сер­ве­ре (all) от узла 127.0.0.1 (localhost) с тре­бо­ва­ни­ем паро­ля (md5).
* необ­хо­ди­мо, что­бы дан­ная стро­ка была выше стро­ки, кото­рая про­пи­са­на по умолчанию
host    all             all             127.0.0.1/32            ident.

После пере­за­пус­ка­ем службу:

systemctl restart postgresql-9.6

* в дан­ном при­ме­ре уста­нов­лен postgresql вер­сии 9.6, для раз­ных вер­сий на раз­ных опе­ра­ци­он­ных систе­мах коман­ды для пере­за­пус­ка сер­ви­са могут быть разные.

4. Проверка

Для теста про­бу­ем под­клю­чить­ся к Postgre с помо­щью создан­но­го пользователя:

psql -Uuser template1 -h127.0.0.1

Настройка прав доступа к базе с помощью групп

Сна­ча­ла созда­дим груп­по­вую роль:

=# CREATE ROLE "myRole" NOSUPERUSER INHERIT NOCREATEDB NOCREATEROLE NOREPLICATION;

* дан­ной коман­дой созда­на груп­па myRole с мини­маль­ны­ми правами.

Теперь доба­вим ранее создан­но­го поль­зо­ва­те­ля user1 в эту группу:

=# GRANT "myRole" TO user1;

Под­клю­чим­ся к базе дан­ных, для кото­рой хотим настро­ить права

=# \c database1

и предо­ста­вим все пра­ва для груп­пы myRole всем таб­ли­цам базы database1

database1=# GRANT ALL PRIVILEGES ON ALL TABLES IN SCHEMA public TO GROUP "myRole";

Редактирование пользователя

1. Смена пароля

Рас­смот­рим несколь­ко при­ме­ров сме­ны паро­ля пользователя.

Одной коман­дой:

=# ALTER USER postgres PASSWORD 'password'

* в дан­ном при­ме­ре мы зада­дим пароль password для поль­зо­ва­те­ля postgres.

С запро­сов вво­да пароля:

=# \password postgres

* после вво­да дан­ной коман­ды систе­ма потре­бу­ет два­жды вве­сти пароль для поль­зо­ва­те­ля (в нашем при­ме­ре, postgres).

Из команд­ной стро­ки Linux:

sudo -u postgres psql -U postgres -d postgres -c "ALTER USER postgres PASSWORD 'password'"

* по сути, мы выпол­ня­ем так­же запрос в обо­лоч­ке sql.

Удаление пользователей и групп

Уда­ле­ние поль­зо­ва­те­ля выпол­ня­ет­ся сле­ду­ю­щей командой:

=# DROP USER user;

Забрать пра­ва:

database1=# REVOKE ALL PRIVILEGES ON ALL TABLES IN SCHEMA public FROM "user";

* обра­ти­те вни­ма­ние, дан­ный запрос отли­ча­ет­ся от предо­став­ле­ния прав дву­мя момен­та­ми: 1) вме­сто GRANT пишем REVOKE; 2) вме­сто TO "user" пишем FROM "user";

Назначение особых прав пользователям PostgreSQL

Поми­мо ALL PRIVILEGES мож­но выда­вать пра­ва на осо­бые опе­ра­ции, например:

=# GRANT SELECT, UPDATE, INSERT ON ALL TABLES IN SCHEMA public TO "user1";

* коман­да поз­во­лит выдать пра­ва на полу­че­ние дан­ных, их обнов­ле­ние и добав­ле­ние. Дру­гие опе­ра­ции, напри­мер, уда­ле­ние будут запре­ще­ны для поль­зо­ва­те­ля user1.

Назна­че­ние прав для опре­де­лен­ной таблицы:

database1=# GRANT ALL PRIVILEGES ON table_users TO "user1";

* в дан­ном при­ме­ре мы предо­ста­вим все пра­ва на таб­ли­цу table_users в базе дан­ных database1;

Учетная запись для резервного копирования

Для выпол­не­ния резерв­но­го копи­ро­ва­ния луч­ше все­го под­клю­чать­ся к базе с мини­маль­ны­ми привилегиями.

Сна­ча­ла созда­ем роль, кото­рую будем исполь­зо­вать для выпол­не­ния резерв­но­го копирования:

=# CREATE USER bkpuser WITH PASSWORD 'bkppasswd';

* мы созда­дим учет­ную запись bkpuser с паро­лем bkppasswd.

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

=# GRANT CONNECT ON DATABASE database TO bkpuser;

* в дан­ном при­ме­ре к базе database.

Под­клю­ча­ем­ся к базе (в нашем при­ме­ре database):

=# \c database

Даем пра­ва на все после­до­ва­тель­но­сти в схеме:

=# GRANT SELECT ON ALL SEQUENCES IN SCHEMA public TO bkpuser;

* мы дали пра­ва для схе­мы public. Это схе­ма явля­ет­ся схе­мой по умол­ча­нию, но в вашем слу­чае она может быть дру­гой. В таком слу­чае, под­став­ля­ем свое значение.

Графический интерфейс

Ино­гда про­ще вос­поль­зо­вать­ся про­грам­мой для выстав­ле­ния прав и рабо­ты с PostgreSQL. Могу посо­ве­то­вать при­ло­же­ние pgAdmin. Оно поз­во­лит в окон­ном режи­ме не толь­ко создать и уда­лить поль­зо­ва­те­лей, но и пол­но­цен­но рабо­тать с СУБД.

 

Удаление

Для уда­ле­ния доста­точ­но вве­сти сле­ду­ю­щую команду.

PostgreSQL (базо­вый репозиторий)

yum remove postgresql-server

PostgreSQL (дру­гая вер­сия — на при­ме­ре 11)

yum remove postgresql11-server

Установка, настройка и работа с Hashicorp Vault

В дан­ной инструк­ции попро­бу­ем охва­тить как мож­но боль­ше при­ме­ров рабо­ты с Hashicorp Vault. Мы выпол­ним уста­нов­ку на систе­мы Linux, насто­им сер­вер, сохра­ним несколь­ко сек­ре­тов и попро­бу­ем полу­чить доступ к дан­ным сек­ре­там из раз­лич­ных систем. В каче­стве Linux рас­смот­рим Debian и CentOS 7 и 8.

Установка пакетов

Нам пона­до­бят­ся неко­то­рые ути­ли­ты. Коман­ды для их уста­нов­ки зави­сят от исполь­зу­е­мой системы.

а) Debian:

apt-get install wget chrony curl apt-transport-https

б) CentOS:

yum install wget chrony curl

* где:

  • wget — ути­ли­та для загруз­ки файлов.
  • chrony — сер­вис для син­хро­ни­за­ции времени.
  • curl — ути­ли­та для отправ­ки POST и GET запро­сов на веб-сервер.
  • apt-transport-https — допол­не­ние для воз­мож­но­сти исполь­зо­вать репо­зи­то­рии по https.

Настройка времени

Для кор­рект­но­го полу­че­ния токе­нов необ­хо­ди­мо, что­бы вре­мя на сер­ве­ре было пра­виль­ное. Зада­ем необ­хо­ди­мый нам часо­вой пояс:

timedatectl set-timezone Europe/Moscow

* пол­ный пере­чень вари­ан­тов мож­но посмот­реть коман­дой timedatectl list-timezones.

Если у нас в сети есть свой сер­вер син­хро­ни­за­ции вре­ме­ни, откры­ва­ем на редак­ти­ро­ва­ние файл настрой­ки chrony.

а) Debian:

vi /etc/chrony/chrony.conf

б) CentOS:

vi /etc/chrony.conf

Нам нуж­но поме­нять источ­ник, с кото­рым мы будем син­хро­ни­зи­ро­вать наше вре­мя. Дан­ная опция отли­ча­ет­ся в зави­си­мо­сти от вер­сии систе­мы или дистрибутива.

а) в Debian или CentOS 8:

pool user1.local
#pool …

* в нашем при­ме­ре мы ком­мен­ти­ру­ем тот адрес pool, кото­рый был в кон­фи­гу­ра­ции и под­став­ля­ем адрес наше­го сер­ве­ра user1.local.

а) в CentOS 7:

server user1.local
#server 0.centos.pool.ntp.org iburst
#server 1.centos.pool.ntp.org iburst
#server 2.centos.pool.ntp.org iburst
#server 3.centos.pool.ntp.org iburst

* в нашем при­ме­ре мы ком­мен­ти­ру­ем адре­са server, кото­рые были в кон­фи­гу­ра­ции и под­став­ля­ем адрес наше­го сер­ве­ра user1.local.

Раз­ре­ша­ем авто­ма­ти­че­ский запуск для сер­ви­са син­хро­ни­за­ции вре­ме­ни и пере­за­пус­ка­ем его.

а) для Debian:

systemctl enable chrony

systemctl restart chrony

б) для CentOS:

systemctl enable chronyd

systemctl restart chronyd

Настройка брандмауэра

Для кор­рект­ной рабо­ты сер­ви­са нам необ­хо­ди­мо открыть порт 8200. В зави­си­мо­сти от исполь­зу­е­мой ути­ли­ты управ­ле­ния netfilter мы долж­ны при­ме­нять раз­ные инструменты.

а) Iptables (как пра­ви­ло, Debian):

iptables -I INPUT -p tcp --dport 8200 -j ACCEPT

Для сохра­не­ния пра­ви­ла мож­но вос­поль­зо­вать­ся ути­ли­той iptables-persistent:

apt-get install iptables-persistent

netfilter-persistent save

б) Firewalld (как пра­ви­ло, для CentOS):

firewall-cmd --permanent --add-port=8200/tcp

firewall-cmd --reload

Установка и запуск

Про­грамм­ный про­дукт под­дер­жи­ва­ет раз­лич­ные вари­ан­ты уста­нов­ки. Мы рас­смот­рим уста­нов­ку из репозитория.

Под­клю­ча­ем офи­ци­аль­ный репо­зи­то­рий и уста­нав­ли­ва­ем пакет vault.

а) Debian:

curl -fsSL https://apt.releases.hashicorp.com/gpg | sudo apt-key add -

echo "deb [arch=amd64] https://apt.releases.hashicorp.com $(lsb_release -cs) main" > /etc/apt/sources.list.d/hashicorp.list

apt-get update

apt-get install vault

б) CentOS:

wget https://rpm.releases.hashicorp.com/RHEL/hashicorp.repo -O /etc/yum.repos.d/hashicorp.repo

yum install vault

Раз­ре­ша­ем авто­за­пуск служ­бы и если она не запу­ще­на, стар­ту­ем ее:

systemctl enable vault --now

Уста­нов­ка выпол­не­на. При попыт­ке зай­ти по адре­су https://<IP-адрес сер­ве­ра Vault>:8200/ мы долж­ны уви­деть стра­ни­цу началь­ной настрой­ки мастер-ключей.

Идем даль­ше.

Настройка рабочего окружения

При попыт­ке выпол­нить любую опе­ра­цию в команд­ной стро­ке, мы полу­чим ошибку:

Error checking seal status: Get "https://127.0.0.1:8200/v1/sys/seal-status": x509: cannot validate certificate for 127.0.0.1 because it doesn't contain any IP SANs

Это зна­чит, что мы пыта­ем­ся под­клю­чить­ся к наше­му сер­ве­ру по https с непра­виль­ным сер­ти­фи­ка­том. На эта­пе пер­вич­ной настрой­ки не хочет­ся зани­мать­ся полу­че­ни­ем и настрой­кой валид­но­го сер­ти­фи­ка­та. В офи­ци­аль­ной доку­мен­та­ции ска­за­но, что нуж­но вве­сти команду:

export VAULT_ADDR=http://127.0.0.1:8200

Она ука­жет теку­ще­му окру­же­нию под­клю­чать­ся к сер­ве­ру по http. Одна­ко, это при­ве­дет к дру­гой ошибке:

Error checking seal status: Error making API request.

URL: GET http://127.0.0.1:8200/v1/sys/seal-status
Code: 400. Raw Message:

Client sent an HTTP request to an HTTPS server.

Она гово­рит, что мы под­клю­ча­ем­ся к сер­ве­ру по неза­щи­щен­но­му кана­лу, когда сер­вер тре­бу­ет без­опас­но­го соединения.

Для реше­ния про­бле­мы откры­ва­ем файл:

vi /etc/vault.d/vault.hcl

И сни­ма­ем ком­мен­та­рии со сле­ду­ю­щих строк, а так­же меня­ем зна­че­ние для поля address:

* так как для https уже исполь­зу­ет­ся порт 8200, мы долж­ны поме­нять пред­ло­жен­ный по умол­ча­нию вари­ант на свой, что­бы не воз­ни­ка­ло кон­флик­тов при запус­ке сервиса.

Пере­за­пус­ка­ем служ­бу vault:

systemctl restart vault

Обнов­ля­ем систем­ную пере­мен­ную VAULT_ADDR:

export VAULT_ADDR=http://127.0.0.1:8201

* обра­ти­те вни­ма­ние, что мы поме­ня­ли порт под­клю­че­ния на 8201.

Про­бу­ем выве­сти на экран статус:

vault status

Мы долж­ны полу­чить что-то на подобие:

Что­бы дан­ная систем­ная пере­мен­ная созда­ва­лась каж­дый раз при вхо­де поль­зо­ва­те­ля в систе­му, откры­ва­ем файл:

vi /etc/environment

И добав­ля­ем:

VAULT_ADDR=http://127.0.0.1:8201

Распечатывание

После уста­нов­ки, сер­вер Vault нахо­дит­ся в запе­ча­тан­ном (sealed) состо­я­нии. То есть, он не зна­ет, как ему рас­шиф­ро­вы­вать сек­ре­ты, кото­рые будут хра­нить­ся в базе.

При попыт­ке выпол­нить любую опе­ра­цию с хра­ни­ли­щем сек­ре­тов мы полу­чим ошибку:

* Vault is sealed

Что­бы испра­вить ситу­а­цию, нуж­но выпол­нить ини­ци­а­ли­за­цию сер­ве­ра — мы полу­чим клю­чи для рас­пе­ча­ты­ва­ния (Unseal Keys). После необ­хо­ди­мо вве­сти эти клю­чи и мож­но будет авто­ри­зо­вать­ся в системе.

Инициализация, распечатывание и вход

Для нача­ла, нам необ­хо­ди­мо ини­ци­а­ли­зи­ро­вать наш сер­вер. Это выпол­ня­ет­ся командой:

vault operator init

Коман­да нам вер­нет 5 клю­чей. Любые 3 из них явля­ют­ся клю­ча­ми для рас­пе­ча­ты­ва­ния сер­ве­ра (Unseal Key). Так­же нам будет предо­став­лен токен для root (Initial Root Token), с помо­щью кото­ро­го мож­но будет вой­ти в систе­му vault.

И так, рас­пе­ча­та­ем наш сер­вер, вве­дя по оче­ре­ди 3 команды.

Для пер­во­го ключа:

vault operator unseal

Для вто­ро­го:

vault operator unseal

И тре­тье­го:

vault operator unseal

После выпол­не­ния каж­дой коман­ды систе­ма будет запра­ши­вать ключ. Необ­хо­ди­мо вве­сти любые 3 из сге­не­ри­ро­ван­ных ранее. При пра­виль­ном вво­де клю­ча, мы будем видеть общую инфор­ма­цию по клю­чу. А при вво­де тре­тье­го клю­ча мы долж­ны увидеть:

Sealed          false

Это зна­чит, что сер­вер боль­ше не запе­ча­тан и с ним мож­но работать.

Теперь необ­хо­ди­мо зало­ги­нить­ся в систе­му командой:

vault login

… и вве­сти ключ root, кото­рый мы полу­чи­ли после инициализации.

Мы можем выпол­нять коман­ды для рабо­ты с Hashicorp Vault.

Автоматическое распечатывание

После пере­за­груз­ки наше­го сер­ве­ра он опять ста­но­вит­ся запе­ча­тан­ным. Пред­по­ла­га­ет­ся, что полу­чен­ных 5 клю­чей необ­хо­ди­мо выдать пяти ответ­ствен­ным за без­опас­ность сотруд­ни­кам. После пере­за­груз­ки, трое из них долж­ны будут вве­сти свои дан­ные. Это пра­виль­но с точ­ки зре­ния безопасности.

Одна­ко, если у нас есть при­чи­ны авто­ма­ти­че­ски под­ни­мать сер­вер после пере­за­груз­ки, рас­смот­рим, как это сделать.

Дан­ный спо­соб про­ти­во­ре­чит без­опас­но­сти, одна­ко, реаль­ная экс­плу­а­та­ция систем не все­гда впи­сы­ва­ет­ся в рам­ки иде­аль­ных концепций.

Выпол­ним настрой­ку в несколь­ко шагов.

1. Скрипт.

Созда­дим ката­лог для хра­не­ния скриптов:

mkdir /scripts

Созда­дим скрипт:

vi /scripts/unseal.sh

* где w1SgHSWyXm+7kwmYk4bFX2rBLG5jKxIn01DMkj57071D, 38s4+FkxKTTANFZgCwEPFOgJIMwTvLca1j36yYPc3gdx и 4xlpKVwPuNlskydM/qmCmW22x7WZdfuiFu92HGRNOa8o — любых 3 токе­на (из 5 сге­не­ри­ро­ван­ных). Обра­ти­те вни­ма­ние, мы задер­жи­ва­ем выпол­не­ние скрип­та на 10 секунд — на прак­ти­ке, сер­вис vault может не успеть запу­стить­ся, и мы тогда полу­чим ошиб­ку при выпол­не­нии коман­ды vault operator unseal.

Раз­ре­ша­ем запуск скрип­та на выполнение:

chmod +x /scripts/unseal.sh

Мож­но, даже, выпол­нить скрипт:

/scripts/unseal.sh

В ито­ге, мы рас­пе­ча­та­ем наш сервер.

2. Авто­за­пуск скрип­та при стар­те системы:

Боль­шин­ство совре­мен­ных сер­вер­ных систем рабо­та­ет на осно­ве systemd. Рас­смот­рим авто­за­пуск с помо­щью последней.

Созда­ем юнит:

vi /etc/systemd/system/vault-unseal.service

* в дан­ном при­ме­ре мы выпол­ня­ем одну коман­ду при запус­ке сер­ви­са — запуск скрип­та /scripts/unseal.sh. Перед этим мы созда­ем систем­ную пере­мен­ную VAULT_ADDR, что­бы при выпол­не­нии команд в скрип­те систе­ма пони­ма­ла, к како­му сер­ве­ру подключаться.

Пере­чи­та­ем кон­фи­гу­ра­цию для systemd:

systemctl daemon-reload

Раз­ре­ша­ем авто­за­пуск создан­но­го сервиса:

systemctl enable vault-unseal

Про­бу­ем пере­за­гру­зить сер­вер — vault дол­жен ока­зать­ся распечатанным.

Работа с секретами

Наша систе­ма пол­но­стью гото­ва, что­бы ей пользоваться.

Для нача­ла дадим раз­ре­ше­ние на хра­не­ние сек­ре­тов по пути secret:

vault secrets enable -path=secret/ kv

Мы долж­ны полу­чить ответ:

Success! Enabled the kv secrets engine at: secret/

Теперь выпол­ним про­стую опе­ра­цию по созда­нию сек­ре­та. Вве­дем коман­ду, пред­ло­жен­ную на офи­ци­аль­ном сай­те разработчика:

vault kv put secret/hello foo=world

* коман­да kv вза­и­мо­дей­ству­ет с хра­ни­ли­щем Vault. В дан­ном при­ме­ре мы добав­ля­ем пару ключ-зна­че­ние, соот­вет­ствен­но foo-world.

Мы долж­ны полу­чить ответ:

Success! Data written to: secret/hello

Посмот­реть содер­жи­мое мож­но командой:

vault kv get secret/hello

На что мы получим:

===== Data =====
Key Value
--- -----
foo world

Так­же мож­но вне­сти за раз мно­же­ство значений:

vault kv put secret/hello foo=world excited=yes

Посмот­реть спи­сок создан­ных сек­ре­тов мож­но командой:

vault kv list secret

Теперь уда­лим сек­рет командой:

vault kv delete secret/hello

Пол­ный пере­чень команд мож­но уви­деть так:

vault -help

После чего мож­но будет полу­чить помощь по кон­крет­ной коман­де vault, например:

vault kv -help

Дан­ной инфор­ма­ции доста­точ­но, что­бы позна­ко­мить­ся с про­дук­том. Пой­дем дальше.

Версионность и метаданные

Hashicorp Vault под­дер­жи­ва­ет вер­си­он­ность дан­ных, то есть, мы можем посмот­реть опре­де­лен­ную вер­сию дан­ных внут­ри сек­ре­та. Одна­ко, по умол­ча­нию, сер­вис уста­нав­ли­ва­ет­ся с kv вер­сии 1, кото­рая не под­дер­жи­ва­ет дан­ной опе­ра­ции. При попыт­ке выпол­нить любую коман­ду, захва­ты­ва­ю­щую вер­си­он­ность, мы полу­чим ошибку:

Metadata not supported on KV Version 1

Для реше­ния необ­хо­ди­мо созда­ние меха­низ­ма kv с под­держ­кой вер­сии 2. Это дела­ет­ся командой:

vault secrets enable -version=2 kv

Или для ранее создан­но­го пути вклю­ча­ем веде­ние вер­си­он­но­сти командой:

vault kv enable-versioning secret/

Теперь зане­сем 2 раза данные:

vault kv put secret/hello foo=world

vault kv put secret/hello foo=world2

Посмот­реть дан­ные опре­де­лен­ной вер­сии мож­но командой:

vault kv get -version=1 secret/hello

В нашем при­ме­ре мы увидим:

=== Data ===
Key Value
--- -----
foo world

* то есть зна­че­ние, кото­рое вво­ди­лось пер­вой командой.

Посмот­реть мета­дан­ные сек­ре­та мож­но командой:

vault kv metadata get secret/hello

Для уда­ле­ния опре­де­лен­ной вер­сии сек­ре­та вводим:

vault kv destroy -versions=1 secret/hello

Динамические секреты

Мы можем настро­ить авто­ма­ти­че­ское созда­ние вре­мен­ных поль­зо­ва­те­лей в раз­лич­ных систе­мах. Это удоб­но для авто­ма­ти­че­ско­го назна­че­ния прав при­ло­же­нию. При этом, через неко­то­рое вре­мя пароль уже не будет дей­ство­вать, что повы­ша­ет без­опас­ность системы.

Рас­смот­рим при­мер настрой­ки дина­ми­че­ских сек­ре­тов для базы дан­ных MariaDB/MySQL.

Пер­вым делом, созда­дим поль­зо­ва­те­ля в СУБД с пра­ва­ми созда­вать дру­гих поль­зо­ва­те­лей. Под­клю­ча­ем­ся к базе данных:

mysql -uroot -p

Созда­ем учет­ную запись, под кото­рой будет под­клю­чать­ся vault к СУБД:

> CREATE USER 'vaultuser'@'localhost' IDENTIFIED BY 'vaultpass';

Дадим пра­ва создан­ной учет­ной запи­си созда­вать дру­гих поль­зо­ва­те­лей и назна­чать им права:

> GRANT CREATE USER ON *.* TO 'vaultuser'@'localhost' WITH GRANT OPTION;

Выхо­дим из обо­лоч­ки SQL:

> exit;

Теперь раз­ре­ша­ем меха­низм сек­ре­тов базы дан­ных (database secrets engine):

vault secrets enable database

Мы долж­ны увидеть:

Success! Enabled the database secrets engine at: database/

* так­же мы можем полу­чить ошиб­ку path is already in use at database/, если дан­ный меха­низм уже раз­ре­шен в нашей системе.

Созда­дим настрой­ку для под­клю­че­ния к нашей базе:

* пред­по­ла­га­ет­ся, что:

  • test — имя базы, для кото­рой vault смо­жет создать вре­мен­ную учет­ную запись.
  • plugin_name — имя пла­ги­на для созда­ния учет­ной запи­си. Важ­ный пара­метр, кото­рый дол­жен пра­виль­но быть подо­бран в зави­си­мо­сти от вер­сии СУБД. Ниже будет ком­мен­та­рий, с какой ошиб­кой мы можем столк­нуть­ся, выбрав непра­виль­ный плагин.
  • test-role — роль, кото­рая будет исполь­зо­вать­ся vault (ее созда­дим ниже).
  • vaultuser — поль­зо­ва­тель, под кото­рым мы под­клю­ча­ем­ся к СУБД (созда­ли выше).
  • vaultpass — пароль, с кото­рым мы под­клю­ча­ем­ся к сер­ве­ру баз данных.

Созда­дим роль, по сути, зада­дим коман­ду для созда­ния вре­мен­ной учет­ной записи:

* где:

  • db_name — имя базы дан­ных, для кото­рой мы будем созда­вать пользователя.
  • creation_statements — коман­ды SQL для созда­ния ново­го поль­зо­ва­те­ля. {{name}} и {{password}} явля­ют­ся спе­ци­аль­ны­ми пере­мен­ны­ми, вме­сто кото­рых vault под­ста­вит сге­не­ри­ро­ван­ные зна­че­ния. Обра­ти­те вни­ма­ние, что в дан­ном при­ме­ре созда­ет­ся поль­зо­ва­тель с пра­ва­ми под­клю­че­ния с любо­го хоста, одна­ко, в зави­си­мо­сти от вер­сии MariaDB, имен­но с локаль­но­го хоста под­клю­чить­ся под дан­ным поль­зо­ва­те­лем будет нель­зя. При такое необ­хо­ди­мо­сти, меня­ем % на localhost.
  • default_ttl — вре­мя, в тече­ние кото­ро­го будет дей­ство­вать пароль.
  • max_ttl — вре­мя, в тече­ние кото­ро­го поль­зо­ва­те­лю мож­но будет обнов­лять пароль.

И так, теперь давай­те созда­дим поль­зо­ва­те­ля и пароль:

vault read database/creds/test-role

* после вво­да коман­ды vault сге­не­ри­ру­ет и создаст в базе ново­го поль­зо­ва­те­ля и пароль.

Мы долж­ны уви­деть что-то на подобие:

* Если мы уви­дим ошиб­ку, на подо­бие Error 1470: String 'v-root-test-role-KHWyA2IwdoaUth7c' is too long for user name (should be no longer than 16) мы столк­ну­лись с огра­ни­че­ни­ем на сто­роне СУБД (нель­зя созда­вать имя поль­зо­ва­те­ля с дли­ной более 16 сим­во­лов). Что­бы решить про­бле­му мы долж­ны пере­со­здать под­клю­че­ние database/config/test с новым пла­ги­ном mysql-legacy-database-plugin.

Так­же для созда­ния поль­зо­ва­те­ля мы можем исполь­зо­вать API запрос:

curl --header "X-Vault-Token: s.e0YKJEOHlpfgQiWqZlzVuUbY" http://127.0.0.1:8201/v1/database/creds/test-role

* где X-Vault-Token — токен с досту­пом. Для теста мож­но исполь­зо­вать тот, что был полу­чен для root после ини­ци­а­ли­за­ции системы.

Теперь давай­те про­ве­рим, что создан­ные учет­ные запи­си име­ют нуж­ный нам доступ. Для нача­ла, под поль­зо­ва­те­лем root мож­но про­ве­рить, что запи­си созданы:

> SELECT user, host FROM mysql.user;

Мы долж­ны уви­деть в спис­ках нуж­ную запись (в нашем при­ме­ре, v-test--gVPavnGVr).

Теперь зай­дем под учет­ной запи­сью, кото­рая была созда­на с помо­щью vault:

mysql -h192.168.0.15 -u'v-test--gVPavnGVr' -p'7v9jC-XHXJjQ2sicLI42'

* в моем слу­чае из-за досту­па %, под­клю­че­ние с localhost было запре­ще­но. Поэто­му я про­ве­ряю доступ с дру­го­го хоста в локаль­ной сети, доба­вив опцию -h192.168.0.15 (где 192.168.0.15 — сер­вер с СУБД, доступ к кото­рой предо­став­лял­ся через vault).

Мы долж­ны под­клю­чить­ся к базе.

Отме­нить доступ мож­но командой:

vault lease revoke database/creds/test-role/JpEmEh2MJV115Lr4S4Lx5UHW

* где database/creds/test-role/JpEmEh2MJV115Lr4S4Lx5UHW — зна­че­ние lease_id, кото­рое нам вер­ну­ла систе­ма при созда­нии вре­мен­ной учет­ной записи.

Посмот­реть спи­сок всех иден­ти­фи­ка­то­ром мож­но командой:

vault list sys/leases/lookup/database/creds/test-role

* где test-role — имя создан­ной нами роли.

Про­длить lease_duration или default_ttl (пароль) мож­но с помо­щью команды:

vault lease renew database/creds/test-role/JpEmEh2MJV115Lr4S4Lx5UHW

Аутентификация и политики

Hashicorp Vault поз­во­ля­ет управ­лять досту­па­ми с помо­щью поли­тик и токе­нов авто­ри­за­ции. Рас­смот­рим про­цесс настройки.

Работа с токенами

Для нача­ла научим­ся управ­лять токе­на­ми. Про­стая коман­да для созда­ния нового:

vault token create

Систе­ма сге­не­ри­ру­ет новый ключ и сде­ла­ет вывод на экран.

Так­же мы можем создать вре­мен­ный токен:

vault token create -period=1h

* на один час.

Посмот­реть инфор­ма­цию о токене мож­но через его аксес­сор. Сна­ча­ла полу­чим спи­сок аксессоров:

vault list auth/token/accessors

После смот­рим токен по аксессору:

vault token lookup -accessor uW9Ajr8VzFiCwHzHWn75qWVe

Вой­ти в систе­му с помо­щью токе­на мож­но командой:

vault login

После вво­дим наш токен. Или одной командой:

vault login s.Db9j6Q4TvyFDr3j2aQmXttrX

Посмот­реть инфор­ма­цию о токене, под кото­рым мы заре­ги­стри­ро­ва­лись в систе­ме, мож­но командой:

vault token lookup

А дан­ной коман­дой мы созда­ем поль­зо­ва­те­ля и при­вя­зы­ва­ем его к поли­ти­ке my-policy:

vault token create -policy=my-policy

Если поли­ти­ки нет в систе­ме, то мы полу­чим предупреждение:

WARNING! The following warnings were returned from Vault:

* Policy "my-policy" does not exist

Нас это не долж­но забо­тить — на сле­ду­ю­щем шаге мы ее создадим.

При необ­хо­ди­мо­сти при­вя­зать токен к несколь­ким поли­ти­кам, пере­чис­ля­ем из в опци­ях policy:

vault token create -policy=my-policy -policy=my-policy2

Работа с политиками

Выше мы созда­ли токен и при­вя­за­ли его к поли­ти­ке my-policy. Созда­дим ее:

* в дан­ной поли­ти­ке мы раз­ре­ша­ем чте­ние всех сек­ре­тов в secret. Для ранее создан­но­го сек­ре­та secret/hello мы раз­ре­шим чте­ние и обнов­ле­ние запи­сей, а для сек­ре­та secret/foo так­же мы раз­ре­ша­ем созда­вать запи­си. Обра­ти­те вни­ма­ние, что на самом деле, дан­ные хра­нят­ся в secret/data…

Посмот­реть спи­сок поли­тик мож­но командой:

vault policy list

Посмот­реть инфор­ма­цию о кон­крет­ной поли­ти­ке мож­но командой:

vault policy read my-policy

Проверка политики

И так, мы созда­ли токен, при­вя­за­ли его к поли­ти­ке, созда­ли саму поли­ти­ку. Про­ве­рим, что наши пра­ва работают.

Если нуж­но, мож­но создать еще токен и при­вя­зать его к нашей политике:

vault token create -policy=my-policy

Заре­ги­стри­ру­ем­ся с нуж­ным нам токе­ном (кото­рый при­вя­зан к  про­ве­ря­е­мой политике):

vault login

Попро­бу­ем сна­ча­ла создать сек­рет в вет­ке secret/foo и в нем ука­зать пару ключ-значение:

vault kv put secret/foo/new foo=world

Коман­да долж­на выпол­нить­ся успешно.

Теперь сде­ла­ем то же самое для secret/hello

vault kv put secret/hello/new foo=world

Мы долж­ны полу­чить ошибку

Error writing data to secret/data/hello/new: Error making API request.

URL: PUT http://127.0.0.1:8201/v1/secret/data/hello/new
Code: 403. Errors:

* 1 error occurred:
* permission denied

Теперь логи­ним­ся под токе­ном с пол­ны­ми пра­ва­ми и доба­вим запись:

vault kv put secret/hello/new foo=world

И сно­ва захо­дим под токе­ном с огра­ни­чен­ны­ми пра­ва­ми. Про­бу­ем обно­вить запись:

vault kv put secret/hello/new foo=world2

Коман­да долж­на выпол­нить­ся успеш­но, так как мы раз­ре­ши­ли поли­ти­кой обнов­лять записи.

Аутентификация на основе пользователей

Так­же в Hashicorp Vault мы можем создать поль­зо­ва­те­ля с паро­лем и при­вя­зать к нему поли­ти­ку. Адми­ни­стра­тор смо­жем вхо­дить в систе­му под учет­ной запи­сью, а не с помо­щью токена.

Раз­ре­ша­ем метод auth по пути userpass:

vault auth enable userpass

Созда­ем пользователя:

vault write auth/userpass/users/user1 password="test-pass" policies="my-profile"

* дан­ной коман­дой мы созда­ли поль­зо­ва­те­ля user1  с паро­лем test-pass и при­вя­за­ли его к поли­ти­ке my-profile.

Вой­ти в систе­му мож­но командой:

vault login -method=userpass username=user1

Вво­дим пароль и попа­да­ем в систе­му под поль­зо­ва­те­лем user1. Мож­но выпол­нить тесты, кото­рые мы дела­ли выше.

Одноразовые SSH пароли

Рас­смот­рим вари­ан­ты хра­не­ния сек­ре­тов для авто­ри­за­ции по SSH с исполь­зо­ва­ни­ем одно­ра­зо­вых паро­лей или One-Time SSH Password (OTP).

Настройка на сервере Vault

Раз­ре­ша­ем меха­низм ssh:

vault secrets enable ssh

Созда­ем роль для созда­ния одно­ра­зо­во­го пароля:

vault write ssh/roles/otp_key_role \
key_type=otp \
default_user=test \
cidr_list=10.0.2.0/24

* в дан­ном примере:

  • key_type — тип созда­ва­е­мо­го клю­ча. Остав­ля­ем otp.
  • default_user — имя учет­ной записи.
  • cidr_list — под­сеть, для кото­рой будет раз­ре­шен доступ. Это долж­на быть под­сеть ком­пью­те­ров, на кото­рых мы будем про­хо­дить аутен­ти­фи­ка­цию по одно­ра­зо­во­му паролю.

На сер­ве­ре, пока, все. Пере­хо­дим к настрой­ке клиента.

Настройка на клиенте

На кли­ен­те необ­хо­ди­мо выпол­нить настрой­ку, кото­рая поз­во­лит выпол­нять две задачи:

  1. Созда­вать одно­ра­зо­вые паро­ли на сто­роне Vault.
  2. Осу­ществ­лять про­вер­ку под­лин­но­сти при под­клю­че­нии по SSH.

Дан­ной зада­чей зани­ма­ет­ся vault-ssh-helper. Рас­смот­рим про­цесс его уста­нов­ки и настройки.

Нам пона­до­бит­ся пакет для рас­па­ков­ки zip-архи­вов. В зави­си­мо­сти от систе­мы ста­вим его одной из команд ниже.

а) для Debian / Ubuntu:

apt-get install unzip

б) для CentOS / Red Hat / Fedora:

yum install unzip

Уста­нов­ка vault-ssh-helper выпол­ня­ет­ся про­стым копи­ро­ва­ни­ем бинар­ни­ка. Пере­хо­дим на офи­ци­аль­ный сайт для загруз­ки и выби­ра­ем послед­нюю вер­сию паке­та. На сле­ду­ю­щей стра­ни­цы копи­ру­ем ссыл­ку на нуж­ный вари­ант архи­ва, в зави­си­мо­сти от архи­тек­ту­ры наше­го сервера:

С помо­щью ско­пи­ро­ван­ной ссыл­ки загру­жа­ем архив:

wget https://releases.hashicorp.com/vault-ssh-helper/0.2.1/vault-ssh-helper_0.2.1_linux_amd64.zip

Рас­па­ко­вы­ва­ем его:

unzip vault-ssh-helper_*.zip -d /usr/bin

Созда­дим ката­лог для кон­фи­гу­ра­ци­он­ных фай­лов vault-ssh-helper:

mkdir /etc/vault-ssh-helper

Созда­дим кон­фи­гу­ра­ци­он­ный файл:

vi /etc/vault-ssh-helper/config.hcl

vault_addr = "https://192.168.0.20:8200"
ssh_mount_point = "ssh"
tls_skip_verify = true
allowed_roles = "*"

* где:

  • vault_addr — адрес наше­го сер­ве­ра секретов.
  • ssh_mount_point — путь на сто­роне Vault, по кото­ро­му будут хра­нить­ся сек­ре­ты. Настра­и­ва­ет­ся при вклю­че­нии меха­низ­ма SSH.
  • tls_skip_verify — сто­ит ли про­пус­кать про­вер­ку под­лин­но­сти сер­ти­фи­ка­та. Так как у нас еще не настро­ен валид­ный сер­ти­фи­кат, уста­нав­ли­ва­ем зна­че­ние в true.
  • allowed_roles — на сто­роне сер­ве­ра мож­но созда­вать раз­ным поль­зо­ва­те­лей от раз­ных ролей. В дан­ной настрой­ке мы можем опре­де­лить, поль­зо­ва­те­лям с какой ролью будет раз­ре­шен вход по SSH.

Откры­ва­ем кон­фи­гу­ра­ци­он­ный файл pamd для sshd:

vi /etc/pam.d/sshd

И в самый верх добавляем:

auth sufficient pam_exec.so quiet expose_authtok log=/tmp/vaultssh.log /usr/bin/vault-ssh-helper -config=/etc/vault-ssh-helper/config.hcl
auth optional pam_unix.so not_set_pass use_first_pass nodelay
…

* в дан­ной кон­фи­гу­ра­ции мы, по-преж­не­му, смо­жем авто­ри­зо­вать­ся под учет­ны­ми запи­ся­ми, создан­ны­ми на самом сер­ве­ре. Если необ­хо­ди­мо это отклю­чить, раз­ре­шив вход толь­ко с OTP, ком­мен­ти­ру­ем @include common-auth и меня­ем sufficient на required.

Нако­нец, редак­ти­ру­ем кон­фи­гу­ра­ци­он­ный файл sshd. Откры­ва­ем его:

vi /etc/ssh/sshd_config

Выстав­ля­ем сле­ду­ю­щие зна­че­ния для опций:

ChallengeResponseAuthentication yes
…
UsePAM yes

* где ChallengeResponseAuthentication раз­ре­ша­ет авто­ри­за­цию с при­ме­не­ни­ем интер­ак­тив­но­го вво­да паро­ля; UsePAM раз­ре­ша­ет исполь­зо­ва­ние моду­ля pam.

Пере­за­пу­стим сер­вис ssh:

systemctl restart sshd

Выпол­ня­ем про­вер­ку нашей настрой­ки командой:

vault-ssh-helper -verify-only -config /etc/vault-ssh-helper/config.hcl

Мы долж­ны полу­чить ответ:

2021/05/18 14:07:14 [INFO] using SSH mount point: ssh
2021/05/18 14:07:14 [INFO] using namespace:
2021/05/18 14:07:14 [INFO] vault-ssh-helper verification successful!

Зна­чит настрой­ка на кли­ен­те выпол­не­на коррекнто.

Созда­ем учет­ную запись на кли­ен­те, под кото­рой будем вхо­дить в систе­му с одно­ра­зо­вым паролем:

useradd test -m

* в нашей поли­ти­ке будет созда­вать­ся пароль для учет­ной запи­си test.

Создаем одноразовый пароль

Вво­дим команду:

vault write ssh/creds/otp_key_role ip=192.168.0.25

* в дан­ном при­ме­ре мы созда­ем одно­ра­зо­вый пароль для ком­пью­те­ра с IP-адре­сом 192.168.0.25.

Мы долж­ны полу­чить, при­ме­ре­но, такой вывод:

Key                Value
--- -----
lease_id           ssh/creds/otp_key_role/5SYfW5VDZ3qGnaMtPhUEHbNr
lease_duration     768h
lease_renewable    false
ip                 192.168.0.25
key                83a57021-74b0-3ce3-8179-6fb92288c0ce
key_type           otp
port 22
username           test

* мы полу­чи­ли одно­ра­зо­вый пароль 83a57021-74b0-3ce3-8179-6fb92288c0ce.

Про­бу­ем вой­ти в систему:

ssh test@192.168.0.25

Вво­дим тот пароль, кото­рый нам выда­ла систе­ма (key). Вой­ти мы смо­жем толь­ко один раз, после нуж­но будет уже гене­ри­ро­вать новый пароль.

Настройка SSL

В инструк­ции выше мы настро­и­ли наше окру­же­ние для локаль­но­го под­клю­че­ния по http. Дан­ный метод вре­мен­ный, так как не поз­во­лит управ­лять систе­мой с дру­го­го ком­пью­те­ра или при­дет­ся жерт­во­вать без­опас­но­стью. Рас­смот­рим про­цесс настрой­ки запро­сов по защи­щен­но­му про­то­ко­лу https.

Пер­вое, что нам нуж­но, это полу­чить сер­ти­фи­кат. Пра­виль­нее все­го купить сер­ти­фи­кат или запро­сить через Let's Encrypt. После про­пи­сать в кон­фи­гу­ра­ци­он­ном фай­ле vault путь до дан­но­го сер­ти­фи­ка­та. Но мы рас­смот­рим про­цесс полу­че­ния само­под­пи­сан­но­го сер­ти­фи­ка­та, но при этом, кото­рый при­мет систе­ма. Для это­го необ­хо­ди­мо выпол­нить несколь­ко условий:

  • Сер­ти­фи­кат дол­жен быть выдан для hostname, по кото­ро­му мы будем отправ­лять запросы.
  • Для сер­ти­фи­ка­та мы долж­ны ука­зать аль­тер­на­тив­ное имя subjectAltName.

И так, созда­ем ката­лог для хра­не­ния сертификатов:

mkdir /etc/ssl/vault

Про­ве­ря­ем вер­сию openssl:

openssl version

Она долж­на быть 1.1.1 и выше. В про­тив­ном слу­чае, необ­хо­ди­мо выпол­нить обнов­ле­ние OpenSSL. Как пра­ви­ло, дан­ное дей­ствие тре­бу­ет­ся толь­ко на CentOS 7.

Гене­ри­ру­ем сертификат:

openssl req -new -x509 -days 1461 -nodes -out /etc/ssl/vault/cert.pem -keyout /etc/ssl/vault/cert.key -subj "/C=RU/ST=SPb/L=SPb/O=Global Security/OU=IT Department/CN=vault.user1.local" -addext "subjectAltName = DNS:vault.user1.local"

* в дан­ном при­ме­ре мы сге­не­ри­ру­ем необ­хо­ди­мые клю­чи по пути /etc/ssl/vault; обя­за­тель­но, нуж­но поме­нять зна­че­ния vault.user1.local на имя сер­ве­ра, кото­рый исполь­зу­ет­ся у вас.

Если коман­да вер­нет ошиб­ку, про­ве­ря­ем, что у нас обнов­лен­ная вер­сия openssl, кото­рая под­дер­жи­ва­ет ключ addext.

Теперь откро­ем кон­фи­гу­ра­ци­он­ный файл hashicorp vault:

vi /etc/vault.d/vault.hcl

При­ве­дем сек­цию HTTPS listener к виду:

# HTTPS listener
listener "tcp" {
address       = "0.0.0.0:8200"
tls_cert_file = "/etc/ssl/vault/cert.pem"
tls_key_file  = "/etc/ssl/vault/cert.key"
}

* необ­хо­ди­мо поме­нять пути до фай­лов tls_cert_file и tls_key_file.

Пере­за­пус­ка­ем сервис:

После пере­за­груз­ки сер­ви­са, он ста­нет запе­ча­тан­ным и нам нуж­но будет сно­ва вве­сти 3 части клю­ча (коман­ды vault operator unseal).

systemctl restart vault

Меня­ем в окру­же­нии пере­мен­ную VAULT_ADDR:

export VAULT_ADDR=https://vault.user1.local:8200

* мы ука­зы­ва­ем про­то­кол https, обра­ще­ния долж­ны выпол­нять­ся по домен­но­му име­ни, для кото­ро­го мы полу­чи­ли сер­ти­фи­кат; так­же ука­зы­ва­ем порт 8200.

Выпол­ня­ем команду:

vault status

Мы долж­ны полу­чить состо­я­ние систе­мы. Зна­чит запро­сы по https работают.

И послед­нее, сно­ва откры­ва­ем файл:

vi /etc/environment

И так­же меня­ем зна­че­ние для пере­мен­ной VAULT_ADDR:

VAULT_ADDR=https://vault.user1.local:8200

Запуск в виде контейнера Docker

В инструк­ции мы рас­смот­ре­ли уста­нов­ку Hashicorp Vault как паке­та. Так­же мы можем уста­но­вить дан­ный сер­вис в виде кон­тей­не­ра Docker из офи­ци­аль­но­го обра­за. Рас­смот­рим вкрат­це дан­ный вопрос.

Для нача­ла, необ­хо­ди­мо уста­но­вить в систе­му Docker. После загру­жа­ем образ

docker pull vault

Для запус­ка vault в режи­ме сер­ве­ра вводим:

docker run --cap-add=IPC_LOCK --name vault -d -p 8200:8200 -e 'VAULT_LOCAL_CONFIG={"backend": {"file": {"path": "/vault/file"}}, "default_lease_ttl": "168h", "max_lease_ttl": "720h", "listener": {"tcp": {"address": "127.0.0.1:8200", "tls_disable": "true"}}}' vault server

После захо­дим внутрь контейнера:

docker exec -it vault sh

Зада­ем систем­ную пере­мен­ную для под­клю­че­ния к vault по http:

export VAULT_ADDR=http://127.0.0.1:8200

Ини­ци­а­ли­зи­ру­ем сервер:

vault operator init

… и так далее.

Установка клиента и удаленное подключение

Мы можем управ­лять нашим сер­ве­ром с уда­лен­но­го ком­пью­те­ра из команд­ной стро­ки. Для это­го необ­хо­ди­мо уста­но­вить кли­ен­та и настро­ить систем­ное окружение.

Уста­нов­ка кли­ен­та ничем не отли­ча­ет­ся от уста­нов­ки сер­ве­ра. Толь­ко нам не нуж­но ини­ци­а­ли­зи­ро­вать систе­му и запус­кать ее в каче­стве сер­ви­са. Опе­ра­ции отли­ча­ют­ся в зави­си­мо­сти от уста­нов­лен­ной опе­ра­ци­он­ной системы.

а) для Debian / Ubuntu / Mint:

apt-get install wget apt-transport-https

echo "deb [arch=amd64] https://apt.releases.hashicorp.com $(lsb_release -cs) main" > /etc/apt/sources.list.d/hashicorp.list

apt-get update

apt-get install vault

б) для CentOS / Red Hat / Fedora:

yum install wget

wget https://rpm.releases.hashicorp.com/RHEL/hashicorp.repo -O /etc/yum.repos.d/hashicorp.repo

yum install vault

После чего зада­ем пере­мен­ную систем­но­го окружения

export VAULT_ADDR=https://vault.user1.local:8200

* обра­ти­те вни­ма­ние, что мы под­клю­ча­ем­ся уже по https. Имя наше­го сер­ве­ра долж­но раз­ре­шать­ся в DNS или быть про­пи­са­но в фай­ле hosts на ком­пью­те­ре управления.

Так­же, если у нас само­под­пи­сан­ный сер­ти­фи­кат, вводим:

export VAULT_SKIP_VERIFY=true

* дан­ная систем­ная пере­мен­ная ука­зы­ва­ет систе­ме не про­ве­рять валид­ность сертификата.

Про­бу­ем посмот­реть ста­тус уда­лен­но­го сервера:

vault status

Реги­стри­ру­ем­ся в системе:

vault login -method=userpass username=user1

* в дан­ном при­ме­ре мы захо­дим под поль­зо­ва­те­лем user1. Так­же мы можем вой­ти с исполь­зо­ва­ни­ем токена.

Мож­но выпол­нять дей­ствия соглас­но разрешениям.

 

Управление динамическими учетными записями в PostgreSQL через Hashicorp Vault

 

Настройка прав PostgreSQL

На сер­ве­ре PostgreSQL нам необходимо:

  1. Задать пароль для поль­зо­ва­те­ля postgres.
  2. Создать поль­зо­ва­те­ля, пароль для кото­ро­го мы будем хра­нить в Vault.
  3. Раз­ре­шить под­клю­че­ние к базе дан­ных для postgres и создан­но­го пользователя.
  4. Открыть порт 5432 для уда­лен­но­го подключения.
  5. Про­ве­рить доступы.

Рас­смот­рим дей­ствия по шагам.

1. Задаем пароль для postgres

Дан­ные дей­ствия необ­хо­ди­мы, если мы не зада­ва­ли пароль для поль­зо­ва­те­ля postgres или мы не зна­ем дан­ный пароль.

Сто­ит иметь вви­ду, что дан­ный поль­зо­ва­тель может исполь­зо­вать­ся дру­ги­ми при­ло­же­ни­я­ми — таким обра­зом, сме­на паро­ля при­ве­дет к поте­ре их рабо­то­спо­соб­но­сти. В этом слу­чае, сто­ит уточ­нить теку­щий пароль и исполь­зо­вать его.

Захо­дим под поль­зо­ва­те­лем postgres и под­клю­ча­ем­ся к СУБД:

su - postgres

$ psql

Вво­дим:

=# ALTER USER postgres PASSWORD 'password';

* в дан­ном при­ме­ре мы зада­ем пароль password для поль­зо­ва­те­ля postgres.

2. Создаем нового пользователя

На дан­ном шаге мы созда­дим поль­зо­ва­те­ля, для кото­ро­го и будем хра­нить сек­рет в Vault. В рам­ках при­ме­ра мы не будем его предо­став­лять ника­ких досту­пов. Для нас доста­точ­но, что­бы мы мог­ли под­клю­чить­ся и удо­сто­ве­рить­ся, что пароль будет меняться.

В той же команд­ной обо­лоч­ке postgresql вводим:

=# CREATE USER user1 WITH PASSWORD 'myPassword';

* с помо­щью дан­ной коман­ды мы созда­дим поль­зо­ва­те­ля user1 с паро­лем myPassword.

3. Разрешаем подключение к СУБД

Нам необ­хо­ди­мо раз­ре­шить под­клю­чать­ся к базе дан­ных поль­зо­ва­те­лю user1 (созда­ли на шаге 2) с локаль­но­го ком­пью­те­ра и поль­зо­ва­те­лю postgres с сер­ве­ра Vault. Это дела­ет­ся посред­ством редак­ти­ро­ва­ния фай­ла pg_hba.conf.

Но раз­ме­ще­ние это­го фай­ла может быть раз­ным — это зави­сит от вер­сии уста­нов­лен­но­го PostgreSQL. Вво­дим команду:

=# SHOW config_file;

Дан­ная коман­да нам пока­жет место раз­ме­ще­ния кон­фи­гу­ра­ци­он­но­го фай­ла postgresql.conf — в этом же ката­ло­ге нахо­дят­ся и дру­гие кон­фи­гу­ра­ци­он­ные фай­лы. Напри­мер, если коман­да показала:

----------------------------------------
/var/lib/pgsql/11/data/postgresql.conf
(1 row)

… то зна­чит нуж­ный нам файл в ката­ло­ге /var/lib/pgsql/11/data.

Выхо­дим из команд­ной обо­лоч­ки psql:

=# \q

Раз­ло­ги­ни­ва­ем­ся из-под поль­зо­ва­те­ля postgres:

$ exit

И вво­дим:

vi /var/lib/pgsql/11/data/pg_hba.conf

* где /var/lib/pgsql/11/data — путь, кото­рый мы полу­чи­ли с помо­щью sql-коман­ды SHOW config_file.

В дан­ном фай­ле мы долж­ны доба­вить 2 строки:

* где 192.168.1.20 — IP-адрес пред­по­ла­га­е­мо­го сер­ве­ра Vault, с кото­ро­го мы будем под­клю­чать­ся под поль­зо­ва­те­лем postgres.

Откры­ва­ем кон­фи­гу­ра­ци­он­ный файл:

vi /var/lib/pgsql/11/data/postgresql.conf

При­во­дим опцию listen_addresses к виду:

listen_addresses = '*'

* в дан­ном при­ме­ре мы настро­и­ли, что­бы postgresql слу­шал запро­сы на всех сете­вых интер­фей­сах. При необ­хо­ди­мо­сти. мы можем огра­ни­чить их чис­ло вво­дом кон­крет­но­го адреса.

Пере­за­пус­ка­ем служ­бу СУБД:

 systemctl restart postgresql

* коман­да для пере­за­пус­ка PostgreSQL может отли­чать­ся и зави­сит от вер­сии СУБД.

4. Настраиваем межсетевой экран

Для под­клю­че­ния к сер­ве­ру баз дан­ных по сети, нам необ­хо­ди­мо открыть порт 5432.

Как пра­ви­ло, в CentOS исполь­зу­ет­ся firewalld, как сред­ство управ­ле­ния бранд­мау­э­ром. Вводим:

firewall-cmd --permanent --add-port=5432/tcp

firewall-cmd --reload

5. Делаем проверку

Убе­дим­ся, что наши учет­ные запи­си име­ют пра­ва для под­клю­че­ния к базе данных.

На сер­ве­ре с СУБД вводим:

psql -Uuser1 -W template1

* в дан­ном при­ме­ре мы под­клю­ча­ем­ся к локаль­но­му хосту под поль­зо­ва­те­лем user1.

Систе­ма запро­сит пароль — вво­дим тот, что зада­ли при созда­нии наше­го поль­зо­ва­те­ля. Мы долж­ны попасть в обо­лоч­ку psql.

Теперь под­клю­ча­ем­ся по SSH на сер­вер Vault. Нам при­дет­ся уста­но­вить на него кли­ен­та postgresql.

а) На систе­мы RPM (Rocky Linux, CentOS):

yum install postgresql

б) На Deb (Ubuntu, Debian):

apt install postgresql

После уста­нов­ки мож­но под­клю­чать­ся к наше­му сер­ве­ру с помо­щью коман­ды psql.

Вво­дим:

psql -h192.168.1.15 -Upostgres -W

* в дан­ном при­ме­ре мы под­клю­чим­ся к сер­ве­ру 192.168.1.15 под учет­ной запи­сью postgres.

Кон­соль у нас запро­сит пароль — вво­дим тот, что зада­ли для поль­зо­ва­те­ля postgres. В ито­ге мы долж­ны под­клю­чить­ся к серверу:

postgres=#

Выхо­дим из SQL-оболочки:

postgres=# \q

… и пере­хо­дим к настрой­ке Vault.

Настройка Vault

На сто­роне хра­ни­ли­ща паро­лей необходимо:

  1. Вклю­чить меха­низм хра­не­ния database.
  2. Создать кон­фи­гу­ра­цию для под­клю­че­ния к СУБД и при­вя­зать ее к роли.

Выпол­ним настрой­ки по шагам.

Включаем механизм database

Для вклю­че­ния меха­низ­ма database вводим:

vault secrets enable database

Мы долж­ны полу­чить ответ:

Success! Enabled the database secrets engine at: database/

… или:

Error enabling: Error making API request.
…
* path is already in use at database/

Вто­рой ответ гово­рит нам о том, что меха­низм database уже рабо­та­ет по пути database/. Так или ина­че, идем дальше.

Настройка подключения к postgresql

Созда­ем кон­фи­гу­ра­цию с опци­я­ми под­клю­че­ния к базе данных:

* где:

  • database/config/postgresql — путь в систе­ме Vault к секрету.
  • plugin_name — пла­гин, кото­рый будем исполь­зо­вать­ся конфигурацией.
  • allowed_roles — для каких ролей будет исполь­зо­вать­ся дан­ная кон­фи­гу­ра­ция. Ниже по инструк­ции мы созда­дим 2 роли — для рота­ции паро­лей и для созда­ния вре­мен­ных пользователей.
  • connection_url — стро­ка под­клю­че­ния к базе дан­ных. В дан­ном при­ме­ре 192.168.0.15 — сер­вер PostgreSQL.
  • username — поль­зо­ва­тель, под кото­рым выпол­ня­ет­ся под­клю­че­ние к СУБД.
  • password — пароль для поль­зо­ва­те­ля, под кото­рым выпол­ня­ем подключение.

Наш Vault под­го­тов­лен для рабо­ты с базой PostgreSQL.

Настройка ротации паролей

Дан­ная настрой­ка поз­во­лит авто­ма­ти­че­ски по тай­ме­ру менять паро­ли в СУБД PostgreSQL для опре­де­лен­ных учет­ных записей.

На сто­роне хра­ни­ли­ща паро­лей необходимо:

  1. Создать роль, кото­рая будет менять пароль в базе данных.
  2. Про­ве­рить настрой­ки, создав новый пароль и под­клю­чив­шись к базе данных.

Пере­хо­дим к настройке.

Создаем роль для смены пароля

Настрой­ка зада­ет­ся с помо­щью static-roles. В нашем Vault вво­дим команду:

* обра­ти­те вни­ма­ние, что запрос rotation_statements важ­но напи­сать имен­но так — пер­вая кавыч­ка двой­ная, вто­рая одинарная.

** в дан­ном примере:

  • Мы созда­дим роль с назва­ни­ем postgresql-rotate (с тем назва­ни­ем, кото­рое мы исполь­зо­ва­ли в allowed_roles, когда созда­ва­ли конфигурацию).
  • Опция db_name долж­на назы­вать­ся как настрой­ка, кото­рую мы созда­ли на преды­ду­щем шаге (database/config/postgresql).
  • Наша роль будет выпол­нять коман­ду rotation_statements (менять пароль для пользователя).
  • Каж­дые 720 часов (30 дней) пароль будет менять­ся автоматически.

Мы долж­ны уви­деть что-то на подобие:

Success! Data written to: database/static-roles/postgresql-rotate

Гото­во.

Меняем пароль и проверяем доступ

Давай­те посмот­рим теку­щий пароль:

vault read database/static-creds/postgresql-rotate

Мы полу­чим что-то на подобие:

Где Cai-dzsJDtKTLHSl6Bvt — наш пароль от учет­ной запи­си user1.

Перей­дем на сер­вер с PostgreSQL и попро­бу­ем вой­ти в СУБД с исполь­зо­ва­ни­ем этих данных:

psql -Uuser1 -W template1

Мы долж­ны под­клю­чить­ся с исполь­зо­ва­ни­ем паро­ля, кото­рый полу­чи­ли от Vault.

Создание временных пользователей в PostgreSQL

Давай­те теперь рас­смот­рим настрой­ку, при кото­рой Vault будет созда­вать вре­мен­ных поль­зо­ва­те­лей. Для это­го мы:

  1. Созда­дим роль в Vault, кото­рая будет созда­вать учет­ную запись в базе PostgreSQL.
  2. Настро­им файл pg_hba.conf для воз­мож­но­сти под­клю­чать­ся к базе поль­зо­ва­те­лям по паролю.
  3. Про­ве­рим настрой­ки, создав учет­ную запись и под­клю­чив­шись к СУБД.

При­сту­пим.

Создаем роль для создания нового пользователя

Настрой­ка зада­ет­ся с помо­щью roles. На сер­ве­ре Vault вво­дим команду:

* обра­ти­те вни­ма­ние, что запрос creation_statements важ­но напи­сать имен­но так — пер­вая кавыч­ка двой­ная, осталь­ные одинарные.

** в дан­ном примере:

  • Мы созда­дим роль с назва­ни­ем postgresql-create (с тем назва­ни­ем, кото­рое мы исполь­зо­ва­ли в allowed_roles, когда созда­ва­ли конфигурацию).
  • Опция db_name долж­на назы­вать­ся как настрой­ка, кото­рую мы созда­ли на шаге созда­ния кон­фи­га (database/config/postgresql).
  • Наша роль будет выпол­нять коман­ду creation_statements — созда­вать поль­зо­ва­те­ля и зада­вать ему пра­ва. Нуж­но пере­пи­сать запрос, что­бы пра­ва выда­ва­лись таки­ми, каки­ми нуж­ны имен­но вам. Для тесто­вых целей мож­но поста­вить как в дан­ном примере.
  • default_ttl — вре­мя, в тече­ние кото­ро­го будет дей­ство­вать пароль.
  • max_ttl — вре­мя, в тече­ние кото­ро­го поль­зо­ва­те­лю мож­но будет обнов­лять пароль.

Мы долж­ны уви­деть что-то на подобие:

Success! Data written to: database/roles/postgresql-create

Гото­во.

Настраиваем файл pg_hba.conf

Ранее в инструк­ции мы настра­и­ва­ли дан­ный файл, что­бы обес­пе­чить воз­мож­ность под­клю­че­ния к базе поль­зо­ва­те­лям user1 и postgresql. Но при созда­нии дина­ми­че­ских учет­ных запи­сей, логи­ны будут раз­ные — необ­хо­ди­мо раз­ре­шить пароль­ный вход для всех пользователей.

Откры­ва­ем файл:

vi /var/lib/pgsql/11/data/pg_hba.conf

* напом­ню, что путь до наше­го фай­ла может быть дру­гим — это зави­сит от опе­ра­ци­он­ной систе­мы и вер­сии postgresql. Посмот­реть рас­по­ло­же­ние кон­фи­гу­ра­ци­он­ных фай­лов мож­но sql-коман­дой SHOW config_file;

В открыв­шем­ся редак­то­ре необ­хо­ди­мо вне­сти изменения:

* мы доба­ви­ли стро­ку, раз­ре­ша­ю­щую поль­зо­ва­те­лю postgres логин с локаль­но­го хоста (local) без запро­са паро­ля; так­же мы заком­мен­ти­ро­ва­ли стро­ку, кото­рая поз­во­ля­ет вход всем поль­зо­ва­те­лям с локаль­но­го хоста без паро­ля и доба­ви­ли новую, почти, такую же, но тре­бу­ю­щую вво­да логи­на и пароля.
** это, все­го лишь, при­мер настрой­ки. В вашем слу­чае необ­хо­ди­мо руко­вод­ство­вать­ся поли­ти­кой без­опас­но­сти, при­ня­той в ком­па­нии и тре­бо­ва­ни­я­ми приложения.

Пере­за­пус­ка­ем сер­вис СУБД:

systemctl restart postgresql

* так­же напом­ню, что назва­ние сер­ви­са может отли­чать­ся и это зави­сит от вер­сии PostgreSQL.

Создаем нового пользователя и проверяем доступ

Созда­ем вре­мен­но­го поль­зо­ва­те­ля командой:

vault read database/creds/postgresql-create

Мы долж­ны уви­деть что-то на подобие:

Наши логин и пароль соот­вет­ствен­но — v-root-postgres-0VO0sWprjEuCPZkZpu62-1631008720 и 9oAhg1VIEhleeRA7EU-U.

Перей­дем на сер­вер с PostgreSQL и попро­бу­ем вой­ти в СУБД с исполь­зо­ва­ни­ем этих данных:

psql -U'v-root-postgres-0VO0sWprjEuCPZkZpu62-1631008720' -W template1

Мы долж­ны под­клю­чить­ся с исполь­зо­ва­ни­ем паро­ля, кото­рый полу­чи­ли от Vault.