Разграничение доступа к данным
Описание
Разграничение доступа к данным в СУБД Pangolin происходит путем настройки ролевой модели.
Ролевая модель – это основополагающий документ, четко определяющий необходимый набор прав доступа ко всем элементам информационной системы для всех ее пользователей. На основании данных, заложенных в ролевую модель, становится возможным назначать права доступа сотрудникам и проводить аудит. Ключевое преимущество ролевого управления – это гибкая управляемость полномочиями и четкое их разграничение, что существенно упрощает выдачу прав и усиливает безопасность информационных систем.
В общем случае, роль – это набор полномочий, который необходим пользователю или группе пользователей для выполнения определенных производственных задач. Каждый сотрудник может иметь одну или несколько ролей, а каждая роль может содержать от одного до множества полномочий, которые разрешены пользователю в рамках этой роли. Роли могут быть привязаны к определенным должностям, подразделениям или функциональным обязанностям работников.
Ролевая модель в скриптах автоматизации
В скриптах автоматизации Pangolin существует ролевая модель, которая была разработана в версии 5.4.0. Ее использование является опциональной возможностью при развертывании СУБД. В данном разделе она рассматривается детально.
Дополнительно в версии 6.2.0 была разработана возможность переназначение прав на определенные файлы, службы и директории таким образом, чтобы непривилегированные пользователи могли управлять ими без необходимости повышения прав. Функциональность разработана для удобства сопровождения СУБД в процессе эксплуатации. Подробнее об этом в подразделе «Управление».
Структура ролей
Для обеспечения контроля доступа к защищаемым элементам системы применяется система разграничения доступа, основанная на ролях. Здесь и ниже под ролевой моделью понимается стандартная ролевая модель СУБД Pangolin, устанавливаемая ранее скриптами автоматизации.
В СУБД Pangolin конфигурирование ролевой модели вынесено из скриптов. Ее конфигурирование опционально и может быть выполнено с помощью скриптов конфигурирования ролевой модели (смотрите раздел «Конфигурирование ролевой модели»), включенных в состав дистрибутива. При необходимости данные скрипты могут быть модифицированы (например, в случае, если в какой-либо функциональности нет необходимости), либо заменены альтернативной ролевой моделью.
В рамках структуры ролей рассматриваются следующие типы:
- административные, использующиеся для системного управления кластером и прикладного администрирования данных;
- прикладные, предназначенные для пользователей, отвечающих за наполнение БД данными;
- специальные, создающиеся для соответствия принятым в организации подходам к аудиту, мониторингу, резервному копированию, восстановлению и др.
При настройке ролевой модели создаются следующие групповые роли:
| Групповая роль | Назначение |
|---|---|
db_admin | Административная роль, обладающая привилегией superuser. Владелец TABLESPACE, DATABASE. Выдается администраторам для управления СУБД |
as_admin | Административная роль — владелец схемы. Выдается администраторам АС. Используется для создания новых объектов в БД (таблиц, функций, последовательностей и тому подобное) и их изменения. Является владельцем пользовательской схемы. Также выдается доменным или локальным ТУЗ для инструментов автоматизации |
as_TUZ | Прикладная роль для доступа к пользовательским данным. Имеет привилегии для совершения DML-операций с объектами схемы. Работает в пуле соединений с БД, а также подключается через Pangolin Pooler |
as_admin_read | Административная роль, отличающаяся от as_admin тем, что предназначена только для просмотра |
all-sa-pam-group | Выдается учетным записям, используемым для доступа через PAM (Privileged Access Management). Используется исключительно для организации аутентификации, конфигурирования pg_hba.conf |
Дополнительно создаются следующие специальные инфраструктурные ТУЗ:
| Инфраструктурная роль | Назначение |
|---|---|
backup_user | ТУЗ с локальной аутентификации для интеграции с СРК |
zabbix_oasubd | ТУЗ с локальной аутентификацией для интеграции с системой мониторинга |
auditor | ТУЗ с локальной аутентификацией для проведения аудита безопасности |
pgbouncer | ТУЗ с локальной аутентификацией для подключения локальной службы Pangolin Pooler |
patroni | ТУЗ с локальной аутентификацией для подключения локальной службы Pangolin Manager |
all-sa-pam19002 | ТУЗ с внешней аутентификацией для подключения через АС PAM администраторов БД |
all-sa-pam19002_ro | ТУЗ с внешней аутентификацией для подключения через АС PAM администраторов систем с привилегиями только на чтение |
Рекомендации по работе с УЗ для администраторов:
- ежедневные задачи администрирования силами администраторов «вручную» должны осуществляться только под персонализированными УЗ;
- права доступа для каждой УЗ/ТУЗ должны быть минимизированы, исходя из использования;
- в руководство должно включаться рекомендуемое минимальное типовое конфигурирование ролевой модели (РМ);
- при развертывании нового экземпляра СУБД Pangolin, минимальная рекомендуемая типовая РМ должна конфигурироваться автоматически.
Матрица несовместимости ролей
В таблице используются обозначения уровней совместимости:
Н- не совместимо;Н/Ж- нежелательно;С- совместимо.
sec_admin_role (администратор безопасности) | superuser (администратор БД, включая postgres) | Роли RBAC Pangolin | |
|---|---|---|---|
sec_admin_role (администратор безопасности) | Н | Н | |
superuser (администратор БД, включая postgres) | Н | С | |
| Роли RBAC Pangolin | Н | С |
Групповая рольsec_admin_role относится к средствам защиты информации (СЗИ) и создается при запуске утилиты инициализации каталога безопасности. Подробнее в разделе «Защита данных от привилегированных пользователей» подразделе «Утилита инициализации каталога безопасности».
Операции, которые не должны выполняться одним лицом
Следующие операции имеют критическое значение для безопасности, поэтому не могут быть выполнены одним лицом:
-
Выполнение общих настроек, влияющих на возможность несанкционированного доступа к передаваемой или хранимой информации:
- настройки защиты сетевых соединений;
- настройки состава загружаемых модулей расширения;
- настройки состава доверенных серверов аутентификации;
- настройки включения прозрачного защитного преобразования данных (TDE).
-
Управление доступом к объектам баз данных, содержащих конфиденциальную или секретную информацию.
Имеется опасность свободного использования расширения pageinspect и схожих с ним на БД с включенной защитой от привилегированных пользователей, в связи с тем что pageinspect позволяет посмотреть рассекреченные данные и не учитывает защиту от привилегированных пользователей.
Связь ролей с объектами БД
При настройке ролевой модели создаются стандартные объекты БД и назначается привилегии для их использования. Такими объектами являются:
- пользовательское табличное пространство — создается на уровне кластера;
- пользовательская база данных — уровень кластера;
- пользовательская схема — уровень определенной базы данных.
Табличное пространство создается в директории /pgdata/{version}/tablespaces/ (может различаться в зависимости от мажорной версии). Владельцем табличного пространства является db_admin, а права на доступ выдаются роли as_admin.
В дополнение к стандартным базам данных ядра PostgreSQL (template0, template1, postgres) создается пользовательская БД. Владелец данной БД — db_admin. Права на использование (USAGE) и логин на данную БД есть по умолчанию у всех вновь создаваемых ролей.
Схема и объекты схемы
Владельцем пользовательской схемы является as_admin. Права на использование схемы выдаются роли as_TUZ.
Для использования схемы предоставляются две привилегии: USAGE и CREATE. Для создания новых объектов в схеме нужна привилегия CREATE. Для обращения к объектам схемы (при условии, что есть права на них) нужна привилегия USAGE. Привилегия CREATE есть только у роли as_admin.
Внутри схемы хранятся объекты БД (таблицы, индексы, функции, и другие). Для каждого типа объекта существует свой набор привилегий. Владельцем объекта становится роль, активная в момент выдачи SQL-запроса на его создание. Так как требуется, чтобы владельцем объектов БД была групповая роль as_admin, то для обеспечения данного условия используются следующие механизмы:
-
При создании объектов администратор, выполняющий данную задачу, должен выдавать команду
SET ROLE as_admin. Для автоматизации некоторых задач, а также в случае, когда другие роли данной УЗ не используются, можно один раз настроить УЗ для работы в ролиas_admin, выдавALTER ROLE <rolename> SET ROLE as_admin. В дальнейшем данная УЗ всегда будет работать какas_admin. -
Владельцем объектов может быть только групповая роль, поэтому в УЗ администраторов, имеющих права на создание объектов отключена опция
INHERIT. Для конечных пользователей БД (ТУЗ) отключатьINHERITне требуется — они не имеют привилегий на создание объектов, но зато автоматически наследуют все другие необходимые привилегии.Роль
as_admin, которая имеет привилегию на создание объектов, нельзя унаследовать (она имеет свойствоNOINHERIT). Это связано с тем, что на момент инсталляции неизвестно, какие пользователи будут работать с БД в дальнейшем и какие привилегии им будут назначены. Групповые роли позволяют систематизировать пользовательскую структуру. А для того, чтобы владельцем объекта становилась именно рольas_admin, необходимо явно переключаться на нее с помощью запроса:SET ROLE as_admin. -
После создания объекта роль
as_adminпредоставляет необходимую привилегию роли, использующей объект (это в первую очередьas_TUZ). Данный процесс можно облегчить, если назначитьdefault privilegesсоздающей роли (as_admin). С помощьюdefault privilegesправа заранее предоставляются на объекты, которые будут создаваться в будущем в данной схеме.
Настройка
Конфигурирование ролевой модели
Установка ролевой модели
Порядок установки:
-
Измените правила в файле
pg_hba.conf:[hostssl|hostgss] postgres admin_dbms <ip_cidr> <auth_method>
[hostssl|hostgss] database_name admin_db <ip_cidr> <auth_method>
[hostssl|hostgss] replication admin_db <ip_cidr> <auth_method>
[hostssl|hostgss] database_name user_db <ip_cidr> <auth_method>
host all admin_dbms 0.0.0.0/0 reject
host all admin_db 0.0.0.0/0 reject
host all user_db 0.0.0.0/0 reject
local all admin_dbms 0.0.0.0/0 reject
local all admin_db 0.0.0.0/0 reject
local all user_db 0.0.0.0/0 rejectВ случае использования нескольких учетных записей для каждой роли – учетные записи указываются через запятую для каждой БД.
В случае использования нескольких БД – желательно группировать записи в
pg_hba.confв разрезе ролей и баз данных. Допустимо указывать роли через запятую для каждой из БД. -
Примените изменения в конфигурационном файле
pg_hba.confс помощью команды:psql -Xc 'SELECT pg_reload_conf()' -
Убедитесь в соответствии конфигурационных параметров
lc_ctype,lc_collateожидаемой локали создаваемой БД (вpostgresql.conf). В случае изменения параметров – перезапустите сервис СУБД. -
Запустите скрипты создания ролей от имени пользователя
postgresоперационной системы в следующем порядке:-
Создайте пользователя роли Администратор СУБД (пример выполнения команды):
$ psql -Xf addrole_admin_dbms.sql
Connected to СУБД Pangolin {version} build 216 (12:05:55 19.02.2024) commit {хеш} (PostgreSQL 15.5)
-- This script is a part of FSTEC Role Model
-- [1/3] This script intended TO ADD RDBMS OWNER ROLE AND must be running FIRST
Enter RDBMS OWNER role name:admin_dbms
Enter DATABASE name:database_name
-- Starting adding database owner at Thu Apr 4 14:49:38 MSK 2024
SET
Time: 0.954 ms
SET
Time: 0.529 ms
DO
Time: 4.498 ms
Adding user admin_dbms
psql:addrole_admin_dbms.sql:75: NOTICE: Success: User admin_dbms added. Do not forget to set password
DO
Time: 5.553 ms
Ending adding database owner at Thu Apr 4 14:49:38 MSK 2024 -
Создайте пользователя роли Администратор БД (пример выполнения команды):
$ psql -Xf addrole_admin_db.sql
Connected to СУБД Pangolin {version} build 216 (12:05:55 19.02.2024) commit {хеш} (PostgreSQL 15.5)
-- This script is a part of FSTEC Role Model
-- [2/3] This script intended to add DB ADMIN role and must be running AFTER addrole_admin_dbms.sql
Enter DB ADMIN role name: admin_db
Enter DATABASE name: database_name
-- Starting adding database admin at Thu Apr 4 14:50:39 MSK 2024
SET
Time: 0.897 ms
SET
Time: 0.531 ms
psql:addrole_admin_db.sql:76: WARNING:
# $PGDATA/pg_hba.conf must contain
[hostssl|hostgssenc] database_name admin_db <ip>/<mask> <auth_method>
DO
Time: 4.918 ms
Adding user admin_db
psql:addrole_admin_db.sql:93: NOTICE: Success: User admin_db added. Do not forget to set password
DO
Time: 5.273 ms
CREATE DATABASE
Time: 76.350 ms
Time: 1.428 ms
-- Ending adding database admin at Thu Apr 4 14:50:39 MSK 2024 -
Создание пользователя роли Пользователь БД (пример выполнения команды)
$ psql -Xf addrole_user_db.sql
Connected to СУБД Pangolin {version} build 216 (12:05:55 19.02.2024) commit {хеш} (PostgreSQL 15.5)
-- This script is a part of FSTEC Role Model
-- [3/3] This script intended to add DB USER role and must be running AFTER addrole_admin_db.sql
Enter DB USER role name: user_db
Enter DATABASE name: database_name
-- Starting adding database user at Thu Apr 4 14:53:05 MSK 2024
SET
Time: 0.918 ms
SET
Time: 0.530 ms
psql:addrole_user_db.sql:66: WARNING:
# $PGDATA/pg_hba.conf must contain
[hostssl|hostgssenc] database_name user_db <ip>/<mask> <auth_method>
DO
Time: 5.107 ms
Adding user user_db
psql:addrole_user_db.sql:83: NOTICE: Success: User user_db added. Do not forget to set password
DO
Time: 5.401 ms
Time: 0.520 ms
SET
Time: 0.462 ms
GRANT ROLE
Time: 2.791 ms
SSL connection (protocol: TLSv1.2, cipher: ECDHE-RSA-AES256-GCM-SHA384, compression: off)
You are now connected to database "database_name" as user "postgres".
SET
Time: 0.910 ms
ALTER ROLE
Time: 4.032 ms
GRANT
Time: 3.367 ms
GRANT
Time: 3.881 ms
GRANT
Time: 0.973 ms
ALTER DEFAULT PRIVILEGES
Time: 3.418 ms
ALTER DEFAULT PRIVILEGES
Time: 2.869 ms
ALTER DEFAULT PRIVILEGES
Time: 2.739 ms
ALTER DEFAULT PRIVILEGES
Time: 2.836 ms
ALTER DEFAULT PRIVILEGES
Time: 2.809 ms
RESET
Time: 0.313 ms
SET
Time: 0.479 ms
SET
Time: 0.414 ms
SET
Time: 0.420 ms
psql:addrole_user_db.sql:121: NOTICE: Fixing permissions on trusted languages
psql:addrole_user_db.sql:121: NOTICE: End fixing permissions on trusted languages
DO
Time: 6.045 ms
-- Ending adding database user at Thu Apr 4 14:53:05 MSK 2024
При добавлении нескольких пользователей ролей — добавление последующих ролей производится после добавления полного цикла из трех ролей Администратора СУБД, Администратора БД, Пользователя БД.
При этом, Администратор БД не может быть добавлен раньше Администратора СУБД, Пользователь БД раньше Администратора БД (в разрезе конкретной БД).
Внимание!Ограничения:
- соответствие имен роли и БД маске: первая буква – латиница (смешанный регистр), вторая и последующие – латиница (смешанный регистр), цифры, символ подчеркивания. Минимальная длина — 1 символ;
- наличие существующего пользователя не является ошибкой. Этому пользователю будут выданы права, предусмотренные скриптом;
- отсутствие БД при создании роли Пользователь БД будет считаться ошибкой.
-
-
В случае выбора метода аутентификации по паролю — задайте пароль для каждой добавленной роли.
Структура скриптов конфигурирования ролевой модели
Скрипты конфигурирования ролевой модели делятся на:
- запускаемые пользователем bash-скрипты;
- SQL-скрипты, вызываемые bash-скриптами с помощью psql;
- Ansible-скрипты.
Модификация скриптов выполняется администратором системы, ответственным за настройку ролевой модели на конкретном кластере. Дистрибутив СУБД Pangolin содержит образец скриптов, настраивающих стандартную ролевую модель.
Примеры запуска скриптов настройки ролевой модели приведены в разделе «Автоматизированная установка при помощи Ansible-скриптов» документа «Руководство по установке».
Запускаемые скрипты
Запускаемые скрипты конфигурирования ролевой модели находятся в директории дистрибутива: installer/scripts_external/configure_roles/configure_roles/templates/role_BASIC/.
Данные скрипты являются параметризуемыми. Значения параметров могут быть заданы непосредственно в теле скрипта, либо с помощью опций командной строки. Параметры, указываемые в командной строке, перезаписывают значения аналогичных параметров, заданных в теле скрипта.
Комментарии в теле скриптов содержат:
- инструкции по выбору значений параметров;
- рекомендуемый перечень подготовительных действий, которые следует выполнить до запуска скрипта;
- перечень заключительных действий, которые следует выполнить после запуска скрипта.
В дистрибутив включены следующие запускаемые bash-скрипты:
| Имя скрипта | Назначение |
|---|---|
run_configure.sh | Основной скрипт, выполняющий конфигурирование ролевой модели |
password_space_settings.sh | Скрипт, выполняющий конфигурирование хранилища паролей для пользователей profile_tuz и backup_user |
Параметры скрипта run_configure.sh:
| Имя параметра | Назначение |
|---|---|
database_name | Имя пользовательской базы данных |
tablespace_name | Имя пользовательского табличного пространства |
tablespace_location | Имя директории, содержащей табличное пространство |
schema_name | Имя пользовательской схемы |
pg_port | Порт в настройках pg_profile |
fqdn_master | Имя хоста мастера в настройках pg_profile |
fqdn_replica | Имя хоста реплики в настройках pg_profile |
stats_periods | Период запуска задания cron в настройках pg_profile |
expire_date | Срок действия пароля конечных пользователей |
user_for_backup | Имя пользователя резервного копирования для использования в manage_backup.sh |
as_adms | Список конечных пользователей, создаваемых в группе as_admin |
as_tuzs | Список конечных пользователей, создаваемых в группе as_TUZ |
temp_pass | Флаг, указывающий на задание временных паролей |
tde_admin_protection | Флаг включения TDE |
path_to_scripts | Путь, по которому размещается данный скрипт (требуется только при запуске с помощью Ansible) |
psql_path | Путь, по которому размещается запускаемый модуль psql |
password_list | Словарь паролей ТУЗ. В случае задания пароля в виде SCRAM-SHA-256 - хеш должен быть предварительно вычислен |
feature_list | Словарь для задания списка функций, которые необходимо включить |
locale | Значение locale с которой будет создана пользовательская БД |
prdbname | Имя пользовательской БД в которой будет установлен pg_profile |
Скрипт run_configure.sh, запущенный с опцией -h или --help, выводит сообщение-подсказку о доступных опциях командной строки и после этого останавливается.
При запуске скрипта run_configure.sh выводится список актуальных значений параметров и выполняется ряд проверок.
SQL-скрипты
SQL-скрипты вызываются bash-скриптами, являющимися в данном ключе оркестраторами. SQL-скрипты находятся в директориях:
installer/scripts_external/configure_roles/configure_roles/templates/role_BASIC/sql_scripts;installer/scripts_external/configure_roles/configure_roles/templates/role_BASIC/sql_scripts/extensions;installer/scripts_external/configure_roles/configure_roles/templates/role_BASIC/sql_scripts/pg_profile.
SQL-скрипты предназначены для настройки отдельных функциональных блоков ролевой модели и в качестве параметров принимают значения из bash-скриптов, которыми они были вызваны. Скрипты выполняются целиком, как отдельная транзакция, и откатываются, если какой-либо оператор завершился с ошибкой.
В дистрибутив включены следующие SQL-скрипты:
| Имя скрипта | Назначение |
|---|---|
create_db_and_ts.sql | Создание пользовательского табличного пространства и базы данных. В качестве шаблона при создании базы данных берется стандартная системная база template1 |
create_end_as_admin_user.sql | Создание конечных пользователей группы as_admin |
create_end_as_TUZ_user.sql | Создание конечных пользователей группы as_TUZ |
create_roles.sql | Создание групповых ролей и служебных пользователей |
create_user_schema.sql | Создание пользовательской схемы |
functions.sql | Настройка прав доступа пользовательским функциям |
get_role_passwd.sql | Настройка функции get_role_passwd |
grants_common_db.sql | Общие для всех баз данных настройки привилегий |
grants_only_postgres_db.sql | Настройки привилегий в базе данных postgres |
grants_only_user_db.sql | Настройки привилегий в пользовательской базе данных |
revoke_public_template0.sql | Настройки привилегий роли public в базе данных template0.sql |
setting_pp_for_users.sql | Настройки парольных политик |
create_common_extensions.sql | Настройки расширений, общие для всех баз данных |
create_ext_only_postgres_db.sql | Настройки расширений в базе данных postgres |
create_pg_hint_plan.sql | Настройка расширения pg_hint_plan |
create_pg_outline.sql | Настройка расширения pg_outline |
create_pg_stat_kcache.sql | Настройка расширения pg_stat_kcache |
create_psql_rotate_password.sql | Настройка расширения psql_rotate_password |
create_schema_for_extensions.sql | Настройка схемы 'ext' |
create_pg_profile_ext.sql | Настройка расширения pg_profile |
users_db_grants_profile_tuz.sql | Настройка прав доступа для расширения pg_profile |
change_owner_for_profile_tables.sql | Настройка владельца функций расширения pg_profile |
common_grants_profile_tuz.sql | Настройка общих прав доступа для расширения pg_profile |
pg_audit_settings.sql | Настройка pgaudit.log для пользователей из ролевой модели |
Ansible-скрипты
Для упрощения развертывания ролевой модели была реализована Ansible-роль configure_roles, которая выполняет настройку ролевой модели, пользовательской БД и расширений автоматически. Выполнение данной роли предполагается после развертывания СУБД Pangolin с использованием playbook_configure_roles.yaml. В данном случае будет выполнена настройка ролевой модели, пользовательской БД и расширений после чистой установки Pangolin. Данная роль располагается в дистрибутиве по пути installer/scripts_external/configure_roles.
Роль configure_roles полностью автономна, может быть запущена вне компонента installer и имеет следующую структуру:
| Файл/директория | Назначение |
|---|---|
playbook_configure_roles.yaml | Основной Ansible-скрипт, выполняющий развертывание ролевой модели |
filter_plugins | Директория, содержащая фильтры для использования внутри роли configure_roles |
templates | Директория, содержащая запускаемые SQL-скрипты (раздел «SQL-скрипты» данного руководства) для развертывания ролевой модели, пользовательской БД и расширений |
tasks | Директория, содержащая yaml-скрипты для развертывания ролевой модели |
group_vars | Директория, содержащая переменные, используемые ролью для развертывания ролевой модели |
library | Директория, содержащая бинарный файл генератора паролей password_generator |
Структура файлов с переменными имеет следующий вид:
| Файл | Назначение |
|---|---|
all.yml | Файл с общими параметрами для роли configure_roles |
message.yml | Файл с сообщениями, которые используются в процессе выполнения роли configure_roles |
variables.yml | Файл с переменными, используемыми для корректировки настраиваемой ролевой модели |
Ansible-роль configure_roles используется при инсталляции для настройки ролевой модели.
Управление
Переназначение прав для непривилегированных пользователей
В СУБД Pangolin возможно переназначение прав на определенные файлы, службы и директории таким образом, чтобы непривилегированные пользователи могли управлять ими без необходимости повышения прав.
Реализованный механизм переназначения прав также позволяет непривилегированному пользователю восстанавливать ряд компонентов в случае неудачного обновления.
Процесс отказа от использования пользователя root в эксплуатации направлен на снижение зависимости системы от привилегированного доступа. Это позволит сократить количество операций, требующих вмешательства администратора, и упростит работу системы в целом.
Особенности реализации
После внедрения возможности переназначения прав, объем команд, указанных в файле sudoers, будет сокращен, так как часть функциональностей перестанет требовать выполнения от имени привилегированного пользователя. Таким образом, эксплуатация системы станет более безопасной и удобной, а риск ошибок при использовании привилегированных учетных записей снизится.
В текущей реализации установки Pangolin все юнит-файлы компонентов размещаются по пути /lib/systemd/system/. Это означает, что без использования прав суперпользователя редактировать или восстанавливать данные файлы невозможно. При ручном восстановлении стенда после неудачного обновления некоторые операции также требуют прав администратора, что может вызывать дополнительные сложности и повышать вероятность ошибок.
В рамках новой функциональности предполагается изменить пути расположения сервисных файлов (/home/user_name/.config/systemd/user/), а так же владельцев (owner:group) для ряда файлов, которые ранее требовали доступа от имени привилегированного пользователя. После этих изменений восстановление и обслуживание сервисных файлов станет возможным без необходимости использования root, что повысит гибкость, безопасность и удобство эксплуатации системы.
Целью реализации данной функциональности является уменьшение использования привилегированного пользователя при работе с функциональностями СУБД Pangolin, а так же манипуляций при эксплуатации.
Настройка
Параметр systemctl_unit_on_user конфигурационного файла утилиты установки отвечает за расположение unit-файлов компонентов Pangolin в пользовательской директории postgres и kmadmin_pg. Если данный параметр будет включен, то установка unit-файлов компонентов производится в директорию /home/user_name/.config/systemd/user. В случае, когда параметр выключен, установка производится в системную директорию сервисов /lib/systemd/system/, а для редактирования и управления файлами необходимы права привилегированного пользователя.
После создания пользователей kmadmin_pg и postgres необходимо выполнить команды:
loginctl enable-linger postgres
loginctl enable-linger kmadmin_pg
Запуск будет осуществляться за счет добавления в .bash_profile пользовательских окружений postgres и kmadmin_pg следующих переменных:
export XDG_RUNTIME_DIR=/run/user/$(id -u)
export DBUS_SESSION_BUS_ADDRESS="unix:path=${XDG_RUNTIME_DIR}/bus"
Для запуска/остановки/перезагрузки службы при вызове systemctl утилиты требуется дополнительный аргумент --user:
systemctl --user start postgresql
systemctl --user stop postgresql
systemctl --user restart postgresql
В зависимости от включения функциональности видоизменяется unit-файл компонентов.
Пример включенной функциональности с расположением unit-файла в пользовательском каталоге:
[Unit]
Description=Runners to orchestrate a high-availability PostgreSQL
After=syslog.target network.target
[Service]
Type=simple
# Read in configuration file if it exists, otherwise proceed
Environment="PG_LICENSE_PATH=/opt/pangolin_license"
Environment="PG_LD_LIBRARY_PATH=/opt/pangolin-dbms/lib"
Environment="PG_PLUGINS_PATH=/opt/pangolin-dbms/lib"
Environment="PATRONI_PLUGINS_PATH=/opt/pangolin-manager/lib/postgresql_se_libs"
Environment="LD_LIBRARY_PATH=/opt/pangolin-manager/lib/postgresql_se_libs"
Environment="PYTHONPATH=/opt/pangolin-manager/lib/python3/site-packages:/opt/pangolin-manager/lib64/python3/site-packages:/opt/pangolin-manager/lib/python3.6/site-packages:/opt/pangolin-manager/lib64/python3.6/site-packages"
LimitNOFILE=65536
# Pre-commands to start watchdog device
# Uncomment if watchdog is part of your patroni setup
PermissionsStartOnly=true
ExecStartPre=-/bin/mkdir -p /run/user/1004/postgresql
ExecStartPre=/bin/chown -R postgres:postgres /run/user/1004/postgresql
ExecStartPre=-/bin/mkdir -p /run/user/1004/pangolin-dbms
ExecStartPre=/bin/chown -R postgres:postgres /run/user/1004/pangolin-dbms
ExecReload=/bin/kill -HUP $MAINPID
WorkingDirectory=/opt/pangolin-manager
ExecStart=/opt/pangolin-manager/bin/pangolin-manager-bin/pangolin-manager.bin /etc/pangolin-manager/postgres.yml
Restart=on-failure
KillMode=process
# Disable restart limits
StartLimitInterval=0
[Install]
WantedBy=default.target
Пример файла sudoerc при включенной функциональности:
postgres ALL=(ALL) NOPASSWD: /usr/bin/systemctl daemon-reload
postgres ALL=(ALL) NOPASSWD: /usr/bin/systemctl stop rsyslog
postgres ALL=(ALL) NOPASSWD: /usr/bin/systemctl start rsyslog
postgres ALL=(ALL) NOPASSWD: /usr/bin/systemctl restart rsyslog
postgres ALL=(ALL) NOPASSWD: /usr/bin/systemctl status rsyslog
postgres ALL=(ALL) NOPASSWD: /usr/bin/systemctl status rsyslog -l
postgres ALL=(ALL) NOPASSWD: /usr/bin/systemctl status rsyslog --no-pager --full
postgres ALL=(ALL) NOPASSWD: /usr/bin/systemctl enable rsyslog
postgres ALL=(ALL) NOPASSWD: /usr/bin/systemctl disable rsyslog
postgres ALL=(ALL) NOPASSWD: /bin/journalctl -u rsyslog
postgres ALL=(ALL) NOPASSWD: /usr/bin/systemctl stop etcd
postgres ALL=(ALL) NOPASSWD: /usr/bin/systemctl start etcd
postgres ALL=(ALL) NOPASSWD: /usr/bin/systemctl restart etcd
postgres ALL=(ALL) NOPASSWD: /usr/bin/systemctl status etcd
postgres ALL=(ALL) NOPASSWD: /usr/bin/systemctl status etcd -l
postgres ALL=(ALL) NOPASSWD: /usr/bin/systemctl status etcd --no-pager --full
postgres ALL=(ALL) NOPASSWD: /usr/bin/systemctl enable etcd
postgres ALL=(ALL) NOPASSWD: /usr/bin/systemctl disable etcd
postgres ALL=(ALL) NOPASSWD: /bin/journalctl -u etcd
Файл sudoerc при выключенной функциональности:
postgres ALL=(ALL) NOPASSWD: /usr/bin/systemctl daemon-reload
postgres ALL=(ALL) NOPASSWD: /usr/bin/systemctl stop rsyslog
postgres ALL=(ALL) NOPASSWD: /usr/bin/systemctl start rsyslog
postgres ALL=(ALL) NOPASSWD: /usr/bin/systemctl restart rsyslog
postgres ALL=(ALL) NOPASSWD: /usr/bin/systemctl status rsyslog
postgres ALL=(ALL) NOPASSWD: /usr/bin/systemctl status rsyslog -l
postgres ALL=(ALL) NOPASSWD: /usr/bin/systemctl status rsyslog --no-pager --full
postgres ALL=(ALL) NOPASSWD: /usr/bin/systemctl enable rsyslog
postgres ALL=(ALL) NOPASSWD: /usr/bin/systemctl disable rsyslog
postgres ALL=(ALL) NOPASSWD: /bin/journalctl -u rsyslog
postgres ALL=(ALL) NOPASSWD: /bin/journalctl -u pangolin-certs-rotate
postgres ALL=(ALL) NOPASSWD: /usr/bin/systemctl stop pangolin-certs-rotate
postgres ALL=(ALL) NOPASSWD: /usr/bin/systemctl reload pangolin-certs-rotate
postgres ALL=(ALL) NOPASSWD: /usr/bin/systemctl start pangolin-certs-rotate
postgres ALL=(ALL) NOPASSWD: /usr/bin/systemctl restart pangolin-certs-rotate
postgres ALL=(ALL) NOPASSWD: /usr/bin/systemctl status pangolin-certs-rotate
postgres ALL=(ALL) NOPASSWD: /usr/bin/systemctl status pangolin-certs-rotate --no-pager --full
postgres ALL=(ALL) NOPASSWD: /usr/bin/systemctl enable pangolin-certs-rotate
postgres ALL=(ALL) NOPASSWD: /usr/bin/systemctl disable pangolin-certs-rotate
postgres ALL=(ALL) NOPASSWD: /usr/bin/systemctl status pangolin-certs-rotate -l
postgres ALL=(ALL) NOPASSWD: /bin/journalctl -u pangolin_reencrypt@postgres
postgres ALL=(ALL) NOPASSWD: /usr/bin/systemctl stop pangolin_reencrypt@postgres
postgres ALL=(ALL) NOPASSWD: /usr/bin/systemctl start pangolin_reencrypt@postgres
postgres ALL=(ALL) NOPASSWD: /usr/bin/systemctl restart pangolin_reencrypt@postgres
postgres ALL=(ALL) NOPASSWD: /usr/bin/systemctl status pangolin_reencrypt@postgres
postgres ALL=(ALL) NOPASSWD: /usr/bin/systemctl status pangolin_reencrypt@postgres --no-pager --full
postgres ALL=(ALL) NOPASSWD: /usr/bin/systemctl enable pangolin_reencrypt@postgres
postgres ALL=(ALL) NOPASSWD: /usr/bin/systemctl disable pangolin_reencrypt@postgres
postgres ALL=(ALL) NOPASSWD: /usr/bin/systemctl status pangolin_reencrypt@postgres -l
postgres ALL=(ALL) NOPASSWD: /usr/bin/systemctl stop pgbouncer
postgres ALL=(ALL) NOPASSWD: /usr/bin/systemctl start pgbouncer
postgres ALL=(ALL) NOPASSWD: /usr/bin/systemctl restart pgbouncer
postgres ALL=(ALL) NOPASSWD: /usr/bin/systemctl reload pgbouncer
postgres ALL=(ALL) NOPASSWD: /usr/bin/systemctl status pgbouncer
postgres ALL=(ALL) NOPASSWD: /usr/bin/systemctl status pgbouncer --no-pager --full
postgres ALL=(ALL) NOPASSWD: /usr/bin/systemctl enable pgbouncer
postgres ALL=(ALL) NOPASSWD: /usr/bin/systemctl disable pgbouncer
postgres ALL=(ALL) NOPASSWD: /usr/bin/systemctl status pgbouncer -l
postgres ALL=(ALL) NOPASSWD: /bin/journalctl -u pgbouncer
postgres ALL=(ALL) NOPASSWD: /usr/bin/systemctl stop pangolin-pooler
postgres ALL=(ALL) NOPASSWD: /usr/bin/systemctl start pangolin-pooler
postgres ALL=(ALL) NOPASSWD: /usr/bin/systemctl restart pangolin-pooler
postgres ALL=(ALL) NOPASSWD: /usr/bin/systemctl reload pangolin-pooler
postgres ALL=(ALL) NOPASSWD: /usr/bin/systemctl status pangolin-pooler
postgres ALL=(ALL) NOPASSWD: /usr/bin/systemctl status pangolin-pooler --no-pager --full
postgres ALL=(ALL) NOPASSWD: /usr/bin/systemctl enable pangolin-pooler
postgres ALL=(ALL) NOPASSWD: /usr/bin/systemctl disable pangolin-pooler
postgres ALL=(ALL) NOPASSWD: /usr/bin/systemctl status pangolin-pooler -l
postgres ALL=(ALL) NOPASSWD: /bin/journalctl -u pangolin-pooler
postgres ALL=(ALL) NOPASSWD: /usr/bin/systemctl stop pangolin-manager
postgres ALL=(ALL) NOPASSWD: /usr/bin/systemctl start pangolin-manager
postgres ALL=(ALL) NOPASSWD: /usr/bin/systemctl restart pangolin-manager
postgres ALL=(ALL) NOPASSWD: /usr/bin/systemctl reload pangolin-manager
postgres ALL=(ALL) NOPASSWD: /usr/bin/systemctl status pangolin-manager
postgres ALL=(ALL) NOPASSWD: /usr/bin/systemctl status pangolin-manager -l
postgres ALL=(ALL) NOPASSWD: /usr/bin/systemctl status pangolin-manager --no-pager --full
postgres ALL=(ALL) NOPASSWD: /usr/bin/systemctl enable pangolin-manager
postgres ALL=(ALL) NOPASSWD: /usr/bin/systemctl disable pangolin-manager
postgres ALL=(ALL) NOPASSWD: /bin/journalctl -u pangolin-manager
postgres ALL=(ALL) NOPASSWD: /usr/bin/systemctl stop etcd
postgres ALL=(ALL) NOPASSWD: /usr/bin/systemctl start etcd
postgres ALL=(ALL) NOPASSWD: /usr/bin/systemctl restart etcd
postgres ALL=(ALL) NOPASSWD: /usr/bin/systemctl status etcd
postgres ALL=(ALL) NOPASSWD: /usr/bin/systemctl status etcd -l
postgres ALL=(ALL) NOPASSWD: /usr/bin/systemctl status etcd --no-pager --full
postgres ALL=(ALL) NOPASSWD: /usr/bin/systemctl enable etcd
postgres ALL=(ALL) NOPASSWD: /usr/bin/systemctl disable etcd
postgres ALL=(ALL) NOPASSWD: /bin/journalctl -u etcd
Главное отличие журнала sudoerc при выключенной функциональности относительно выключенного состояния является меньшее количество команд, требующих прав привилегированного пользователя, как следствие меньший объем журнала. Это связано с тем, что при включенной функциональности unit-файлы находятся в пользовательском каталоге, для которого дополнительные привилегии не требуются.
Изменения в .bash_profile:
alias members='ETCDCTL_API=3 etcdctl --endpoints=<server_name>:<port> --cert="/pg_ssl/etcd.crt" --key="/pg_ssl/etcd.key" --cacert="/pg_ssl/root.crt" member list -w table'
alias elist='ETCDCTL_API=3 etcdctl --endpoints=<server_name>:<port> --cert="/pg_ssl/etcd.crt" --key="/pg_ssl/etcd.key" --cacert="/pg_ssl/root.crt" endpoint status -w table --cluster'
alias elog='journalctl --user-unit etcd'
alias health='ETCDCTL_API=2 etcdctl --endpoints https://<server_name>:<port> --cert-file /pg_ssl/etcd.crt --key-file /pg_ssl/etcd.key --ca-file /pg_ssl/root.crt cluster-health 2>&1'
export PG_LICENSE_PATH=/opt/pangolin_license
export LD_LIBRARY_PATH=/usr/pangolin-{version}/lib
export PATH=$PATH:/usr/pangolin-{version}/bin
export PG_PLUGINS_PATH=/usr/pangolin-{version}/lib
export PGHOME=/usr/pangolin-{version}
export PGDATABASE=postgres
export PGUSER=postgres
export PGHOST={IP-адрес}
export PGPORT={Порт}
export PGCLIENTENCODING=UTF8
NOW=$(date +"%Y-%m-%d")
export PGDATA=/pgdata/{version}/data
export MANPATH=$MANPATH:$PGHOME/share/man
alias errors="ls -t /pgerrorlogs/{version}/postgresql-$NOW*.log | head -1 | xargs tail -F | grep -E 'WARNING|ERROR|FATAL|ПРЕДУПРЕЖДЕНИЕ|ОШИБКА|ВАЖНО'"
alias hba='vim $PGDATA/pg_hba.conf'
alias pglog='ls -t /pgerrorlogs/{version}/postgresql-$NOW*.log | head -1 | xargs tail -300'
alias pgver="psql -c 'select version();' | sed \"s| on | (\$(psql --single-line --no-align -c 'select product_version();' | sed '2q;d' )) on |\""
export XDG_RUNTIME_DIR=/run/user/$(id -u)
export DBUS_SESSION_BUS_ADDRESS="unix:path=${XDG_RUNTIME_DIR}/bus"
export PATH=$PATH:/opt/pangolin-manager/bin/
umask 022
export PATH=$PATH:/opt/pangolin-manager/bin/
export CLNAME=clustername
alias fail='pangolin-manager-ctl -c /etc/pangolin-manager/postgres.yml failover $CLNAME'
alias hist='pangolin-manager-ctl -c /etc/pangolin-manager/postgres.yml history $CLNAME'
alias list='pangolin-manager-ctl -c /etc/pangolin-manager/postgres.yml list $CLNAME'
alias pgconfig='curl -s -m 3 https://<server_name>:<port>/config | jq'
alias ptlog='journalctl --user-unit pangolin-manager.service'
alias ptver="pangolin-manager-ctl version"
alias reload='pangolin-manager-ctl -c /etc/pangolin-manager/postgres.yml reload $CLNAME'
alias restart='pangolin-manager-ctl -c /etc/pangolin-manager/postgres.yml restart $CLNAME'
alias status='sudo systemctl status pangolin-manager --no-pager --full'
alias switch='pangolin-manager-ctl -c /etc/pangolin-manager/postgres.yml switchover $CLNAME'
Пример включения функциональности:
sudo SYSTEMD_UNIT_IN_USER=true yum install pangolin-manager-venv
sudo SYSTEMD_UNIT_IN_USER=true yum install pangolin-manager
Для Pangolin Manager журнал логирования из journalctl перенаправляется в файл, а также добавляется ротация удаления данных файлов. Путь к хранимым логам будет расположен по пути логирования pangolin-dbms:
log:
dir: /pgerrorlogs/major_version/
file_size: 26214400
file_num: 4
Ограничения
Ограничения функциональности:
-
Для некоторых файлов владелец (owner) не сможет быть изменен на
postgres:postgres(например, для/etc/pangolin-auth-reencrypt/enc_util.cfg, так как данный файл отвечает за хранилище паролей и не может быть изменен пользователем). -
В процессе обновления продукта до конечной версии, сервисные файлы не будут переноситься в пользовательский каталог при включении параметра
systemctl_unit_on_user. Их расположение не изменится. -
Для чтения журнала
journalctlнужно будет отдельно от утилиты установки/обновления Pangolin добавлять пользовательскую группуsystemd-journal:usermod -aG systemd-journal postgres;usermod -aG systemd-journal kmadmin_pg.
-
Расположение
pid-файлов компонентов ограничено пользовательской директорией/var/run/user/$(id -u)/. -
Компонент
etcdне будет изменять расположение службы.