Nebula потребує трьох файлів: CA, сертифіката хоста і ключа хоста

Якщо дати комусь каталог Nebula, він зазвичай копіює все, включно з файлом, який ніколи не повинен залишати вашу робочу станцію. Плутанина зрозуміла, бо три файли в блоці PKI хоста виглядають однаково, і два з них — сертифікати. Кожен відповідає на своє питання, і лише два з них належать вузлу. Розкладіть їх за ролями, перш ніж щось копіювати.

Три файли, три різні завдання

Сертифікат CA — це якір довіри: він каже хосту, яким центрам вірити, коли інший хост пред'являє свою особу. Сертифікат хоста — це власне посвідчення вузла, підписане цим центром. Ключ хоста — відповідна закрита половина, і він належить рівно одній машині. Вузол із сертифікатом CA і власною парою може приєднатися до overlay і довести, хто він. Вузол із чужим ключем також може видавати себе за цю людину, і саме цю помилку покликана запобігти така схема.

Тому копіювання робочого каталогу хоста на другу машину — не короткий шлях. Це дубльована особа з передбачуваним результатом.

Ключ підпису ніколи не подорожує

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

Якщо сертифікати мають видавати кілька людей, дайте їм процес, а не копію ключа. Спільний ключ підпису на ноутбуці — це повноваження, яке ніхто не може перевірити чи відкликати.

Що міститься в сертифікаті хоста

Сертифікат хоста прив'язує до ключа не лише ім'я файлу. Він несе адресу вузла в overlay, його ім'я та членство в групі, усе підписано, щоб пір міг вирішити, чи приймати його. Тому перейменування хоста означає видачу нового сертифіката, а не редагування рядка конфігурації.

nebula-cert print -path host.crt показує, що насправді було видано. Прочитайте його, перш ніж припускати, що сертифікат містить потрібну вам адресу.

Перезавантаження не завжди достатньо

Деякі налаштування PKI перезавантажуються за сигналом, а деякі ні.Сертифікат, у якого змінилася адреса в overlay — класичний випадок, що потребує перезапуску процесу, а не перезавантаження.

Переконайтеся, які шляхи процес насправді відкрив, а не лише які шляхи називає файл конфігурації. Потім змініть одне посвідчення, перевірте з'єднання та журнали, і лише після цього беріться за наступне. Перезавантаження, яке виглядає успішним, поки старий сертифікат залишається в пам'яті, створює невідповідність, схожу на проблему маршрутизації. Перезапуск дешевий; налагодження особи, яку половина overlay досі бачить по-старому, — ні.

Видалення особи потребує списку блокування

Заміна втраченого або розкритого посвідчення має дві половини. Новий сертифікат повертає доступ, а стару особу треба перестати приймати. Це окремі операції, і виконання лише першої залишає скомпрометоване посвідчення чинним.

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