SSSD-SECRETS(5) | Формати файлів та правила | SSSD-SECRETS(5) |
NAME¶
sssd-secrets - Відповідач реєстраційних даних SSSD
ОПИС¶
На цій сторінці довідника описано налаштування засобу надання відповідей Secrets для sssd(8). Щоб дізнатися більше про синтаксис налаштування, зверніться до розділу «ФОРМАТ ФАЙЛІВ» сторінки довідника sssd.conf(5).
У багатьох програмах системи або користувача існує потреба у збереженні конфіденційних даних, зокрема паролів і ключів до служб, та зручній роботі з цими даними. Простим способом вирішення цієї проблеми є вбудовування цих “реєстраційних даних” до файлів налаштувань. Втім, це призводить до потенційного розширення доступу до конфіденційних даних через резервні копії, системи керування налаштуваннями, та загалом робить захист даних важчим.
Проєкт custodia[1] було створено для урегулювання цієї проблеми у хмароподібних середовищах, але нам ця ідея здалася вартою уваги навіть на рівні окремої ізольованої системи. Як служба захисту, SSSD є ідеальним місцем для реалізації такої можливості з доступом до відповідного програмного інтерфейсу через сокети UNIX. Така реалізація уможливлює використання локальних викликів і належну маршрутизацію до локального або віддаленого сховища ключів, зокрема сховища IPA, для зберігання, депонування і відновлення даних.
Записи реєстраційних даних є простими парами ключ-значення. Реєстраційні дані кожного з користувачів співвідносяться із його простором назв на основі ідентифікатора користувача. Це означає, що реєстраційні дані одного користувача ніколи не потраплять до іншого. Реєстраційні дані зберігаються у “контейнерах”, які можна вкладати один у одного.
Оскільки відповідач реєстраційних даних може використовуватися ззовні для зберігання загальних реєстраційних даних, як це описано у решті цієї сторінки підручника, і всередині іншими компонентами SSSD для зберігання власних реєстраційних даних, можна налаштувати деякі параметри, зокрема квоти для окремих записів “hive” у підрозділі налаштувань із назвою відповідного рою. Підтримувані у поточній версії рої:
secrets
kcm
КОРИСТУВАННЯ ВІДПОВІДАЧЕМ РЕЄСТРАЦІЙНИХ ДАНИХ¶
Сокет UNIX, на якому відповідач SSSD очікує на дані, розташовано у /var/run/secrets.socket.
Відповідач для реєстраційних даних активується за допомогою сокетів systemd(1). На відміну від інших відповідачів SSSD, його не можна запустити додаванням рядка “secrets” до інструкції “service”. Модуль сокета systemd називається “sssd-secrets.socket”, а відповідний файл служби має назву “sssd-secrets.service”. Щоб службу можна було активувати за допомогою сокета, слід увімкнути і задіяти сокет, а потім увімкнути службу:
systemctl start sssd-secrets.socket systemctl enable sssd-secrets.socket systemctl enable sssd-secrets.service
Будь ласка, зауважте, що відповідні налаштування модулів вже могло бути виконано засобами вашого дистрибутива.
ПАРАМЕТРИ НАЛАШТУВАННЯ¶
Відповідачу реєстраційних даних можна передавати типові параметри відповідача SSSD, зокрема “debug_level” та “fd_limit”. Із повним списком параметрів можна ознайомитися на сторінці підручника sssd.conf(5). Крім того, передбачено декілька специфічних для реєстраційних даних параметрів.
Відповідач реєстраційних даних налаштовується за допомогою загального розділу “[secrets]” і необов'язкових розділів “[secrets/users/$uid]” для окремих користувачів у sssd.conf. Будь ласка, зауважте, що деякі параметра, зокрема тип постачальника даних, можна вказати лише у підрозділах окремих користувачів.
provider (рядок)
local
proxy
Типове значення: local
Наведені нижче параметри стосуються лише записів реєстраційних даних “hive” і тому їх слід встановлювати у підрозділах окремих роїв. Встановлення значення параметра 0 означає «без обмежень».
containers_nest_level (ціле значення)
Типове значення: 4
max_secrets (ціле значення)
Типове значення: 1024 (рій реєстраційних даних), 256 (рій kcm)
max_uid_secrets (ціле число)
Типове значення: 256 (рій реєстраційних даних), 64 (рій kcm)
max_payload_size (ціле значення)
Типове значення: 16 (рій реєстраційних даних), 65536 (64 МіБ) (рій kcm)
Наприклад, щоб встановити різні квоти для роїв “secrets” та “kcm”, скористайтеся такими рядками:
[secrets/secrets] max_payload_size = 128 [secrets/kcm] max_payload_size = 256
Вказані нижче параметри стосуються лише конфігурацій, у яких використовується засіб надання даних “proxy”.
proxy_url (рядок)
Формат адреси має відповідати формату, що визначається RFC 2732:
http[s]://<вузол>[:порт]
Приклад: http://localhost:8080
auth_type (рядок)
basic_auth
header
auth_header_name (рядок)
Приклад: MYSECRETNAME
auth_header_value (рядок)
Приклад: mysecret
forward_headers (список рядків)
Типове значення: not set
verify_peer (булеве значення)
Типове значення: true
verify_host (булеве значення)
Типове значення: true
capath (рядок)
Типове значення: not set
cacert (рядок)
Типове значення: not set
cert (рядок)
Типове значення: not set
key (рядок)
Типове значення: not set
КОРИСТУВАННЯ API REST¶
У цьому розділі наведено список доступних команд та приклади користування із використанням програми curl(1). Усі запити до засобу надання даних проксі мають встановлювати для заголовка Content Type значення “application/json”. Крім того, для локального засобу надання даних передбачено підтримку встановлення для Content Type значення “application/octet-stream”. Реєстраційні дані, збережені із запитами, де встановлено значення заголовка Content Type “application/octet-stream”, є даними у кодуванні base64 у сховищі, які розшифровуються під час отримання, тому не можна зберігати реєстраційні дані із одним значенням Content Type і отримувати з іншим. Адреса реєстраційних даних має починатися з /secrets/.
Отримання списку реєстраційних даних
Приклад:
curl -H "Content-Type: application/json" \
--unix-socket /var/run/secrets.socket \
-XGET http://localhost/secrets/
Отримання реєстраційних даних
Приклади:
curl -H "Content-Type: application/json" \
--unix-socket /var/run/secrets.socket \
-XGET http://localhost/secrets/foo
curl -H "Content-Type: application/octet-stream" \
--unix-socket /var/run/secrets.socket \
-XGET http://localhost/secrets/bar
Встановлення реєстраційних даних
Тип “application/json” просто надсилає реєстраційний ключ як вміст повідомлення.
У наведеному нижче прикладі ми встановлюємо для реєстраційних даних із назвою «foo» значення «foosecret», а для реєстраційних даних із назвою «bar» — значення «barsecret», використовуючи різні значення Content Type.
curl -H "Content-Type: application/json" \
--unix-socket /var/run/secrets.socket \
-XPUT http://localhost/secrets/foo \
-d'{"type":"simple","value":"foosecret"}'
curl -H "Content-Type: application/octet-stream" \
--unix-socket /var/run/secrets.socket \
-XPUT http://localhost/secrets/bar \
-d'barsecret'
Створення контейнера
У наступному прикладі створюємо контейнер із назвою «mycontainer»:
curl -H "Content-Type: application/json" \
--unix-socket /var/run/secrets.socket \
-XPOST http://localhost/secrets/mycontainer/
Щоб працювати із записами реєстраційних даних у цьому контейнері, просто вкладіть записи реєстраційних даних до шляху контейнера:
Вилучення реєстраційних даних або контейнера
У наведеному нижче прикладі ми вилучимо реєстраційні дані для запису «foo».
curl -H "Content-Type: application/json" \
--unix-socket /var/run/secrets.socket \
-XDELETE http://localhost/secrets/foo
ПРИКЛАД НАЛАШТОВУВАННЯ МОДУЛІВ НАДАННЯ ДАНИХ CUSTODIA І ПРОКСІ¶
Для тестування засобу надання даних «proxy» вам слід налаштувати проксі-передавання на сервер Custodia. Будь ласка, завжди користуйтеся документацією до Custodia, оскільки інструкції налаштовування у різних версіях Custodia можуть бути різними.
Ці налаштування визначають для сервера Custodia адресу очікування даних http://localhost:8080, дозволяють будь-кому із заголовком із назвою MYSECRETNAME, який встановлено у значення mysecretkey, обмін даними із сервером Custodia. Запишіть ці дані до файла (наприклад, custodia.conf):
[global] server_version = "Secret/0.0.7" server_url = http://localhost:8080/ auditlog = /var/log/custodia.log debug = True [store:simple] handler = custodia.store.sqlite.SqliteStore dburi = /var/lib/custodia.db table = secrets [auth:header] handler = custodia.httpd.authenticators.SimpleHeaderAuth header = MYSECRETNAME value = mysecretkey [authz:paths] handler = custodia.httpd.authorizers.SimplePathAuthz paths = /secrets [/] handler = custodia.root.Root store = simple
Далі, віддайте команду custodia, вказавши файл налаштувань у параметрі командного рядка.
Будь ласка, зверніть увагу на те, що у поточній версії неможливо на загальному рівні переспрямовувати усі запити до екземпляра Custodia. Замість цього слід визначати підрозділи для окремих ідентифікаторів користувачів, які переспрямовуватимуть запити до Custodia. У наведеному нижче прикладі проілюстровано конфігурацію, за якої запити користувача із UID 123 переспрямовуватимуться до Custodia, а запити усіх інших користувачів оброблятимуться локальним засобом надання даних.
[secrets] [secrets/users/123] provider = proxy proxy_url = http://localhost:8080/secrets/ auth_type = header auth_header_name = MYSECRETNAME auth_header_value = mysecretkey
AUTHORS¶
Основна гілка розробки SSSD — https://pagure.io/SSSD/sssd/
NOTES¶
- 1.
- custodia
01/23/2024 | SSSD |