Набір для відновлення

Kept герметизує кожне секретне значення, яке зберігає (ключі ШІ та секрети, що ви зберігаєте на речах, наприклад пароль Wi-Fi роутера), за допомогою KEPT_SECRET_KEY, і підписує сеанси за допомогою KEPT_AUTH_SECRET. Жоден з них не є в базі даних чи резервній копії, навмисно: хтось, хто отримає вашу резервну копію, не має отримати з нею ваші секрети. Інший бік цього: без ключа відновлення повертає все, окрім секретних значень і ключів ШІ, які залишаються назавжди нечитабельними.

Набір для відновлення — це все, що потрібне, щоб відновити Kept з його резервної копії. Зберігайте його в менеджері паролів або на папері, у місці, яке не загубиться разом із сервером.

Що він містить

• KEPT_SECRET_KEY і KEPT_AUTH_SECRET;
• після обертання ключа — версію ключа (KEPT_SECRET_KEY_VERSION) і кожен виведений з експлуатації ключ (KEPT_SECRET_KEYS_RETIRED), які досі потрібні старішим резервним копіям;
• репозиторій restic резервного копіювання, його пароль і облікові дані сховища (ключі S3 і регіон, або ключ SFTP і прив’язаний ключ хоста сервера як рядок known_hosts), або “No backup configured”;
• адресу екземпляра, версію та ревізію Kept, час створення набору;
• кроки відновлення звичайними словами та команди, щоб прочитати ваш інвентар лише з restic, із підставленим репозиторієм.

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

Як його отримати

З сервера в будь-який час:

docker compose exec kept kept admin recovery-kit

Він виводить у термінал; нічого нікуди не записується. --format html дає сторінку для друку, а --out <file> записує його у файл, читабельний лише вами. Ключі друкуються навіть тоді, коли база даних недоступна; частина про резервне копіювання потребує логіну власника бази даних (KEPT_OWNER_DATABASE_URL, compose.override.yaml, що його дають резервні копії), і без нього набір повідомляє, що він відсутній. За наявності цього логіну друк зараховується як завантаження (нижче) і аудитується.

З вебінтерфейсу: Адміністрування → Статус → Набір для відновлення → Завантажити набір для відновлення, як адміністратор екземпляра, лише по HTTPS, після повторного введення пароля (або, для облікового запису без пароля, протягом десяти хвилин після входу: вхід за допомогою ключа доступу зараховується; інакше “Увійдіть знову”). Оберіть текстовий файл або сторінку для друку. Кожне завантаження аудитується, і нічого з набору не зберігається там, де пізніший відвідувач міг би його відкрити.

Коли Kept просить про нього

Налаштування не чекає на набір, але Kept просить вас підтвердити його перед першим з: збереженням секретного значення, додаванням ключа ШІ або налаштуванням резервного копіювання. До того часу Адміністрування → Статус просить про нього; завантаження зараховується як таке підтвердження. Сторінка статусу знову просить про це, коли набір, який ви завантажили, застарів: після зміни налаштувань резервного копіювання або обертання ключа (kept admin rotate-key).

Якщо ви самі задаєте ключі

Якщо KEPT_SECRET_KEY і KEPT_AUTH_SECRET є у вашому власному середовищі (згенеруйте кожен за допомогою kept admin gen-key), Kept використовує їх як є, а том kept-config залишається порожнім. Набір усе одно друкує їх; зберігати копію все одно ваше завдання.

Обертання ключа

docker compose exec kept kept admin rotate-key

робить новий ключ поточним і повторно шифрує під ним кожен збережений секрет. Для цього потрібен логін власника бази даних, тому служба kept має мати KEPT_OWNER_DATABASE_URL (compose.override.yaml, що його дають резервні копії). Він повідомляє, що задати, якщо ви керуєте ключами самостійно. Старий ключ переходить до списку виведених, тож резервні копії, створені до обертання, все ще відкриваються: завантажте новий набір після цього.