NAME

ОПИС

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

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

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

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

secrets

kcm

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

Відповідач для реєстраційних даних активується за допомогою сокетів 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
            

Будь ласка, зауважте, що відповідні налаштування модулів вже могло бути виконано засобами вашого дистрибутива.

ПАРАМЕТРИ НАЛАШТУВАННЯ

Відповідач реєстраційних даних налаштовується за допомогою загального розділу “[secrets]” і необов'язкових розділів “[secrets/users/$uid]” для окремих користувачів у sssd.conf. Будь ласка, зауважте, що деякі параметра, зокрема тип постачальника даних, можна вказати лише у підрозділах окремих користувачів.

provider (рядок)

Наведені нижче параметри стосуються лише записів реєстраційних даних “hive” і тому їх слід встановлювати у підрозділах окремих роїв. Встановлення значення параметра 0 означає «без обмежень».

containers_nest_level (ціле значення)

max_secrets (ціле значення)

max_uid_secrets (ціле число)

max_payload_size (ціле значення)

Наприклад, щоб встановити різні квоти для роїв “secrets” та “kcm”, скористайтеся такими рядками:

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

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

proxy_url (рядок)

auth_type (рядок)

auth_header_name (рядок)

auth_header_value (рядок)

forward_headers (список рядків)

verify_peer (булеве значення)

verify_host (булеве значення)

capath (рядок)

cacert (рядок)

cert (рядок)

key (рядок)

КОРИСТУВАННЯ API REST

Отримання списку реєстраційних даних

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
                        

Встановлення реєстраційних даних

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'
                        

Створення контейнера

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

http://localhost/secrets/mycontainer/mysecret
                        

Вилучення реєстраційних даних або контейнера

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

ПРИКЛАД НАЛАШТОВУВАННЯ МОДУЛІВ НАДАННЯ ДАНИХ 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

NOTES

1.

custodia