SSSD-SECRETS(5)

NAME
sssd-secrets - Відповідач реєстраційних даних SSSD

ОПИС

На цій сторінці довідника описано налаштування засобу надання відповідей Secrets для sssd(8). Щоб дізнатися більше про синтаксис налаштування, зверніться до розділу «ФОРМАТ ФАЙЛІВ» сторінки довідника sssd.conf(5).

У багатьох програмах системи або користувача існує потреба у збереженні конфіденційних даних, зокрема паролів і ключів до служб, та зручній роботі з цими даними. Простим способом вирішення цієї проблеми є вбудовування цих “реєстраційних даних” до файлів налаштувань. Втім, це призводить до потенційного розширення доступу до конфіденційних даних через резервні копії, системи керування налаштуваннями, та загалом робить захист даних важчим.

Проект custodia[1] було створено для урегулювання цієї проблеми у хмароподібних середовищах, але нам ця ідея здалася вартою уваги навіть на рівні окремої ізольованої системи. Як служба захисту, SSSD є ідеальним місцем для реалізації такої можливості з доступом до відповідного програмного інтерфейсу через сокети Unix. Така реалізація уможливлює використання локальних викликів і належну маршрутизацію до локального або віддаленого сховища ключів, зокрема сховища IPA, для зберігання, депонування і відновлення даних.

Записи реєстраційних даних є простими парами ключ-значення. Реєстраційні дані кожного з користувачів співвідносяться із його простором назв на основі ідентифікатора користувача. Це означає, що реєстраційні дані одного користувача ніколи не потраплять до іншого. Реєстраційні дані зберігаються у “контейнерах”, які можна вкладати один у одного.

Since the secrets responder can be used both externally to store general secrets, as described in the rest of this man page, but also internally by other SSSD components to store their secret material, some configuration options, like quotas can be configured per “hive” in a configuration subsection named after the hive. The currently supported hives are:

secrets
    secrets for general usage

kcm
    used by the sssd-kcm(8) service.

КОРИСТУВАННЯ ВІДПОВІДАЧЕМ РЕЄСТРАЦІЙНИХ ДАНИХ

Сокет 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). Крім того, передбачено декілька специфічних для реєстраційних даних параметрів.

The secrets responder is configured with a global “[secrets]” section and an optional per-user “[secrets/users/$uid]” section in sssd.conf. Please note that some options, notably as the provider type, can only be specified in the per-user subsections.

provider (рядок)
    This option specifies where should the secrets be stored. The secrets responder can configure a per-user subsections (e.g. “[secrets/users/123]” - see bottom of this manual page for a full example using Custodia for a particular user) that define which provider store the secrets for this particular user. The per-user subsections should contain all options for that user's provider. Please note that currently the global provider is always local, the proxy provider can only be specified in a per-user section. The following providers are supported:

    local
        Реєстраційні дані зберігаються у локальній базі даних, зашифровані, разом із іншими даними, за допомогою основного ключа. Для локального засобу надання даних у поточній версії не передбачено жодних додаткових параметрів.

    proxy
        Відповідач реєстраційних даних переспрямовує запити до сервера Custodia. Для засобу надання даних «proxy» передбачено декілька додаткових параметрів (див. нижче).

    Типове значення: local

The following options affect only the secrets “hive” and therefore should be set in a per-hive subsection. Setting the option to 0 means "unlimited".

containers_nest_level (ціле значення)
    Цей параметр визначає максимальну дозволену кількість вкладених контейнерів.

    Типове значення: 4

max_secrets (ціле значення)
    This option specifies the maximum number of secrets that can be stored in the hive.

    Default: 1024 (secrets hive), 256 (kcm hive)

max_uid_secrets (integer)
    This option specifies the maximum number of secrets that can be stored per-UID in the hive.

    Default: 256 (secrets hive), 64 (kcm hive)

max_payload_size (ціле значення)
    Цей параметри визначає максимальний об'єм даних для реєстраційного запису у кілобайтах.

    Default: 16 (secrets hive), 65536 (64 MiB) (kcm hive)

For example, to adjust quotas differently for both the “secrets” and the “kcm” hives, configure the following:

    [secrets/secrets]
    max_payload_size = 128
    [secrets/kcm]
    max_payload_size = 256

Вказані нижче параметри стосуються лише конфігурацій, у яких використовується засіб надання даних “proxy”.

proxy_url (рядок)
    Адреса, за якою очікуватиме на дані сервер Custodia. У поточній версії передбачено підтримку протоколів http і https.

    Формат адреси має відповідати формату, що визначається RFC 2732:

    http[s]://<вузол>[:порт]

    Приклад: http://localhost:8080

auth_type (рядок)
    Спосіб розпізнавання сервером Custodia. Передбачено підтримку таких способів розпізнавання:

    basic_auth
        Виконати розпізнавання на основі імені користувача і пароля, які визначено параметрами “username” і “password”.

    header
        Виконати розпізнавання за допомогою значення заголовка HTTP, як його визначено у параметрах налаштування “auth_header_name” і “auth_header_value”.

auth_header_name (рядок)
    Якщо встановлено, відповідач реєстраційних даних додаватиме заголовок із цією назвою до запиту HTTP разом із значенням, яке визначається параметром налаштування “auth_header_value”.

    Приклад: MYSECRETNAME

auth_header_value (рядок)
    Значення, яке sssd-secrets має використовувати для “auth_header_name”.

    Приклад: mysecret

forward_headers (список рядків)
    Список заголовків HTTP, які слід переспрямувати до сервера Custodia разом із запитом.

    Типове значення: not set

verify_peer (булеве значення)
    Визначає, чи слід перевіряти сертифікат вузла і чи слід вважати його чинним, якщо для засобу надання даних проксі використано протокол HTTPS.

    Типове значення: true

verify_host (булеве значення)
    Визначає, чи має назва вузла збігатися із назвою вузла у його сертифікаті, якщо для засобу надання даних проксі використано протокол HTTPS.

    Типове значення: true

capath (рядок)
    Шлях до каталогу, у якому зберігаються сертифікати служб сертифікації. Якщо для цього параметра не встановлено значення, використовуватиметься загальносистемний типовий шлях.

    Типове значення: not set

cacert (рядок)
    Шлях до файла, у якому міститься сертифікат служби сертифікації сервера. Якщо для цього параметра не встановлено значення, програма шукатиме сертифікат CA у “capath”.

    Типове значення: not set

cert (рядок)
    Шлях до файла, що містить клієнтський сертифікат, якщо такий потрібен для сервера. Цей файл може також містити закритий ключ. Закритий ключ можна також зберігати у файлі, назву якого встановлено за допомогою параметра “key”.

    Типове значення: 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/.

Отримання списку реєстраційних даних
    Щоб отримати список доступних реєстраційних даних, надішліть запит HTTP GET із кінцевою навскісною рискою у шляху до контейнера.

    Приклад:

        curl -H "Content-Type: application/json" \
             --unix-socket /var/run/secrets.socket \
             -XGET http://localhost/secrets/

Отримання реєстраційних даних
    Щоб прочитати значення окремого запису реєстраційних даних, надішліть запит HTTP GET без кінцевої навскісної риски. Остання частина адреси вважатиметься назвою запису реєстраційних даних.

    Приклади:

        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”, надішліть запит HTTP PUT із даними JSON, які включатимуть тип і значення. Тип (type) має бути встановлено у значення "simple", а значення (value) має містити дані реєстраційного запису. Якщо запис із вказаною назвою вже існує, відповіддю буде повідомлення про помилку 409 HTTP.

    Тип “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'

Створення контейнера
    Контейнери надають додатковий простір назв для реєстраційних даних цього користувача. Для створення контейнера надішліть запит HTTP POST, чи я адреса завершуватиметься назвою контейнера. Будь ласка, зауважте, що адреса має завершуватися символом навскісної риски.

    У наступному прикладі створюємо контейнер із назвою «mycontainer»:

        curl -H "Content-Type: application/json" \
             --unix-socket /var/run/secrets.socket \
             -XPOST http://localhost/secrets/mycontainer/

    Щоб працювати із записами реєстраційних даних у цьому контейнері, просто вкладіть записи реєстраційних даних до шляху контейнера:

        http://localhost/secrets/mycontainer/mysecret

Вилучення реєстраційних даних або контейнера
    Щоб вилучити запис реєстраційних даних або контейнер, надішліть запит HTTP DELETE із шляхом до запису реєстраційних даних або до контейнера.

    У наведеному нижче прикладі ми вилучимо реєстраційні дані для запису «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
    https://github.com/latchset/custodia