H.1. ldap2pg#
H.1. ldap2pg #
- H.1.1. О ldap2pg
- H.1.2. Особенности
- H.1.3. Установка
- H.1.4. Интерфейс командной строки
- H.1.5. ldap2pg.yml файл справка
- H.1.6. Проверка кластера Postgres
- H.1.7. Управление ролями
- H.1.8. Запрос каталога с помощью LDAP
- H.1.9. Управление привилегиями
- H.1.10. Встроенные привилегии
- H.1.11. Кулинарная книга
- H.1.12. Вклад
- H.1.13. Поддержка
- H.1.14. Авторы
Postgres может проверять пароль существующей роли с использованием протокола LDAP из коробки. ldap2pg автоматизирует создание, обновление и удаление ролей и пользователей PostgreSQL из корпоративного каталога.
Управление ролями близко к управлению привилегиями, так как вы ожидаете, что роли будут иметь надлежащие привилегии по умолчанию. ldap2pg также может предоставлять и отзывать привилегии.

H.1.2. Особенности #
Считывает настройки из расширенного конфигурационного файла YAML.
Создает, изменяет и удаляет роли PostgreSQL из поисков LDAP.
Создает статические роли из YAML для завершения записей LDAP.
Управляет родительскими ролями (псевдоним группы).
Предоставляет или отзывает привилегии статически или из записей LDAP.
Пробный запуск, режим проверки.
Регистрирует поисковые запросы LDAP как команды
ldapsearch(1)
.Логирует каждое SQL-выражение.
ldap2pg
лицензирован под
лицензией PostgreSQL.
ldap2pg требует файл конфигурации с именем ldap2pg.yaml
. Проект поставляется с
проверенным
ldap2pg.yml в качестве отправной точки.
ldap2pg
работает с
OpenLDAP,
FreeIPA, Oracle
Internet Directory и Microsoft Active Directory.
H.1.3. Установка #
H.1.3.1. Требования #
ldap2pg выпускается как бинарный файл Go без требований.
Во время выполнения ldap2pg требуется непривилегированная роль с
опциями CREATEDB
и CREATEROLE
или доступ суперпользователя. ldap2pg не требует запуска
на том же хосте, что и синхронизируемый кластер PostgreSQL.
С 2 МиБ ОЗУ и одним vCPU, ldap2pg может синхронизировать несколько тысяч ролей за секунды, в зависимости от времени отклика экземпляра PostgreSQL и каталога LDAP.
H.1.3.2. Установка бинарных файлов #
Скачайте бинарный файл для вашей целевой системы и архитектуры с страницы релизов ldap2pg.
Переместите бинарный файл в
/usr/local/bin
.Убедитесь, что он исполняемый с
chmod 0755 /usr/local/bin/ldap2pg
.Проверьте установку с помощью
ldap2pg --version
.
H.1.3.3. Использование yum/dnf #
На RHEL и совместимых клонах, репозиторий Dalibo Labs YUM предлагает RPM-пакет для ldap2pg.
Для использования упаковки Dalibo Labs:
Установите пакет
ldap2pg
с помощью yum:yum install ldap2pg
H.1.4. Интерфейс командной строки #
ldap2pg пытается быть дружелюбным в отношении конфигурации и совместимым с psql, утилитами OpenLDAP и приложениями 12 факторов. ldap2pg считывает свою конфигурацию из нескольких источников в следующем порядке, первый имеет приоритет:
аргументы командной строки.
переменные окружения.
файл конфигурации.
ldaprc, ldap.conf, и т.д.
Переключатель --help
показывает обычную онлайн-документацию
для аргументов командной строки. Начиная с версии 5.7, это выглядит
так:
$ ldap2pg --help usage: ldap2pg [OPTIONS] [dbname] --check Check mode: exits with 1 if Postgres instance is unsynchronized. --color Force color output. -c, --config string Path to YAML configuration file. Use - for stdin. -?, --help Show this help message and exit. (default true) -q, --quiet count Decrease log verbosity. -R, --real Real mode. Apply changes to Postgres instance. -P, --skip-privileges Turn off privilege synchronisation. -v, --verbose count Increase log verbosity. -V, --version Show version and exit. (default true) Optional argument dbname is alternatively the database name or a conninfo string or an URI. See man psql(1) for more information. By default, ldap2pg runs in dry mode. ldap2pg requires a configuration file to describe LDAP searches and mappings. See https://ldap2pg.readthedocs.io/en/latest/ for further details.
Аргументы могут быть определены несколько раз. В случае конфликта используется последний аргумент.
H.1.4.1. Переменные окружения #
ldap2pg не имеет переключателя CLI для настройки подключения Postgres.
Однако, ldap2pg поддерживает libpq
переменные окружения PG*.
См. psql(1) для получения подробной информации о переменных окружения libpq.
То же самое касается LDAP, ldap2pg поддерживает стандартные
LDAP*
переменные окружения и файлы ldaprc
.
См. ldap.conf(5)
для получения дополнительной информации
о том, как настроить. ldap2pg принимает одну дополнительную переменную:
LDAPPASSWORD
.
ldap2pg загружает файл .env
в родительском каталоге lda2pg.yml, если он существует.
Используйте true
или false
для
булевых значений в окружении.
например, LDAP2PG_SKIPPRIVILEGES=true
.
Подсказка
Проверьте соединение Postgres, используя psql(1)
и LDAP, используя ldapwhoami(1)
, ldap2pg будет в порядке, и позже будет легче отлаживать настройку и конфигурацию.
H.1.4.2. Настройка ведения журнала #
ldap2pg имеет несколько уровней ведения журнала:
ERROR
: детали ошибки. Когда это происходит, ldap2pg завершится с ошибкой.WARNING
: ldap2pg предупреждает о выборах, о которых вы должны знать.CHANGE
: только изменения, примененные к кластеру Postgres. (также известный как уровень Magnus Hagander).INFO
(по умолчанию): сообщает, что делает ldap2pg, особенно перед длительной задачей.DEBUG
: все, включая необработанные SQL-запросы, поиски LDAP и детали интроспекции.
Параметры --quiet
и --verbose
соответственно уменьшают и увеличивают подробность.
Вы можете выбрать самый высокий уровень подробности с помощью
переменной окружения LDAP2PG_VERBOSITY
. Например:
$ LDAP2PG_VERBOSITY=DEBUG ldap2pg 12:23:45 INFO Starting ldap2pg version=v6.0-alpha5 runtime=go1.21.0 commit=<none> 12:23:45 WARN Running a prerelease! Use at your own risks! 12:23:45 DEBUG Searching configuration file in standard locations. 12:23:45 DEBUG Found configuration file. path=./ldap2pg.yml $
Вывод ldap2pg варьируется в зависимости от того, работает ли он с TTY или нет. Если стандартная ошибка является TTY, ведение журнала окрашивается и настраивается для чтения человеком. В противном случае формат ведения журнала является чистым logfmt, для обработки машиной. Вы можете принудительно включить вывод, удобный для чтения человеком, используя переключатель CLI --color
.
H.1.5. ldap2pg.yml файл справка #
ldap2pg требует YAML файл конфигурации, обычно называемый
ldap2pg.yml
и помещаемый в рабочий каталог.
Все можно настроить из YAML файла: запросы инспекции Postgres,
поиски LDAP, привилегии и карта синхронизации.
Предупреждение
ldap2pg требуется файл конфигурации, в котором описана карта синхронизации.
H.1.5.1. Расположение файла #
ldap2pg ищет файл конфигурации в следующем порядке:
ldap2pg.yml
в текущем рабочем каталоге.~/.config/ldap2pg.yml
./etc/ldap2pg.yml
./etc/ldap2pg/ldap2pg.yml
.
Если установлены LDAP2PG_CONFIG
или
--config
, ldap2pg пропускает поиск
стандартных местоположений файлов. Вы можете указать -
, чтобы
читать конфигурацию из стандартного ввода. Это полезно для передачи
ldap2pg динамической конфигурации.
H.1.5.2. Структура файла #
ldap2pg.yml
разделен на несколько секций:
postgres
: настройка соединения с Postgres и запросы для инспекции.privileges
: определение профилей привилегий.rules
: список LDAP-поисков и соответствующее сопоставление с ролями и правами.
Проект предоставляет простой, хорошо прокомментированный ldap2pg.yml, протестированный на CI. Если вы не знаете, с чего начать, это хорошая отправная точка.
Примечание
Если у вас возникли проблемы с поиском правильной конфигурации для ваших нужд, не стесняйтесь создать запрос для получения помощи.
H.1.5.2.1. О YAML #
YAML является супермножеством JSON. Документ JSON является допустимым документом YAML. YAML - это очень свободный формат, где отступы имеют значение.
В файле ldap2pg.yaml
вы, вероятно, будете использовать
подстановочные знаки для шаблона glob и фигурные скобки для вставки
атрибутов LDAP. Позаботьтесь о защите этих символов с помощью
кавычек.
H.1.5.3. Параметры Postgres #
Раздел postgres
определяет пользовательские SQL
запросы для инспекции Postgres.
Секция postgres
содержит несколько
параметров *_query
. Эти параметры могут быть
либо строкой, содержащей SQL-запрос, либо YAML-списком для возврата
статического списка значений, пропуская выполнение запроса на
кластере PostgreSQL.
H.1.5.3.1. databases_query
#
SQL-запрос для перечисления имен баз данных в кластере. По умолчанию, ldap2pg ищет базы данных, к которым он может подключиться, и он может переназначать объекты своему владельцу. ldap2pg перебирает базы данных, чтобы переназначить объекты перед удалением роли. ldap2pg управляет привилегиями в каждой базе данных.
postgres: databases_query: "SELECT datname FROM pg_catalog.pg_databases;" # OR databases_query: [mydb]
Примечание
Настройка _query параметра с YAML списком пропускает запрос к кластеру для инспекции и заставляет ldap2pg использовать статическое значение.
H.1.5.3.2. fallback_owner
#
Имя роли, принимающей на себя владение базой данных удаленной роли.
Прежде чем удалить роль, ldap2pg переназначает объекты и очищает ACL. ldap2pg начинает с переназначения владельца базы данных целевым пользователем. Новый владелец базы данных — это резервный владелец. Другие объекты переназначаются каждому владельцу базы данных.
H.1.5.3.3. managed_roles_query
#
SQL-запрос для отображения имени управляемых ролей.
ldap2pg ограничивает удаление ролей и редактирование привилегий
управляемыми ролями. Обычно этот запрос возвращает дочерние элементы
специальной группы, такой как ldap_roles
. По
умолчанию ldap2pg управляет всеми ролями, к которым у него есть доступ.
public
является специальной встроенной ролью в
Postgres. Если managed_roles_query
возвращает
роль public
в списке, ldap2pg будет
управлять привилегиями на public
. По умолчанию,
ldap2pg управляет привилегиями public
.
Следующий пример показывает, как настроить ldap2pg для управления
ролью public
, ldap_roles
и любыми членами ldap_roles
:
postgres: managed_roles_query: | VALUES ('public'), ('ldap_roles') UNION SELECT DISTINCT role.rolname FROM pg_roles AS role JOIN pg_auth_members AS ms ON ms.member = role.oid JOIN pg_roles AS parent ON parent.rolname = 'ldap_roles' AND parent.oid = ms.roleid ORDER BY 1;
H.1.5.3.4. roles_blacklist_query
#
SQL-запрос, возвращающий имя и глобальный шаблон для добавления роли в черный список
из управления. ldap2pg не будет касаться этих
ролей. Значение по умолчанию [postgres, pg_*]
.
ldap2pg добавляет в черный список самого пользователя.
postgres: roles_blacklist_query: - postgres - "pg_*" - "rds_*"
Предупреждение
Имейте в виду, что *foo
является ссылкой YAML.
Вы должны заключить в кавычки шаблон, начинающийся с *
.
H.1.5.3.5. schemas_query
#
SQL-запрос, возвращающий имя управляемых схем в
базе данных. ldap2pg выполняет этот запрос для каждой базы данных,
возвращенной databases_query
, только если
ldap2pg управляет привилегиями. ldap2pg перебирает объекты в этих
схемах при проверке GRANTs в кластере.
postgres: schemas_query: | SELECT nspname FROM pg_catalog.pg_namespace
H.1.5.4. Раздел Привилегии PostgreSQL #
Верхний уровень секции privileges
является отображением,
определяющим профили привилегий, на которые ссылаются позже в
правиле предоставления карты синхронизации. Профиль привилегий
представляет собой список, содержащий либо ссылку на тип привилегии в
ACL Postgres, либо другой профиль. Профиль привилегий может включать
другой профиль рекурсивно. См. раздел
Управление привилегиями
для получения подробной информации.
privileges: reading: - default: global type: SELECT on: TABLES writing: - reading - default: global type: SELECT on: TABLES
Профиль привилегий, имя которого начинается с _
,
неактивен, если не включен в активный профиль.
H.1.5.4.1. default
#
Определяет область действия привилегий по умолчанию. Может быть неопределенной или
либо global
, либо schema
.
Область global
ссылается на привилегии по умолчанию
для любых схем, включая будущие схемы.
Область schema
ссылается на привилегии по умолчанию
для конкретных схем. Целевая схема определяется
правилом предоставления.
privileges: reading: - default: global type: SELECT on: TABLES
H.1.5.4.2. type
#
Тип привилегии, как описано в Раздел 5.7 например, SELECT, REFERENCES, USAGE и т.д.
privileges: reading: - type: USAGE on: SCHEMAS
H.1.5.4.3. on
#
Целевой ACL типа привилегии. например, TABLES, SEQUENCES, SCHEMAS,
и т.д. Обратите внимание на особые случаи ALL TABLES
,
ALL SEQUENCES
, и т.д. См. документацию
Управление привилегиями
для подробностей.
privileges: reading: - type: SELECT on: ALL TABLES
H.1.5.5. Правила синхронизации #
Верхний уровень секции rules
является списком YAML. Это единственный обязательный параметр в ldap2pg.yaml
. Каждый элемент rules
называется mapping. Mapping является словарем YAML с любым из подразделов role
или grant
. Mapping может опционально иметь поле description
и секцию ldapsearch
.
rules: - description: "Define DBA roles" ldapsearch: base: ... roles: - name: "{cn}" options: LOGIN SUPERUSER
Подраздел ldapsearch
является необязательным. Вы
можете определять роли и предоставлять права без запроса к каталогу.
H.1.5.5.1. description
#
Свободная строка, используемая для ведения журнала. Этот параметр не принимает вставку параметров mustache.
H.1.5.5.2. ldapsearch
#
Эта директива определяет параметры поиска LDAP. Она названа в честь утилиты командной строки ldapsearch, поставляемой проектом OpenLDAP. Её поведение должно быть в основном таким же.
Примечание
Эта документация называет LDAP-запрос поиском, в то время как слово запрос зарезервировано для SQL-запроса.
ldapsearch
директивы позволяют и требуют
внедрения атрибутов LDAP в правила role
и
grant
с использованием фигурных скобок. См.
Поиск в каталоге для
подробностей.
H.1.5.5.2.1. base
, scope
and
filter
#
Эти параметры имеют то же значение, определение и значение по умолчанию, что и аргументы searchbase, scope и filter утилиты командной строки ldapsearch.
rules: - ldapsearch: base: ou=people,dc=acme,dc=tld scope: sub filter: > (& (member=*) (cn=group_*) )
H.1.5.5.2.2. joins
#
Настраивает подпоиски LDAP. Раздел joins
является словарем, где имя атрибута является ключом, а параметры
поиска LDAP - значением. Параметры поиска LDAP такие же, как и для основного поиска LDAP.
rules: - ldapsearch: joins: member: filter: ... scope: ... role: - name: "{member.sAMAccountName}"
База поиска подпоиска — это значение
атрибута ссылки, например, каждое значение
member
. Вы не можете настроить
атрибут base
подпоиска. Точно так же
ldap2pg выводит атрибуты подпоисков из
правил role
и grant
.
Вы можете иметь только один подпоиск на один поиск верхнего уровня.
Вы не можете выполнять под-подпоиск.
См. Поиск в каталоге для получения подробной информации.
Примечание
Выполнение подпоиска для каждой записи набора результатов может быть очень ресурсоемким.
Вы можете оптимизировать запрос, используя специальный фильтр поиска LDAP, такой как memberOf
.
Обратитесь к администратору вашего LDAP каталога и документации для получения подробной информации.
H.1.5.5.3. role
#
Определяет правило для описания одной или нескольких ролей, необходимых в
целевом кластере Postgres. Это включает имя, параметры, конфигурацию,
комментарий и членство. Множественная форма roles
допустима. Значение может быть либо одним правилом роли, либо списком
правил ролей.
rules: - role: name: dba options: SUPERUSER LOGIN - roles: - name: group0 options: NOLOGIN - name: group1 options: NOLOGIN
H.1.5.5.3.1. comment
#
Определяет SQL комментарий роли. Значение по умолчанию
Managed by ldap2pg
. Принимает инъекцию атрибута LDAP.
В случае инъекции атрибутов LDAP, вы должны позаботиться о том, сколько комбинаций будет сгенерировано. Если шаблон генерирует один комментарий, ldap2pg скопирует комментарий для каждой роли, сгенерированной по правилу роли. Если шаблон генерирует несколько комментариев, ldap2pg связывает имя и комментарий. Если сгенерировано больше или меньше комментариев, чем имен, ldap2pg завершится с ошибкой.
Следующий пример определяет статический комментарий, общий для всех сгенерированных ролей:
rules: - roles: names: - alice - bob comment: "Static roles from YAML."
Следующий пример генерирует один комментарий из отличительного имени записи LDAP, скопированный для всех созданных ролей:
rules: - ldapsearch: ... role: name: "{cn}" comment: "Generated from LDAP entry {dn}."
Следующий пример генерирует уникальный комментарий для каждой созданной роли:
rules: - ldapsearch: ... role: name: "{member.cn}" comment: "Generated from LDAP entry {member}."
Подсказка
Если роль определена несколько раз, родители объединяются. Другие поля сохраняются такими, как они были объявлены в первом определении роли.
H.1.5.5.3.2. name
#
Имя требуемой роли в кластере. Значение может быть
либо одной строкой, либо списком строк. Множественная форма
names
допустима. Вы можете вставлять атрибуты LDAP
в имя, используя фигурные скобки. Когда определено несколько имен,
новая роль определяется для каждого имени, каждое с
одинаковыми атрибутами, такими как options
и
parents
. Параметр comment
имеет особую обработку, см.
выше.
rules: - roles: name: "my-role-name"
При внедрении атрибута LDAP в имя, каждое значение атрибута LDAP каждой записи LDAP будет определять новую роль. Когда в формате определено несколько атрибутов LDAP, генерируются все комбинации атрибутов.
ldap2pg защищает имя роли двойными кавычками в целевом кластере Postgres. Сохранение регистра, пробелы допускаются (даже если это действительно плохая идея).
ldap2pg применяет roles_blacklist_query к этому параметру.
H.1.5.5.3.3. options
#
Определяет параметры роли PostgreSQL. Может быть строкой, похожей на SQL, или словарем YAML. Допустимые параметры: BYPASSRLS
, CONNECTION LIMIT
, LOGIN
, CREATEDB
, CREATEROLE
, INHERIT
, REPLICATION
и SUPERUSER
. Доступные параметры зависят от версии целевого кластера PostgreSQL и привилегий пользователя ldap2pg.
- roles: - name: my-dba options: LOGIN SUPERUSER - name: my-group options: LOGIN: no INHERIT: yes
H.1.5.5.3.4. config
#
Определяет параметры конфигурации PostgreSQL, которые будут установлены для роли. Должен быть словарем YAML. Доступные параметры конфигурации варьируются в зависимости от версии целевого кластера PostgreSQL. Некоторые параметры требуют привилегий суперпользователя для установки. ldap2pg завершится с ошибкой, если у него нет привилегий для установки параметра конфигурации.
- roles: - name: my-db-writer config: log_statement: mod log_min_duration_sample: 100
Установка config
в null
(по умолчанию) отключит функцию для роли. Если
config
является словарем, ldap2pg удалит
параметр, установленный в кластере, но не определенный в YAML ldap2pg. Чтобы
сбросить все параметры, установите config
в
пустой словарь, как показано ниже.
- roles: - name: reset-my-configuration config: {}
Обратите внимание, что атрибуты LDAP не расширяются в значениях конфигурации.
H.1.5.5.3.5. parent
#
Имя родительской роли. Допускается список имен. Допустима также форма множественного числа parents
. Родительская роль предоставляется с помощью GRANT ROLE parent TO role;
. Параметр parent
принимает ввод атрибутов LDAP с использованием фигурных скобок. ldap2pg применяет roles_blacklist_query к этому параметру. Родительской ссылкой могут быть локальные роли, не управляемые ldap2pg.
rules: - role: name: myrole parent: myparent
H.1.5.5.3.6. before_create
#
SQL фрагмент для выполнения перед созданием роли.
before_create
принимает внедрение атрибутов LDAP
с использованием фигурных скобок. Вы несете ответственность за экранирование
атрибута с помощью .identifier()
или
.string()
.
rules: - ldapsearch: ... role: name: "{cn}" before_create: "INSERT INTO log VALUES ({cn.string()})"
H.1.5.5.3.7. after_create
#
SQL фрагмент для выполнения после создания роли.
after_create
принимает внедрение атрибутов LDAP
с использованием фигурных скобок. Вы несете ответственность за экранирование
атрибута с помощью либо .identifier()
, либо
.string()
.
rules: - ldapsearch: ... role: name: "{sAMAccountName}" after_create: "CREATE SCHEMA {sAMAccountName.identifier()} AUTHORIZATION {sAMAccountName.identifier()}"
H.1.5.5.4. grant
#
Определяет предоставление привилегии роли с соответствующими
параметрами. Может быть отображением или списком отображений. Множественная форма
grants
также допустима.
rules: - grant: privilege: reader databases: __all__ schema: public role: myrole
H.1.5.5.4.1. database
#
Ограничьте грант одной или несколькими базами данных. Может быть список
имен. Множественная форма databases
допустима.
Специальное значение __all__
расширяется до всех
управляемых баз данных, как возвращено
databases_query.
По умолчанию __all__
. Гранты, найденные в
других базах данных, будут отозваны. Принимает внедрение атрибутов LDAP
с использованием фигурных скобок.
Этот параметр игнорируется для привилегий на уровне экземпляра (например, на LANGUAGE).
H.1.5.5.4.2. privilege
#
Название привилегии, в рамках привилегий, определенных в
привилегиях
YAML секции. Может быть списком названий. Множественная форма
privileges
допустима. Обязательно, значение
по умолчанию отсутствует. Принимает внедрение атрибутов LDAP с использованием
фигурных скобок.
H.1.5.5.4.3. role
#
Название целевой роли гранта (granted
role или grantee). Должно быть
перечислено в
managed_roles_query.
Может быть списком имен. Множественная форма roles
допустима. Принимает инъекцию атрибутов LDAP с использованием фигурных
скобок. ldap2pg применяет
roles_blacklist_query
к этому параметру.
H.1.5.5.4.4. schema
#
Имя схемы в рамках схем, возвращаемых
schemas_query.
Специальное значение __all__
означает все
управляемые схемы в базах данных. Может быть списком
имен. Множественная форма schemas
допустима.
Принимает внедрение атрибутов LDAP с использованием фигурных скобок.
Этот параметр игнорируется для привилегий на
DATABASE
и других привилегий на уровне экземпляра или
на уровне базы данных.
H.1.5.5.4.5. owner
#
Имя роли, для которой необходимо настроить привилегии по умолчанию. Специальное значение __auto__
возвращает управляемые роли, имеющие привилегию CREATE
в целевой схеме. Может быть списком имен. Допустима форма множественного числа owners
. Допускается использование атрибутов LDAP с использованием фигурных скобок.
H.1.6. Проверка кластера Postgres #
ldap2pg следует явному созданию / неявному удалению и явному предоставлению / неявному отзыву. Таким образом, правильная проверка кластера на предмет того, что вы хотите удалить/отозвать, является очень важной для успешной синхронизации.
ldap2pg проверяет базы данных, схемы, роли, владельцев и привилегии с
помощью SQL-запросов. Вы можете настроить все эти запросы в
YAML разделе postgres
с параметрами, оканчивающимися
на _query
. См.
справочник ldap2pg.yaml для подробностей.
H.1.6.1. Какие базы данных синхронизировать? #
databases_query
возвращает плоский список
баз данных для управления. databases_query
должен
возвращать базу данных по умолчанию, как определено в
PGDATABASE
. При удалении ролей ldap2pg
перебирает список баз данных, чтобы переназначить объекты и очистить GRANTs
удаляемой роли. Этот список баз данных также сужает область
проверки GRANTs. ldap2pg будет отзывать GRANTs только на этих
базах данных. См.
справочник ldap2pg.yaml для подробностей.
postgres: databases_query: | SELECT datname FROM pg_catalog.pg_database WHERE datallowconn IS TRUE;
H.1.6.2. Синхронизация подмножества ролей #
По умолчанию ldap2pg управляет всеми ролями из Postgres, на которые у него есть полномочия, за исключением черного списка по умолчанию. Если вы хотите, чтобы ldap2pg синхронизировал только подмножество ролей, вам нужно настроить запрос инспекции в
postgres:managed_roles_query
. Следующий запрос исключает суперпользователей из синхронизации.
postgres: managed_roles_query: | SELECT 'public' UNION SELECT rolname FROM pg_catalog.pg_roles WHERE rolsuper IS FALSE ORDER BY 1;
ldap2pg будет только удалять, отзывать, предоставлять роли, возвращаемые этим запросом.
Обычный случай для этого запроса - возвращать только участников группы, такой как ldap_roles
. Таким образом, ldap2pg ограничивается подмножеством ролей в кластере.
Роль public
не существует в системном
каталоге. Таким образом, если вы хотите, чтобы ldap2pg управлял
привилегиями public
, вы должны явно включить
public
в набор управляемых
ролей. Это значение по умолчанию. Конечно, даже если
public
управляется, ldap2pg не будет удалять или
изменять его, если он не находится в каталоге.
Подстраховкой для полного игнорирования некоторых ролей является roles_blacklist_query.
postgres: roles_blacklist_query: [postgres, pg_*] # This is the default.
Примечание
Шаблон, начинающийся с *
должен
быть заключены в кавычки.
В противном случае вы получите ошибку YAML, такую как found undefined alias
.
H.1.6.3. Инспектирование схем #
Для привилегий на уровне схемы ldap2pg необходимо знать управляемые
схемы для каждой базы данных. Это цель
schemas_query
.
H.1.6.4. Настройка привилегий по умолчанию для владельцев #
Чтобы настроить привилегии по умолчанию, используйте
ключевое слово default
при указании привилегии:
privileges: reading: - default: global type: SELECT on: TABLES
Затем предоставьте его, используя правило grant
:
rules: - grant: - privilege: reading role: readers schema: public owner: ownerrole
Вы можете использовать __auto__
в качестве владельца. Для каждой
схемы ldap2pg настроит каждую управляемую роль, имеющую
привилегию CREATE
на схему.
rules: - grant: - privilege: reading role: readers schema: public owner __auto__
ldap2pg настраивает привилегии по умолчанию в последнюю очередь, после всех действующих
привилегий. Таким образом, CREATE
на схему предоставляется
до того, как ldap2pg проверяет создателей на схемах.
H.1.6.5. Статические запросы #
Вы можете заменить все запросы статическим списком в YAML. Этот список будет использоваться так, как если бы он был возвращен Postgres. Это очень удобно для замораживания значений, таких как базы данных или схемы.
postgres: databases_query: [postgres] schemas_query: [public]
H.1.7. Управление ролями #
ldap2pg синхронизирует роли Postgres в три этапа:
Выполняет цикл
rules
и генерирует список нужных ролей из правилrole
.Проверяет Postgres на наличие существующих ролей, их опций и членства.
Сравнивает два набора ролей и применяет к кластеру Postgres, используя
CREATE
,DROP
иALTER
.
Каждая роль в
rules
является правилом для генерации нуля или более ролей
с соответствующими параметрами. Правило role
похоже на шаблон. Правила role
позволяют
устранить дублирование членства и опций, задав список имен.
Вы можете смешивать статические правила и динамические правила в одном файле.
H.1.7.1. Запуск без привилегий #
ldap2pg предназначен для работы без привилегий. Пользователь синхронизации
нуждается в опции CREATEROLE
для управления другими
непривилегированными ролями. Опция CREATEDB
позволяет
пользователю синхронизации управлять владельцами баз данных.
Пользователь ldap2pg должен иметь createrole_self_grant
установленный в inherit,set
для правильной обработки групп.
CREATE ROLE ldap2pg LOGIN CREATEDB CREATEROLE; ALTER ROLE ldap2pg SET createrole_self_grant TO 'inherit,set;
Запуск без привилегий до Postgres 16 на самом деле ошибочен. Лучше просто запустить ldap2pg с привилегиями суперпользователя, вы не будете чувствовать ложной безопасности.
H.1.7.2. Игнорирование ролей #
ldap2pg полностью игнорирует роли, соответствующие одному из шаблонов glob, определенных в roles_blacklist_query:
postgres: # This is the default value. roles_blacklist_query: [postgres, pg_*]
Черный список ролей также применяется к предоставлениям. ldap2pg никогда не будет
применять GRANT
или REVOKE
к
роли, соответствующей одному из шаблонов черного списка.
ldap2pg вносит в черный список своего запущенного пользователя.
H.1.7.3. Членство #
ldap2pg управляет родительскими ролями. ldap2pg применяет roles_blacklist_query к родительским ролям. Однако, ldap2pg предоставляет неуправляемые родительские роли. Таким образом, вы можете создать группу вручную и управлять ее членами, используя ldap2pg.
H.1.8. Запрос каталога с помощью LDAP #
ldap2pg читает поисковые запросы LDAP на этапах rules
в
записи ldapsearch
.
Поиск LDAP не является обязательным. ldap2pg может создавать роли, определенные статически из YAML. Каждый поиск LDAP выполняется один раз и только один раз. Нет ни цикла, ни дублирования поисков LDAP.
Подсказка
ldap2pg регистрирует поисковые запросы LDAP как команды ldapsearch
.
Включите подробные сообщения, чтобы их увидеть.
Вы можете отладить неудачный поиск, скопировав команду в свою оболочку и обновив параметры.
Как только вы будете довольны, переведите правильные параметры обратно в YAML.
H.1.8.1. Настройка доступа к каталогу #
ldap2pg читает конфигурацию каталога из файла ldaprc и переменных окружения LDAP*. Известные параметры LDAP:
BASE
BINDDN
PASSWORD
REFERRALS
SASL_AUTHCID
SASL_AUTHZID
SASL_MECH
TIMEOUT
TLS_REQCERT
NETWORK_TIMEOUT
URI
См. ldap.conf(5) для значения и формата каждого параметра.
H.1.8.2. Внедрение атрибутов LDAP #
Несколько параметров принимают внедрение атрибутов LDAP с использованием фигурных скобок. Для этого оберните имя атрибута фигурными скобками, как {cn}
или {sAMAccountName}
. ldap2pg расширяет до каждого значения атрибута для каждой записи поиска.
Если параметр имеет несколько атрибутов LDAP, ldap2pg расширяется до всех комбинаций атрибутов для каждой записи.
Учитывая следующие LDAP записи:
dn: uid=dimitri,cn=Users,dc=bridoulou,dc=fr objectClass: inetOrgPerson uid: dimitri sn: Dimitri cn: dimitri mail: dimitri@bridoulou.fr company: external dn: cn=domitille,cn=Users,dc=bridoulou,dc=fr objectClass: inetOrgPerson objectClass: organizationalPerson objectClass: person objectClass: top cn: domitille sn: Domitille company: acme company: external
Формат {company}_{cn}
с вышеуказанными записями LDAP
генерирует следующие строки:
acme_domitille
external_domitille
external_dimitri
Псевдоатрибут dn
всегда доступен
и ссылается на Уникальное Имя (Distinguished Name) исходной записи LDAP.
H.1.8.2.1. Доступ к RDN и подпоиск #
Если тип атрибута - это Distinguished Name (DN), вы можете ссылаться
на Relative Distinguished Name (RDN) с помощью точки, как в этом примере:
<attribute>.<rdn>
. Если у RDN
несколько значений, возвращается только первое значение. Нет
способа получить доступ к другим значениям.
Например, если LDAP запись имеет атрибут member
со значением cn=toto,cn=Users,dc=bridoulou,dc=fr
, формат {member.cn}
сгенерирует toto
. Формат {member.dc}
сгенерирует ldap
. Нет способа получить доступ к acme
и fr
.
Известные RDN: cn
, l
,
st
, o
,
ou
, c
,
street
, dc
и
uid
. Другие атрибуты вызывают
подпоиск. Формат
{member.sAMAccountName}
инициирует
подпоиск для всех значений member
с базой поиска LDAP, суженной до атрибута sAMAccountName
.
H.1.8.2.2. Регистр атрибутов LDAP #
При внедрении атрибута LDAP с фигурными скобками, вы можете
управлять регистром значения, используя
методы .lower()
или .upper()
.
- ldapsearch: ... role: "{cn.lower()}"
H.1.9. Управление привилегиями #
Управление привилегиями - задача непростая. ldap2pg пытается сделать это проще и безопаснее.
H.1.9.1. Основы #
Базовый дизайн ldap2pg амбициозен. Вместо дизайна отозвать всё и назначить снова, ldap2pg использует дизайн проверить-изменить. Процесс такой же, как и для синхронизации ролей, включая следующие три шага:
Цикл
rules
и создание необходимого набора разрешений.Проверка кластера Postgres на предоставленные привилегии.
Сравнение двух наборов привилегий и обновление кластера Postgres, используя
GRANT
,REVOKE
.
ldap2pg синхронизирует привилегии по одному за раз, база данных за базой данных. ldap2pg синхронизирует привилегии по умолчанию в последнюю очередь.
По умолчанию ldap2pg не управляет никакими привилегиями. Чтобы включить управление привилегиями, вы должны определить как минимум один активный профиль привилегий в разделе привилегий. Самый простой способ - использовать [встроенные профили привилегий], поставляемые с ldap2pg, в активной группе привилегий.
H.1.9.2. Определение профиля привилегий #
Профиль привилегий — это список ссылок либо на тип привилегий в ACL, либо на другой профиль. ldap2pg поставляется с несколькими предопределенными ACL, такими как DATABASE
, LANGUAGE
и т. д. Тип привилегий — это USAGE
, CONNECT
и так далее, как описано в документации Раздел 5.7. См. документацию раздела YAML привилегии для получения подробной информации о формате профиля привилегий.
ldap2pg загружает ссылочные ACL, проверяя кластер PostgreSQL
с помощью тщательно составленных запросов. Нессылочные ACL игнорируются.
Проверенные привилегии предполагаются к отзыву, если явно не
указаны в правиле grant
.
Предупреждение
Если это не предоставлено, отзовите это!
Как только привилегия включена,
ldap2pg
отменяет
все предоставления, найденные в экземпляре Postgres и
не требуемые правилом grant
в rules
.
H.1.9.3. Расширенная инспекция экземпляра #
При управлении привилегиями ldap2pg проводит более глубокую проверку
экземпляра Postgres. ldap2pg проверяет схемы после
синхронизации ролей и перед синхронизацией привилегий. ldap2pg
проверяет владельцев объектов после синхронизации привилегий и
перед синхронизацией привилегий по умолчанию. Владелец объекта — это
роль, имеющая привилегию CREATE
на схему.
H.1.9.4. Предоставление профиля привилегий #
Проверка привилегий может потреблять много ресурсов на экземпляре PostgreSQL. Известно, что отзыв привилегий происходит медленно в PostgreSQL. Лучшая практика - предоставлять привилегии группе ролей и позволять пользователю наследовать привилегии. С помощью ldap2pg вы можете определить статические группы в YAML и наследовать их при создании ролей из каталога.
Используйте правило предоставления, чтобы предоставить профиль привилегий одной или нескольким ролям. При предоставлении привилегий вы должны определить получателя. Вы можете ограничить предоставление одной или несколькими базами данных, одной или несколькими схемами. Если профиль привилегий включает привилегии по умолчанию, вы можете определить владельцев, для которых нужно настроить привилегии по умолчанию.
По умолчанию, разрешение применяется ко всем управляемым базам данных, как возвращено с помощью databases_query, ко всем схемам каждой базы данных, как возвращено с помощью schemas_query.
H.1.9.5. Пример #
Следующий пример определяет три профиля привилегий.
rules
определяет три группы и предоставляет
соответствующий профиль привилегий:
privileges: reading: - __connect__ - __usage_on_schemas__ - __select_on_tables__ writing: - reading # include reading privileges - __insert_on_tables__ - __update_on_tables__ owning: - writing - __create_on_schemas__ - __truncate_on_tables__ rules: - role: - names: - readers - writers - owners options: NOLOGIN - grant: - privilege: reading role: readers - privilege: writing role: writers - privilege: owning role: owners
Другой способ включения профиля чтения в запись - это сделать группу писателей наследником группы читателей.
H.1.9.6. Управление публичными привилегиями #
PostgreSQL имеет псевдо-роль под названием public
.
Это роль-джокер, означающая всех пользователей.
Все роли в PostgreSQL неявно наследуются от этой
роли public
. Предоставление привилегии
роли public
предоставляет её каждой роли сейчас и в
будущем.
PostgreSQL также как и схема public
. Схема
public
является реальной схемой, доступной во
всех базах данных.
PostgreSQL имеет некоторые встроенные привилегии для
роли public
. Особенно для
схемы public
. Например,
public
имеет CONNECT
ко всем
базам данных по умолчанию. Это означает, что вы полагаетесь только на
pg_hba.conf
для настройки доступа к базам данных,
что требует административного доступа к кластеру и вызова
pg_reload_conf()
.
По умолчанию, ldap2pg включает роль public
в управляемые роли. Предопределенный ACL знает, как проверять встроенные привилегии, предоставленные public
. Если вы хотите сохранить роль public
, перепишите managed_roles_query, чтобы не включать public
.
H.1.9.7. Управление привилегиями по умолчанию #
Если вы предоставите привилегии SELECT
на все таблицы
в схеме роли, это не будет применяться к новым таблицам, созданным
впоследствии. Вместо повторного выполнения ldap2pg после создания
каждого объекта, PostgreSQL предоставляет способ определения
привилегий по умолчанию для будущих объектов.
PostgreSQL присваивает права по умолчанию роли создателя. Когда
роль создает объект, PostgreSQL применяет соответствующие
права по умолчанию к новому объекту.
например, ALTER DEFAULT PRIVILEGES FOR ROLE bob GRANT SELECT ON TABLES TO alice;
гарантирует, что каждая новая таблица, созданная bob, будет доступна для
alice:
Если ldap2pg создает и удаляет роли создателя, вы хотите, чтобы ldap2pg правильно настраивал привилегии по умолчанию для этих ролей. Если вы задумываетесь, следует ли управлять привилегиями с помощью ldap2pg, вам следует как минимум управлять привилегиями по умолчанию вместе с создателем.
ldap2pg проверяет создателей из PostgreSQL по схемам, а не LDAP каталогу. Создатель - это роль с опцией LOGIN и привилегией CREATE на схему. Вы можете вручную установить целевого владельца для предоставления любой управляемой роли.
ldap2pg не настраивает привилегии на
__all__
схемах. Вы должны использовать
global
область вместо этого. Если вы хотите
предоставить/отозвать привилегии по умолчанию для каждой схемы, вы должны ссылаться на
schema
по умолчанию.
Следующий пример настраивает привилегии по умолчанию для alice, чтобы разрешить bob выполнять SELECT на будущих таблицах, созданных alice.
privileges: reading: - default: global type: SELECT on: TABLES owning: - type: CREATE on: SCHEMAS rules: - roles: names: - alice - bob options: LOGIN - grant: privilege: owning role: alice - grant: privilege: reading role: bob
PostgreSQL имеет жестко заданные глобальные привилегии по умолчанию. Если у роли не настроены глобальные привилегии по умолчанию, PostgreSQL предполагает некоторые значения по умолчанию. По умолчанию PostgreSQL просто предоставляет привилегии владельцу. Вы можете увидеть их, как только измените привилегии по умолчанию. PostgreSQL скопирует жестко заданные значения вместе с вашими предоставленными привилегиями.
Если вы явно не предоставите эти привилегии заново в ldap2pg.yml, ldap2pg отзовет эти жестко заданные привилегии. На самом деле, владельцу таблицы не нужно предоставлять SELECT на свои собственные таблицы. Таким образом, жестко заданные значения по умолчанию бесполезны. Вы можете позволить ldap2pg удалить эти бесполезные значения по умолчанию.
H.1.10. Встроенные привилегии #
ldap2pg предоставляет некоторые встроенные ACL и предопределенные профили привилегий для повторного использования. На эти привилегии нет гарантии. Вы должны проверять конфигурацию привилегий в ваших базах данных так же, как вы должны делать это с вашим собственным кодом.
H.1.10.1. Использование Предопределенных Профилей Привилегий #
Профиль привилегий — это список ссылок на тип привилегий
в ACL. В ldap2pg, ACL — это набор запросов для проверки,
предоставления и отзыва привилегий на класс объектов. Запрос проверки
расширяет тип PostgreSQL aclitem
для перечисления
всех предоставлений из системного каталога. Профиль привилегий может включать
другой профиль.
Встроенный профиль привилегий начинается и заканчивается
__
. ldap2pg
отключает профиль привилегий
начиная с _
. Таким образом, вы должны
включить встроенный профиль привилегий в другой профиль, чтобы
их активировать. Если два профиля ссылаются на одну и ту же привилегию,
ldap2pg проверит её один раз.
privileges: ro: - __connect__ - __usage_on_schemas__ - __select_on_tables__ rw: - ro - __insert__ - __update_on_tables__ ddl: - rw - __all_on_schemas__ - __all_on_tables__ rules: - grant: privilege: ddl database: mydb role: admins
Имя встроенного профиля следует следующей свободной конвенции:
..._on_all_tables__
ссылается наALL TABLES IN SCHEMA
ACL. Аналогично для последовательностей и функций.__default_...__
ссылается как на глобальные, так и на установленные в пределах схемы привилегии по умолчанию.__..._on_tables__
группы__..._on_all_tables__
и__default_..._on_tables__
.Группа, начинающаяся с
__all_on_...__
, является эквивалентомALL PRIVILEGES
в SQL. Однако, каждое привилегия будет предоставлена индивидуально.Привилегия, специфичная для одного типа объекта, не имеет суффикса
_on_<type>
. Например,__delete_on_tables__
является псевдонимом для__delete__
.
Эта страница не документирует стандарт SQL и значение каждого SQL-привилегии. Вы найдете документацию по SQL-привилегиям в GRANT и ALTER DEFAULT PRIVILEGES.
H.1.10.2. Справочник по ACL #
Вот список встроенных ACL.
Для эффективных привилегий:
DATABASE
: привилегия на базу данных, такая какCONNECT
,CREATE
и т. д.SCHEMA
: управлятьUSAGE
иCREATE
в схеме.LANGUAGE
: управлениеUSAGE
на процедурных языках.ALL FUNCTIONS IN SCHEMA
: управлениеEXECUTE
для всех функций в каждой схеме.ALL SEQUENCES IN SCHEMA
: как выше, но для последовательностей.ALL TABLES IN SCHEMA
: как выше, но для таблиц и представлений.
ALL ... IN SCHEMA
ACL проверяет, предоставлено ли
привилегия только подмножеству объектов. Это
частичное предоставление. Частичное предоставление либо
отзывается, если оно нежелательно, либо предоставляется заново, если ожидается.
ACL для привилегий по умолчанию:
SEQUENCES
FUNCTIONS
TABLES
Эти ACL должны быть указаны с global
, установленным
либо в schema
, либо в
global
.
Вы можете ссылаться на эти ACL, используя параметр privileges:on в YAML. Например:
privileges: myprofile: - type: SELECT on: ALL TABLES IN SCHEMA
Вы не можете (пока) настроить пользовательский ACL.
H.1.10.3. Справочник по профилям #
H.1.10.3.1. Профиль __all_on_functions__
#
H.1.10.3.2. Профиль __all_on_schemas__
#
H.1.10.3.3. Профиль __all_on_sequences__
#
H.1.10.3.4. Профиль __all_on_tables__
#
H.1.10.3.5. Профиль __delete_on_tables__
#
H.1.10.3.6. Профиль
__execute_on_functions__
#
H.1.10.3.7. Профиль __insert_on_tables__
#
H.1.10.3.8. Профиль
__references_on_tables__
#
H.1.10.3.9. Профиль
__select_on_sequences__
#
H.1.10.3.10. Профиль __select_on_tables__
#
H.1.10.3.11. Профиль __trigger_on_tables__
#
H.1.10.3.12. Профиль __truncate_on_tables__
#
H.1.10.3.13. Профиль
__update_on_sequences__
#
H.1.10.3.14. Профиль __update_on_tables__
#
H.1.10.3.15. Профиль __usage_on_sequences__
#
H.1.10.4. Справочник по привилегиям #
Вот список предопределенных привилегий:
Имя | Управляет |
---|---|
__connect__
|
CONNECT ON DATABASE
|
__create_on_schemas__
|
CREATE ON SCHEMA
|
__delete_on_all_tables__
|
DELETE ON ALL TABLES IN SCHEMA
|
__execute_on_all_functions__
|
EXECUTE ON ALL FUNCTIONS IN SCHEMA
|
__insert_on_all_tables__
|
INSERT ON ALL TABLES IN SCHEMA
|
__references_on_all_tables__
|
REFERENCES ON ALL TABLES IN SCHEMA
|
__select_on_all_sequences__
|
SELECT ON ALL SEQUENCES IN SCHEMA
|
__select_on_all_tables__
|
SELECT ON ALL TABLES IN SCHEMA
|
__temporary__
|
TEMPORARY ON DATABASE
|
__trigger_on_all_tables__
|
TRIGGER ON ALL TABLES IN SCHEMA
|
__truncate_on_all_tables__
|
TRUNCATE ON ALL TABLES IN SCHEMA
|
__update_on_all_sequences__
|
UPDATE ON ALL SEQUENCES IN SCHEMA
|
__update_on_all_tables__
|
UPDATE ON ALL TABLES IN SCHEMA
|
__usage_on_all_sequences__
|
USAGE ON ALL SEQUENCES IN SCHEMA
|
__usage_on_schemas__
|
USAGE ON SCHEMA
|
H.1.10.5. Справочник по привилегиям по умолчанию #
Вот список предопределенных привилегий по умолчанию. Профиль привилегий по умолчанию ссылается как на глобальные, так и на схемные значения по умолчанию.
Имя | Управляет |
---|---|
__default_delete_on_tables__
|
DELETE ON TABLES
|
__default_execute_on_functions__
|
EXECUTE ON FUNCTIONS
|
__default_insert_on_tables__
|
INSERT ON TABLES
|
__default_references_on_tables__
|
REFERENCES ON TABLES
|
__default_select_on_sequences__
|
SELECT ON SEQUENCES
|
__default_select_on_tables__
|
SELECT ON TABLES
|
__default_trigger_on_tables__
|
TRIGGER ON TABLES
|
__default_truncate_on_tables__
|
TRUNCATE ON TABLES
|
__default_update_on_sequences__
|
UPDATE ON SEQUENCES
|
__default_update_on_tables__
|
UPDATE ON TABLES
|
__default_usage_on_sequences__
|
USAGE ON SEQUENCES
|
H.1.11. Кулинарная книга #
Здесь, в этой кулинарной книге, вы найдете несколько рецептов для различных случаев использования ldap2pg.
Если вы испытываете трудности с настройкой ldap2pg для ваших нужд, пожалуйста создайте запрос, чтобы мы могли обновить Кулинарную книгу новыми рецептами! Ваш вклад приветствуется!
H.1.11.1. Настройте pg_hba.conf
с помощью LDAP #
ldap2pg НЕ настраивает
PostgreSQL за вас. Вы должны внимательно прочитать Раздел 19.10
по этому вопросу. Правильная настройка PostgreSQL
перед
написанием ldap2pg.yaml
— это хороший старт. Вот
шаги по настройке PostgreSQL с LDAP в наилучшем порядке:
Напишите LDAP-запрос и протестируйте его с помощью
ldapsearch(1)
. Таким образом, вы также можете проверить, как вы подключаетесь к вашему LDAP-каталогу.В кластере PostgreSQL, вручную создайте единственную роль, имеющую свой пароль в каталоге LDAP.
Отредактируйте
pg_hba.conf
следуя Раздел 19.10 до тех пор, пока вы не сможете эффективно войти с единственной ролью и паролем из LDAP.
Как только у вас настроена аутентификация LDAP в кластере PostgreSQL, вы можете перейти к автоматизации создания ролей из каталога LDAP с помощью ldap2pg:
Напишите простой
ldap2pg.yaml
с только одним поиском LDAP, чтобы настроить параметры подключения ldap2pg для PostgreSQL и подключения LDAP. По умолчанию ldap2pg всегда работает в режиме сухого запуска, поэтому вы можете безопасно повторять выполнение ldap2pg, пока не получите правильный результат.Затем заполните
ldap2pg.yaml
в соответствии с вашими потребностями, следуя Раздел H.1.4. Запустите ldap2pg на самом деле и проверьте, что ldap2pg поддерживает вашу единственную тестовую роль, и что вы все еще можете подключиться к кластеру с ней.Наконец, вы должны решить, когда и как вы хотите запускать синхронизацию: регулярное задание cron? Задача ansible? Вручную? Другое? Убедитесь, что выполнение ldap2pg происходит часто, целенаправленно и с уведомлением.
H.1.11.2. Поиск в каталоге LDAP #
Первый шаг - это поиск на вашем LDAP-сервере с помощью ldapsearch(1), инструмента командной строки из OpenLDAP. Например:
$ ldapsearch -H ldaps://ldap.ldap2pg.docker -U testsasl -W Enter LDAP Password: SASL/DIGEST-MD5 authentication started SASL username: testsasl SASL SSF: 128 SASL data security layer installed. # extended LDIF # # LDAPv3 ... # search result search: 4 result: 0 Success # numResponses: 16 # numEntries: 15 $
Теперь сохраните настройки в ldaprc
:
LDAPURI ldaps://ldap.ldap2pg.docker LDAPSASL_AUTHCID testsasl
И в окружении: LDAPPASSWORD=secret
Затем обновите ваш ldapsearch(1), чтобы правильно сопоставлять записи ролей на сервере LDAP:
$ ldapsearch -H ldaps://ldap.ldap2pg.docker -U testsasl -W -b cn=dba,ou=groups,dc=ldap,dc=ldap2pg,dc=docker '' member ... # dba, groups, ldap.ldap2pg.docker dn: cn=dba,ou=groups,dc=ldap,dc=ldap2pg,dc=docker member: cn=Alan,ou=people,dc=ldap,dc=ldap2pg,dc=docker member: cn=albert,ou=people,dc=ldap,dc=ldap2pg,dc=docker member: cn=ALICE,ou=people,dc=ldap,dc=ldap2pg,dc=docker # search result search: 4 result: 0 Success ... $
Теперь переведите запрос в ldap2pg.yaml
и
свяжите сопоставление ролей, чтобы создать роли из каждого значения
каждой записи, возвращенной поиском LDAP:
- ldapsearch: base: cn=dba,ou=groups,dc=ldap,dc=ldap2pg,dc=docker role: name: '{member.cn}' options: LOGIN SUPERUSER
Протестируйте это:
$ ldap2pg ... Querying LDAP cn=dba,ou=groups,dc=ldap,dc=ldap2pg,dc=docker... Would create alan. Would create albert. Would update options of alice. ... Comparison complete. $
Читать далее о том, как управлять созданием ролей из записи LDAP в
Раздел H.1.5. Как только вы будете
удовлетворены результатом сравнения, переходите к реальному выполнению с
--real
.
H.1.11.3. Использование LDAP с высокой доступностью #
ldap2pg поддерживает высокую доступность LDAP из коробки, как и любой клиент openldap. Используйте список URI, разделенный пробелами, чтобы указать все серверы.
$ LDAPURI="ldaps://ldap1 ldaps://ldap2" ldap2pg
См. [ldap.conf(5)] для получения дополнительных сведений.
H.1.11.4. Запуск от имени не-суперпользователя #
Поскольку Postgres предоставляет опцию роли CREATEROLE
,
вы можете управлять ролями без привилегий суперпользователя.
С точки зрения безопасности, это хорошая идея — управлять ролями без
суперпривилегий.
Предупреждение
До Postgres 15, наличие CREATEROLE примерно эквивалентно наличию прав суперпользователя. Это потому, что пользователь с CREATEROLE может предоставить себе почти все привилегии. Таким образом, ldap2pg поддерживает выполнение без привилегий только в Postgres 16 и более поздних версиях.
ldap2pg поддерживает этот случай. Однако вы должны быть осторожны с
ограничениями. Давайте назовем роль, не обладающую правами суперпользователя, создающую другие
роли, creator
.
Вы не можете управлять некоторыми параметрами ролей, такими как
SUPERUSER
,BYPASSRLS
иREPLICATION
. Таким образом, вы не сможете обнаружить ложных суперпользователей.Убедитесь, что
creator
может отозвать все предоставления управляемых пользователей.
H.1.11.5. Удаление всех ролей #
Если вы когда-либо захотите очистить все роли в кластере PostgreSQL,
ldap2pg может быть полезен. Вы должны явно определить пустые
rules
.
$ echo '{version: 6, rules: []}' | ldap2pg --config - ... Empty synchronization map. All roles will be dropped! ...
В этом примере применяется черный список по умолчанию. ldap2pg никогда не сбрасывает свою роль подключения.
H.1.11.6. ldap2pg как контейнер Docker #
Уже знакомы с Docker и хотите сэкономить время на настройке? Вы находитесь в нужном месте.
Чтобы запустить контейнер, просто используйте команду:
$ docker run --rm dalibo/ldap2pg --help
Образ Docker для ldap2pg использует те же параметры конфигурации, как объяснено в разделах Раздел H.1.4 и Раздел H.1.5. Вы можете подключить конфигурационный файл ldap2pg.yml.
$ docker run --rm -v ${PWD}/ldap2pg.yml:/workspace/ldap2pg.yml dalibo/ldap2pg
Вы также можете экспортировать некоторые переменные окружения с опцией -e:
$ docker run --rm -v ${PWD}/ldap2pg.yml:/workspace/ldap2pg.yml -e PGDSN=postgres://postgres@localhost:5432/ -e LDAPURI=ldaps://localhost -e LDAPBINDDN=cn=you,dc=entreprise,dc=fr -e LDAPPASSWORD=pasglop dalibo/ldap2pg
Убедитесь, что ваш контейнер может разрешить имя хоста, на которое вы указываете. Если вы используете какое-либо внутреннее разрешение имен, обязательно добавьте опцию –dns= в вашу команду, указывающую на ваш внутренний DNS-сервер. Больше информации
H.1.12. Вклад #
Вы можете внести свой вклад в ldap2pg, добавив патч к коду, документации или образцу конфигурации! Здесь представлена расширенная документация о том, как настроить среду разработки. Не стесняйтесь адаптировать под свои нужды. Автоматические тесты на CircleCI позаботятся о проверке регрессий.
H.1.12.1. Среда разработки Docker #
Репозиторий проекта содержит файл docker-compose.yml
для запуска экземпляров Samba Directory и PostgreSQL.
$ docker compose pull ... Status: Downloaded newer image for postgres:16-alpine $ docker compose up -d Creating network "ldap2pg_default" with the default driver Creating ldap2pg_postgres_1 ... Creating ldap2pg_samba_1 ... Creating ldap2pg_postgres_1 Creating ldap2pg_samba_1 ... done
Вам решать, как получить доступ к контейнерам Postgres и LDAP
с вашего хоста: либо используйте разрешение DNS, либо
docker-compose.override.yml
для открытия порта на
вашем хосте. Предоставленный docker-compose.yml
идет
с postgres.ldap2pg.docker
и
samba.ldap2pg.docker
dnsdock
алиасами.
Настройте вашу среду с обычными переменными окружения PG*
так, чтобы psql
мог просто подключиться к вашему
экземпляру PostgreSQL. Проверьте с помощью простого вызова psql
.
$ export PGHOST=postgres.ldap2pg.docker PGUSER=postgres PGPASSWORD=postgres $ psql -c 'SELECT version()';
Сделайте то же самое для настройки libldap2
с
LDAP*
переменными окружения. Предоставляется ldaprc
, который настраивает BINDDN
и
BASE
. ldap2pg поддерживает
LDAPPASSWORD
для установки пароля из окружения. Проверьте это с помощью ldapsearch
:
$ export LDAPURI=ldaps://samba.ldap2pg.docker LDAPPASSWORD=1Ntegral $ ldapsearch -vxw $LDAPPASSWORD -s base cn ldap_initialize( <DEFAULT> ) filter: (objectclass=*) requesting: cn # extended LDIF # # LDAPv3 # base <cn=users,dc=bridoulou,dc=fr> (default) with scope baseObject # filter: (objectclass=*) # requesting: cn # # Users, bridoulou.fr dn: CN=Users,DC=bridoulou,DC=fr cn: Users # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 $
H.1.12.1.1. Среда без разрешения DNS #
Чтобы получить доступ к Samba Directory и PostgreSQL без dnsdock, откройте порты контейнеров для вашего хоста с помощью следующей переопределения:
# contents docker-compose.override.yml version: '3' services: samba: ports: # HOST:CONTAINER - 389:389 - 636:636 postgres: ports: - 5432:5432
Используйте PGHOST=localhost
и
LDAPURI=ldaps://localhost
.
H.1.12.1.2. Запуск ldap2pg с изменениями #
Теперь вы можете запустить ldap2pg из исходного кода и протестировать свои изменения!
$ go run ./cmd/ldap2pg 09:54:27 INFO Starting ldap2pg version=v6.0-alpha5 runtime=go1.20.3 commit=<none> 09:54:27 WARN Running a prerelease! Use at your own risks! 09:54:27 INFO Using YAML configuration file. path=./ldap2pg.yml ... 09:54:27 INFO Nothing to do. elapsed=78.470278ms mempeak=1.2MiB postgres=0s queries=0 ldap=486.921µs searches=1 $
H.1.12.2. Средства разработки #
Проект ldap2pg поставляется с тремя случаями для тестирования:
номинальный: обычный случай с:
запуск без привилегий
одна база данных с именем
nominal
.3 группы: читатели, писатели и владельцы
роли и привилегии синхронизированы.
extra: несколько крайних случаев вместе
запуск от имени суперпользователя
synchronize role configuration
выполнять подпоиски LDAP.
big: огромный проект синхронизации
несколько баз данных с МНОЖЕСТВОМ схем, таблиц, представлений и т. д.
все привилегии синхронизированы
3 группы на схему.
1K пользователей в каталоге.
test/fixtures/
содержит фикстуры для Samba и PostgreSQL. Среда разработки по умолчанию загружает nominal и extra фикстуры. По умолчанию большой случай не загружается. Функциональные тесты используют nominal и extra фикстуры. См. ниже для big случая.
test/fixtures/postgres/reset.sh
сбрасывает
состояние PostgreSQL. Вы также можете использовать
make reset-postgres
для воссоздания контейнера PostgreSQL с нуля.
H.1.12.3. Модульные тесты #
Модульные тесты строго не имеют ввода/вывода. Запускайте модульные тесты как обычные go-тесты.
$ go test ./... ? github.com/dalibo/ldap2pg/cmd/ldap2pg [no test files] ? github.com/dalibo/ldap2pg/cmd/render-doc [no test files] ok github.com/dalibo/ldap2pg/cmd/mon-dojo 0.002s ok github.com/dalibo/ldap2pg/internal 0.003s ok github.com/dalibo/ldap2pg/internal/config 0.007s ok github.com/dalibo/ldap2pg/internal/inspect 0.005s ok github.com/dalibo/ldap2pg/internal/ldap 0.005s ok github.com/dalibo/ldap2pg/internal/lists 0.005s ? github.com/dalibo/ldap2pg/internal/postgres [no test files] ok github.com/dalibo/ldap2pg/internal/perf 0.004s ok github.com/dalibo/ldap2pg/internal/privilege 0.003s ? github.com/dalibo/ldap2pg/internal/role [no test files] ok github.com/dalibo/ldap2pg/internal/pyfmt 0.004s ok github.com/dalibo/ldap2pg/internal/tree 0.002s ok github.com/dalibo/ldap2pg/internal/wanted 0.003s $
H.1.12.4. Функциональные тесты #
test/
каталог является проектом [pytest] с функциональными тестами. Функциональные тесты стремятся проверить ldap2pg в реальном мире : без моков.
Функциональные тесты требуют Python 3.6. Создайте virtualenv для изоляции
зависимостей Python для разработки ldap2pg. Установите зависимости для разработки с помощью
pip install -Ur test/requirements.txt
.
$ pip install -Ur test/requirements.txt ... Successfully installed iniconfig-2.0.0 packaging-23.1 pluggy-1.3.0 pytest-7.4.2 sh-1.14.1 $
Вы можете запускать функциональные тесты прямо из вашей среды разработки:
$ pip install -Ur test/requirements.txt ... $ pytest test/ ... ldap2pg: /home/bersace/src/dalibo/ldap2pg/test/ldap2pg.sh ... test/test_nominal.py::test_re_revoke PASSED [ 90%] test/test_nominal.py::test_nothing_to_do PASSED [100%] =============================== 11 passed in 14.90s ================================ $
CI выполняет функциональные тесты в CentOS 6 и 7 и RockyLinux 8 и 9.
Тесты написаны с использованием замечательных проектов
pytest и
sh.
conftest.py
предоставляет различные
специфические фикстуры. Самое важное, что база данных Postgres
сбрасывается между каждым Python
модулем. pytests выполняет функциональные
тесты в порядке их определения. Если тест изменяет Postgres, то
последующие тесты будут иметь это изменение до конца
модуля. Это позволяет разбить большой сценарий на несколько
шагов, не теряя контекста и циклов процессора.
Два основных фикстуры pytest очень полезны при тестировании:
psql
и ldap
. Эти
небольшие помощники предоставляют быстрый доступ к частой проверке
базы данных Postgres на основе LDAP с
sh.py
-стилем API.
Вы можете выполнять тесты так же, как в CI, с помощью следующих команд:
$ goreleaser build --clean --snapshot --single-target $ COMPOSE_FILE=docker-compose.yml:test/docker-compose.yml docker compose up --exit-code-from=test
H.1.12.5. Большой регистр #
Чтобы нагрузить ldap2pg на большой установке, используйте make big
.
Это заполнит каталог множеством пользователей и групп, несколькими
базами данных с множеством схем и т.д. Синхронизируйте эту установку
с:
$ test/genperfconfig.sh | PGDATABASE=big0 go run ./cmd/ldap2pg -c -
H.1.12.6. Документирование #
Создание документации требует Python 3.7.
mkdocs отвечает за
создание документации. Чтобы редактировать документацию, установите
docs/requirements.txt
и выполните
mkdocs serve
в корневом каталоге. См.
документацию
mkdocs для получения дополнительной информации.
$ pip install -r docs/requirements.txt ... Successfully installed babel-2.12.1 certifi-2023.7.22 charset-normalizer-3.2.0 click-8.1.7 colorama-0.4.6 ghp-import-2.1.0 idna-3.4 jinja2-3.1.2 markdown-3.5 m...
H.1.12.7. Выпуск #
Обновить default.pgo
Просмотрите
docs/changelog.md
. Первый заголовок должен быть# ldap2pg X.Y
Создайте коммит релиза, тег и журнал изменений с помощью
make release
. make считывает следующую версию из журнала изменений.Как только CircleCI создал артефакты релиза GitHub, опубликуйте пакеты с помощью
make publish-packages
.Как только Docker Hub опубликует новый тег, отметьте последнее изображение на docker hub с помощью
make tag-latest
.
H.1.13. Поддержка #
Если вам нужна поддержка и вы не нашли её в документации, просто задайте вопрос в вопросе на GitHub! Французский язык принимается. Не пропустите кулинарную книгу для продвинутых случаев использования.
H.1.14. Авторы #
ldap2pg — это проект Dalibo Labs.
Étienne BERSAC является сопровождающим.
Дамьен Казейлс разработал логотип.
Гарольд ле КЛЕМАН де СЕН-МАРК реализовал подпоиски LDAP.
Randolph Voorhies реализовал синхронизацию конфигурации ролей.