Infisical - это самостоятельный менеджер по секретам. Он хранит учетные данные, необходимые вашим приложениям, и передает их в процесс во время выполнения, поэтому ничего чувствительного не должно сидеть в файле на коробке. Причина запуска одного - это счет: ваш пароль производственной базы данных находится в .env на сервере приложения, в переменной CI, в потоке Slack с того дня, как сломался сервис, и в чьей-то истории оболочки. Никто не вращает его, потому что никто не может найти каждый экземпляр.
В этом руководстве показано, как установить Inficial на собственном сервере. Ставим перед ним Nginx и сертификат Let’s Encrypt, а затем проходит полный путь, который выполняет настоящий секрет: создать проект, хранить секрет, дать приложению свою собственную личность машины и введите значение в системный сервис, который никогда не записывает его на диск. Каждая команда ниже была запущена на Ubuntu 26.04 LTS
Предпосылки
- Сервер под управлением Ubuntu 26.04
- Права пользователя: пользователь root или обычный пользователь с привилегиями sudo.
Конвенции
| |
Шаг 1. Обновите систему
Свежая установка Ubuntu 26.04 LTS требует обновления пакетов до последних доступных версий.
| |
Система может нуждаться в перезагрузке после обновления.
| |
Шаг 2. Установка Infisical
Теперь нам нужно загрузить последнюю соответствующую версию Infisical добавим репозиторий:
| |
Шаг 3. Установка PostgreSQL
Установите пакет Postgres.
| |
Шаг 4. Создание базы данных
Нам нужно создать базу данных для Infisical.
| |
Шаг 5. Создайте файл конфигурации
Сначала создайте два секрета:
| |
Пакет считывает конфигурационный файл в стиле Ruby, а не переменные среды.
Затем создайте каталог конфигурации и откройте файл. Этот файл содержит строки подключения к базе данных и другие настройки времени выполнения.
| |
Вставьте пять необходимых настроек, заменив только что созданные значения:
| |
Этот файл - драгоценности короны экземпляра, так что заприте его, прежде чем идти дальше:
| |
Применяйте конфигурацию. Шаг перенастройки запускает миграцию и запускает контролируемую службу:
| |
Сервер работает на порту 8080 по умолчанию (настраиваемый в infisical.rb).
Проверьте сервис и подтвердите ответы API. Обратите внимание, что хвост infisical-ctl следует за журналом и не выходит, поэтому используйте статус для скриптов:
| |
Здоровая установка печатает контролируемый процесс и HTTP 200:
| |
Шаг 6. Настройте Nginx в качестве обратного прокси
| |
Создайте обратный конфигурацию прокси-сервера для infisical.
| |
Заполните файл следующей конфигурацией.
| |
Включите конфигурацию обратной прокси-сервера Infisical Nginx.
| |
Проверка конфигурации и перезагрузите службу Nginx.
| |
Затем посетите веб-сайт по адресу http://secrets.example.org для доступа.
Шаг 7. Получите сертификат TLS от Let’s Encrypt
Мы будем использовать Let’s Encrypt для получения SSL-сертификата бесплатно. Пожалуйста, убедитесь, что вы указали свой поддомен на IP-адрес сервера. Шаги, приведенные ниже, будут работать только в том случае, если вы обслуживаете интерфейс управления с помощью Nginx.
| |
Запрос на Let’s Encrypt SSL.
| |
Проверьте SSL
Откройте следующую ссылку в вашем веб-браузере для проверки.
| |
Следующая команда гарантирует, что Certbot может проверить ваш поддомен с помощью вашей конфигурации.
| |
Если пробный запуск прошел без ошибок, все готово. Теперь процесс продления будет автоматизирован.
Он автоматически настраивает /etc/nginx/sites-available/infisical.conf для включения SSL.
Шаг 8. Создайте учетную запись администратора
Просмотрите свой домен и Infisical отправит вас на /admin/signup. Первая созданная учетная запись становится супер-администратором экземпляра, что означает, что тот, кто впервые попадает на эту страницу, владеет вашими секретами. Создайте его сразу после начала службы, а не завтра.
После того, как создали учетную запись, название организации, а затем мастер настройки задает вопрос, который наиболее важен в публичном случае: кто может создавать учетные записи. Оставьте его только по приглашению, если у вас нет причины этого не делать, и обрежьте методы входа до тех, которые вы действительно используете.
Не читайте поле inviteOnlySignup на конечной точке статуса в качестве подтверждения. Он отражает внутренний флаг разрешительной подписи, а не описывает политику, которую предлагает его название, поэтому плохо быть начеку. Вместо этого проверьте настройку в консоли сервера и подтвердите ее, открыв страницу регистрации в частном окне.
Шаг 9. Создайте проект и храните первый секрет
Проекты являются единицей изоляции. Внутри проекта вы получаете среды, которые по умолчанию разрабатывают, и постановку и производство, и папки для группировки секретов по службе или по пути. Доступ предоставляется в каждом проекте, поэтому форма ваших проектов становится формой вашего радиуса взрыва позже.
Создайте один из страниц продукта Secrets Management, назовите его в честь сервиса, который будет его потреблять, а затем добавьте секреты с панелью «Добавить секретность». Значения маскируются в списке до тех пор, пока вы не нажмете «Откровите значения», что является правильным по умолчанию для экрана, которым кто-то может поделиться:
Шаг 10. Дайте приложению собственную идентификацию машины
Приложения никогда не должны входить в систему как личность. Нечеловеческие модели нечеловеческих клиентов в качестве машинных идентичностей, и метод аутентификации по умолчанию для них - Universal Auth: идентификатор клиента и секрет клиента, которые обменивают на недолговечный токен доступа. Идентификатору предоставляется роль в конкретных проектах, поэтому она читается только то, к чему вы ее прикрепили.
Создайте один под контролем доступа, машинные идентификаторы. Дайте ему название рабочей нагрузки, а не человека, который его сделал, выберите роль члена организации, а затем добавьте его в проект с ролью зрителя, если ему нужно только читать. Доступными ролями проекта являются Admin, Member, Viewer и No Access.
Откройте метод Universal Auth на личность, чтобы найти идентификатор клиента и создать секрет клиента. Внимательно прочитайте настройки токенов на этой панели, потому что по умолчанию щедры:
Токен доступа TTL и max TTL по умолчанию до 2592000 секунд, что составляет тридцать дней. Притч, который живет в течение месяца, едва ли короче, чем полномочия, которые он должен был защищать. Отредактируйте метод и установите TTL на длину разворачивания, измеренную за считанные минуты, и max TTL до чего-то часа или меньше. Доверенные полевые поля IP по умолчанию 0.0.0.0/0 и ::/0 таким образом, сужение только входа IPv4 оставляет дверь открытой на IPv6, и оба могут быть ограничены вашим диапазоном выхода CI. Локаут включен по умолчанию при трех неудачных попытках с пятиминутным локаутом.
Секрет клиента раскрывается ровно один раз. Храните его там, где рабочая нагрузка может прочитать его и нигде больше.
Шаг 11. Введите секреты в реальный сервис
Установите CLI на машину, которая выполняет рабочую нагрузку. Это отдельный пакет от сервера, опубликованный в собственном репозитории:
| |
Направьте CLI на свой собственный пример и обменивайте учетные данные личности на токен. Использовать INFISICAL_DOMAIN, который имеет приоритет над старшим INFISICAL_API_URL когда оба установлены. Суффикс /api является необязательным в любом случае, потому что CLI добавляет его, когда он отсутствует:
| |
Прочтите секреты, которые позволяет увидеть личность. Идентификатор проекта поступает из URL-адреса проекта или страницы его настроек:
| |
CLI печатает таблицу всего по объему и ничего, что не выходит за рамки:
| |
Теперь запустите приложение через infisical run, который извлекает секреты и передает их в детский процесс в качестве переменных среды:
| |
То же приложение, запущенное без обертки, ничего не находит, и на диске в любом случае нет .env:
| |
Это счастливый путь, и именно здесь останавливается большинство записей. Следующая часть - почему они не должны.
Шаг 12. Накопление личности не охватывает процесс
Вот часть скипа swiftстартов. Обертка, которая испрашивает файл учетных данных, а затем звонит в CLI, оставляет идентификатор клиента и клиент секретом в среде приложения, которое она запускает. Все, что может запустить оболочку внутри вашего приложения, может читать их, отчеканить свежие жетоны навсегда, и ваш тщательно сокращенный TTL ничего не значит.
Проверка детской процессной среды показывает, какие именно утечки:
| |
Три из этих четырех строк являются учетными данными, а не конфигурацией:
| |
Исправление стоит одной команды. Удалите учетные переменные в течение последнего времени, чтобы приложение унаследовало значения, а не учетные данные, которые их принесли:
| |
Та же проверка теперь возвращает одну безвредную линию, адрес конечной точки:
| |
Делать это вручную каждый раз - это то, как это забывается, поэтому включите это в определение службы.
Шаг 13. Системный блок, который объединяет
Настройка INFISICAL_UNIVERSAL_AUTH_CLIENT_ID и INFISICAL_UNIVERSAL_AUTH_CLIENT_SECRET Недостаточно само по себе, что является первым, что большинство людей пробует. CLI игнорирует их для run и попадает в интерактивный логин, который выходит из строя в условиях системы. Крошечная обертка обрабатывает обмен. Создать его:
| |
Он входит в систему, заменяет себя CLI и удаляет учетные данные из того, что будет дальше:
| |
Сделайте его исполняемым, затем создайте файл учетных данных, который будет считываться:
| |
Шесть строк, и только две из них являются секретными. Проверка обновления отключена, поэтому CLI не обращается к GitHub каждый раз, когда устройство перезапускается:
| |
Ограничьте его учетной записью службы, которая нуждается в нем, поэтому скомпрометированный веб-процесс не может прочитать идентификатор:
| |
Теперь о самом подразделении.
| |
Полномочия прибывают через EnvironmentFile и никогда не появляться в подразделении или в ps выходной:
| |
Теперь вы можете перезагрузить систему и запустить billing-api.
| |
Сервис придумывает свою конфигурацию уже в памяти:
| |
Проверьте затвердевание, прочитав рабочую среду процесса напрямую, что является единственной проверкой, которая фактически доказывает это. Основной PID устройства - обертка CLI; приложение - его ребенок:
| |
Раскол - это весь смысл. Обертка содержит учетные данные и никаких секретов; приложение содержит секреты и никаких учетных данных. Рабочая нагрузка в этой лаборатории была заглушкой раковины, которая заканчивается sleep, поэтому детский процесс сообщает, что имя:
| |
Теперь ротация работает так, как и предполагалось. Измените значение в пользовательском интерфейсе, перезапустите службу, и новое значение будет жить без развертывания, перестроенного изображения или запуска управления конфигурацией. Рабочие нагрузки Kubernetes получают такое же поведение через оператора, а не через CLI, и оператор внешних секретов является нейтральным для поставщика способом подключения к нему, если вы уже используете его.
Завершение
В настоящее время на Ubuntu 26.04 LTS установлена корректная установка Infisical с правильным TLS-шифрованием и CLI и веб-доступом. Ваш сервер Infisical готов надежно хранить и управлять секретами для вашей инфраструктуры.
Вы можете поделиться статьей со своими друзьями в социальных сетях, которым может быть интересна эта статья или просто оставить комментарий ниже. Спасибо.