Вопрос или проблема
Следуя из другого вопроса, у меня работает демон LXD:
$ curl --insecure https://127.0.0.1:8443
{"type":"sync","status":"Success","status_code":200,"operation":"","error_code":0,"error":"","metadata":["/1.0"]}
Однако, при попытке запустить контейнер Vagrant с провайдером LXD, ему не нравится сертификат:
$ vagrant up
Провайдер не смог аутентифицироваться на демоне LXD по адресу https://127.0.0.1:8443.
Возможно, вам нужно настроить LXD для разрешения запросов с этой машины. Самый
простой способ сделать это — добавить сертификат клиента LXC в список доверенных
сертификатов LXD. Обычно это можно сделать с помощью следующей команды:
$ lxc config trust add /home/username/.config/lxc/client.crt
Вы можете найти больше информации о настройке LXD по адресу:
https://linuxcontainers.org/lxd/getting-started-cli/#initial-configuration
На моей системе нигде нет client.crt. lsof -p [PID программы, работающей на порте 8443]
не перечисляет никаких сертификатов. sudo locate .crt | grep lxd
нашла только /var/lib/lxd/server.crt
, но lxc config trust add /var/lib/lxd/server.crt
не помогло. Документация по настройке не упоминает необходимость доверия сертификату. Я подозреваю, что мне нужно общаться с демоном через Unix-сокет, а не через HTTPS. Как я могу двигаться дальше?
Для справки, мне удается запускать контейнеры, например, с помощью lxc launch ubuntu:18.10 test
и получать оболочку с lxc exec test -- /bin/bash
, так что LXC работает нормально.
Я неправильно понял ситуацию. Похоже, создание нового сертификата и доверие к нему работает:
openssl req -x509 -newkey rsa:2048 -keyout ~/.config/lxc/client.key -nodes -out ~/.config/lxc/client.crt -subj "/CN=lxd.local"
lxc config trust add ~/.config/lxc/client.crt
Для получения client.crt
Выполните
openssl s_client -connect 127.0.0.1:8443
И скопируйте и вставьте первый представленный сертификат, исключая строки
-----BEGIN CERTIFICATE-----
и
-----END CERTIFICATE-----
.
Ответ или решение
Чтобы решить проблему с доверием самоподписанного TLS-сертификата LXD-демона в Vagrant, необходимо предпринять ряд шагов, которые позволят корректно взаимодействовать с LXD. В данном случае, проблема связана с тем, что Vagrant не может аутентифицировать соединение с LXD-демоном из-за отсутствия доверенного сертификата. Описанные действия помогут разрешить эту ситуацию.
Шаги по доверительной настройке LXD-демона:
-
Создание самоподписанного сертификата клиента:
Начните с создания сертификата с помощью OpenSSL. Введите следующую команду в терминале:openssl req -x509 -newkey rsa:2048 -keyout ~/.config/lxc/client.key -nodes -out ~/.config/lxc/client.crt -subj "/CN=lxd.local"
Эта команда создаст новую пару ключей и сертификат клиентской стороны, который будет использован для аутентификации с LXD-демоном.
-
Добавление сертификата клиента в доверенные сертификаты LXD:
После генерации сертификата клиентской стороны, его необходимо добавить в список доверенных сертификатов LXD:lxc config trust add ~/.config/lxc/client.crt
Этот шаг критически важен, поскольку он позволяет LXD распознавать ваш клиентский сертификат как доверенный.
-
Получение текущего сертификата сервера (опционально):
Для проверки текущего сертификата сервера вы можете использовать OpenSSL:openssl s_client -connect 127.0.0.1:8443
Полученный сертификат нужно скопировать, начиная с строки
-----BEGIN CERTIFICATE-----
и заканчивая-----END CERTIFICATE-----
. -
Проверка работы:
После выполнения предыдущих шагов, повторите командуvagrant up
. Если все было сделано правильно, Vagrant должен успешно аутентифицировать соединение и запустить контейнер.
Можно ли использовать Unix-сокеты вместо HTTPS?
Да, альтернатива использованию HTTPS для взаимодействия с LXD — переход на использование Unix-сокетов. Это позволяет избежать проблем с сертификатами, так как Unix-сокеты используют локальные системные механизмы аутентификации. Однако это будет работать только если ваш сценарий использует исключительно локальные ресурсы.
Эти шаги позволят вам легко интегрировать Vagrant с LXD, используя корректные конфигурации и доверительные отношения. Доверие самоподписанным сертификатам — стандартная практика при работе в локальных или тестовых средах, особенно когда контроль над всеми аспектами связи находится в вашем распоряжении.