Файл sops что это
В настоящем документе были внесены следующие изменения:
• Начиная с SDP3 2.22 содержание данного документа будет находиться под заголовком Управление SOPS.
При замене электронных блоков управления автомобилей или при выполнении манипуляций с ними возможно случайное повреждение файла SOPS или внесение в него ошибок. В этом документе дана информация и рекомендации по устранению таких проблем.
Блоки-носители SOPS.
В стандартном грузовике Scania файл SOPS размещается в двух блоках, которые именуются "носителями SOPS". Это ICL и координатор (COO). Периферические блоки поддерживают коммуникацию с остальным электронным оборудованием после того как выполнены процедуры идентификации и программирования запасных частей. Они получают одинаковые идентификационные номера и контролируют передаваемую информацию. Имеются два блока-носителя SOPS (ICL и COO), каждый из которых имеет собственный файл SOPS (это копии одного файла). К системе также подключен другой блок управления, например, GMS, имеющий такой же идентификационный номер.
Распространенные проблемы в работе с файлом SOPS.
Четыре наиболее распространенные проблемы из-за ошибок, допущенных в работе:
• Файл SOPS отсутствует: Файл вообще отсутствует. Это распространенная проблема, если новый блок был приобретен как запасная часть. Также эта проблема может возникнуть, если модуль VCI
был отключен во время работы.
• Файл SOPS пустой: Файл SOPS и, возможно, сетевое окружение для него имеются, однако файл пустой или не содержит никакой значимой информации. Также эта проблема может возникнуть, если модуль VCI был отключен во время работы.
• Файл SOPS поврежден: Файл поврежден, и пропали важные разделы информации. Также эта проблема может возникнуть, если модуль VCI был отключен во время работы.
• Файл SOPS не совпадает: В блоке-носителе SOPS записан файл SOPS, который отличается от файла, записанного в автомобиле. Это распространенная проблема, возникающая, когда в качестве
замены устанавливают блок, ранее использовавшийся на другом автомобиле.
Как система SDP3 выбирает, какой файл SOPS следует использовать.
Система SDP3 автоматически определяет, какой файл SOPS следует использовать, если файлы в двух блоках-носителях SOPS повреждены или отличаются один от другого. Если в автомобиле имеются два разных файла SOPS, система SDP3 проверяет, какой из вариантов имеет больше совместимых периферических блоков управления. Если требуется замена нескольких блоков управления, замену следует выполнять поэтапно, чтобы система SDP3 не выбрала неверный файл SOPS. Не выполняйте установку нескольких блоков управления одновременно. Файл SOPS из координатора (СОО) будет выбран, если два этих подсоединенных блока являются единственными носителями файла SOPS. Координатор (СОО) является основным носителем файла SOPS.
В блоке управления отсутствует файл SOPS.
Если блок-носитель SOPS заменяется запасной частью, не имеющей файла SOPS, система SDP3 скопирует существующий файл SOPS и запишет его в новый блок управления.
Файл SOPS в блоке управления пустой.
Если в блоке-носителе SOPS имеется пустой файл SOPS, применяется та же процедура, что и при замене блока-носителя SOPS.
Файл SOPS в блоке управления поврежден.
Применяется та же процедура, что и при замене блока-носителя SOPS; поврежденный файл SOPS заменяется тем файлом, который имеется в автомобиле.
Отсутствующий, пустой или поврежденный файл SOPS в обоих блоках управления-носителях SOPS.
Если были заменены оба блока-носителя SOPS, и файл SOPS в них пустой, поврежден или отсутствует, следует заказать оригинальный файл SOPS автомобиля в Глобальной службе технической поддержки Scania. Для этого необходимо создать запрос в системе FRAS , в разделе "Техническая поддержка". Приложите к запросу регистрационные файлы и демо-файл. Затем файл SOPS можно будет загрузить в разделе "Модернизация". Выберите "Выполнение модернизации с использованием файла SOPS, полученного от компании Scania" в разделе "Регулировка" системы SDP3. По крайней мере один из этих блоков должен иметь такой же идентификационный номер, что и файл SOPS.
Не совпадающий файл SOPS в ICL и COO.
Если оба блока-носителя SOPS заменены блоками, которые ранее были в эксплуатации и в которых уже имеется файл SOPS, возникает проблема, которая не может быть решена напрямую через систему SDP3. Проблема также может возникнуть из-за небрежности, при замене блока-носителя SOPS, ранее бывшего в эксплуатации, одновременно с несколькими периферическими блоками управления. Система SDP3 может выбрать некорректный вариант, если блоков управления, которые эксплуатировались на другом автомобиле, больше, чем оригинальных блоков
управления автомобиля. Обратитесь в Службу глобальной технической поддержки Scania за дополнительной информацией о решении этой проблемы. Для этого необходимо создать запрос в системе FRAS , в разделе "Техническая поддержка". Приложите к запросу регистрационные файлы и демо-файл.
Описание: Программа Скания SOPS предназначена для профессионального редактирования файлов конфигурации грузовых автомобилей Scania. Вы сможете изменить и настроить под себя более трехсот различных параметров.
Для работы с грузовиками скания, а именно для скачивания и закачивания файла конфигураций необходим адаптер Scania VCI-2.
Доступ к секрету
sops предлагает несколько опций:
Расшифровка файла на stdout. (обычный режим -d )
Расшифровка файла in place; -d -i
Открытие расшифрованной копии на редактирование (для интерактивной работы с файлом), это режим по-умолчанию при запуске sops myfile.yaml .
Запуск указанной программы с путём к временному файлу (fifo или обычному файлу), который удаляется по завершению программы; sops exec-file .
Запуск программы с выставлением переменных окружения из шифрованного файла; sops exec-env
Извлечение значения по имени ключа из шифрованного файла (когда нужен один секрет из множества); --extract в сочетании с другими опциями.
Весьма интересной особенностью является возможность выставления переменных среды окружения из yaml-файлов, что делает их редактирование куда приятнее, чем редактирование самих env-файлов. В yaml доступны всякие вкусные конструкции с многострочным представлением вместо борьбы за эскейпинг третьей вложенности кавычек в обычном env'е.
Модель хранения секретов
Sops использует два понятия:
секрет - информация, которая хранится в зашифрованных файлах и расшифровывается в нужный момент.
мастер-ключ - то, с помощью чего расшифровывают секреты. В случае GPG это приватный ключ. Для одного файла с секретами может использоваться несколько мастер-ключей.
Sops использует внешнего поставщика "мастер-ключей" для хранения секретов. Среди них pgp/gpg (для локальной разработки), Hashicorp Vault (для интеграции в существующие системы под его управлением), KMS в Amazon'е, Google'е и Microsoft'е, и многие другие. В этой статье я буду фокусироваться на сценариях с pgp (в форме gpg), как наиболее удобных для знакомства и для локальной работы. Соответственно, ожидается, что у вас уже есть приватный ключ в GPG keyring'е.
В SOPS шифруемые секреты доступны для просмотра (для доверенных участников). Для разных файлов секретов список участников может быть разный.
Для шифрования достаточно иметь публичные ключи всех участников (а для просмотра - хотя бы один приватный). Если приватного ключа нет, получаются "слепые секреты" (создающий новый секрет не может его потом прочитать). Поддерживается система разделения мастер-ключа (алгоритм Шамира, когда для открытия секрета надо более одного участника).
Шифрованные файлы планируется хранить в гите и они адаптированы к читаемости в diff'е при изменении.
Киллер-фича sops (для меня) — одновременная поддержка и частичного шифрования файлов, и их rekeying (смену ключей). Это функция, которой отчаянно не хватает в ansible-vault.
Rekeying
Одной из проблем при управлении секретами является удаление доступа к файлам у людей (и серверов), которые это право потеряли. Не смотря на то, что человек, теоретически, мог раньше секрет скопировать, отзыв доступа к секретам (при увольнении или переходе в другую команду) — это всё равно крайне важная операция. Аналогичная же проблема возникает и при добавлении нового сотрудника — ему нужно добавить ключ на доступ.
В sops рекеинг выполняется простой командой sops updatekeys для каждого файла. Дальше он спрашивает, действительно ли убрать/добавить ключ, показывая их оттиски (fingerprints), в соответствии с конфигом .sops.yaml . Поменяли конфиг, sops его учитывает. Не меняли конфиг — сообщает, что менять нечего. До выполнения какой-то операции с файлами секретов конфиг игнорируется (т.е. смена конфига не приведёт автоматически к перешифровке всех файлов).
Требования к идеальному решению по управлению секретами
- Универсальность (может работать и в облаке, и локально).
- Легкое взаимодействие с любыми технологическими стэками через REST API или платформы включающие CLI binaries (бонусом будет беспрепятственная интеграция с Terraform, Ansible, Kubernetes, и CI/CD Pipelines).
- Необходимость соответствовать требованиям завтрашнего дня.
- Открытый исходный код/Бесплатно (нет риска исчезновения сервиса, или скачков цены).
- Большое сообщество или длинная история поддержки разработчиками (у меня нет желания пользоваться заброшенными проектами, кроме нестареющего/завершенного ПО, как Unix Utilities).
- Легко масштабируется и предлагает высокую доступность.
- Шифрование хранящихся данных.
- Шифрование передаваемых данных.
- Доступ к данным должен быть отзываемым.
- Уязвимости должны быть известны, а контрмеры применены.
- Разработчик должен иметь возможность управлять своими секретами, но не продакшна.
- Глава проекта может управлять секретами и разработчика, и продакшна.
- Изоляция на уровне проекта: Глава проекта «А» не должен видеть секреты продакшна проекта «Б».
Note: Mozilla SOPS также соответствует моим требованиям, но тогда это не было очевидно, потому что изначально я полагал, что нет безопасного способа хранить зашифрованные секреты в git.
Эволюция Криптографии вкратце
- Симметричные ключи шифрования:
- Длинный пароль используемый и для шифрования, и для расшифровки.
- Асимметричное шифрование с парой ключей — публичным и приватным:
- Публичный ключ шифрует данные, а приватный дешифрует
- HSM (Модули аппаратной безопасности)
- Сделайте так, чтобы приватный ключ не смогли украсть.
- HSM — дорогой.
- HSM — неудобен ни для пользователя, ни для автоматизации.
- Облачный KMS (сервис управления ключами):
- KMS это доверенный сервис. Он шифрует и дешифрует данные от имени клиента, что позволяет пользователю или компьютеру, по сути, выполнять процесс шифровки-дешифровки используя данные личности, а не ключи (Клиент аутентифицируется с помощью KMS, который проверяет их личность через ACL. Если проверка успешна, клиент может посылать зашифрованные данные в запросе KMS. Информация далее дешифруется от имени клиента и посылается в открытом виде назад, к пользователю, через защищенный TLS канал).
- KMS – дешевый.
- KMS доступен через REST API, т.е. удобен и для пользователей, и для автоматизации.
- KMS крайне безопасен. Он дает возможность десятилетиями избегать утечек ключей.
- Изобретение принципа шифрования KMS ввело три убойные возможности:
- При реагировании на известное нарушение:
Без KMS: ключи шифрования утекают к злоумышленникам, и вы не можете аннулировать их. Это означает, что вам нужно изменить несколько ключей, заново зашифровать все данные с новыми ключами и постараться как только можете, чтобы удалить старые зашифрованные данные. Пока занимаетесь этим, вам необходимо "сражаться" с начальством за время простоя для нескольких продакшн систем и минимизировать это время. Даже если вы сделаете все правильно, может так случиться, что не будет возможности полностью удалить старые данные, как в случае с историей git и резервными копиями.
Вместе с KMS: учетные данные личности утекают к злоумышленникам. Однако эти данные могут быть отозваны, и в таком виде становятся для вора бесполезными. Исчезает кошмар с повторной шифровкой данных и удалением всей старой информации. Вам все еще необходимо изменять секреты (учетные идентификационные данные vs ключи шифрования), однако этот процесс становится достаточно дешевым для автоматизации и профилактики. - Менеджмент шифрованных данных превращается из невыполнимой – в тривиальную задачу управления централизованным ACL. Становится возможным с легкостью отзывать, изменять, подтверждать доступ к данным. Как бонус: с тех пор, как Cloud KMS, IAM, и SSO Identity Federations стали взаимодействовать, вы можете использовать уже существующие идентификаторы пользователей.
- Становится возможным использование методов Crypto Anchoring:
Изучение продвинутых технологий шифрования дало мне понять, что KMS мог быть использовать для предотвращения утечек ключей. Это, плюс возможность отозвать права дешифровки без необходимости каких-либо изменений в зашифрованных файлах, делает реальностью по-настоящему безопасное хранение секретов в Git. Я пересмотрел несколько ранее отвергнутых решений на основе Git. Удивительно, но Mozilla SOPS полностью соответствует моим критериям идеального решения по управлению секретами. Оно так же хорошо взаимодействует с инструментами CICD pipeline: SOPS Terraform Provider, Helm Secrets – лишь оболочка для SOPS и вы всегда можете откатить до:
(где kubectl может быть любой утилитой CLI, принимающей стандартный ввод)
SOPS не имеет недостатков других решений, основанных на базе Git:
SOPS не имеет недостатков Vault:
Ему не нужна инфраструктура, поэтому SOPS дешевый, как и KMS. Вы можете легко его настроить, обучить пару людей и написать readme меньше чем за час. Вот пример, как легко он настраивается и используется:
(Создайте файл с именем .sops.yaml со следующими двумя строками)
Это откроет редактор vim, и вы сможете указать что именно вы хотите хранить в секрете. Эта простая команда используется и для создания, и для редактирования файлов.
Это покажет вам зашифрованный yaml
Покажет расшифрованный yaml
SOPS использует данные для входа от AWS, которые хранятся в ~/.aws, для авторизации через KMS, поэтому вы можете производить процесс шифровки/дешифровки без пароля. Также SOPS рекурсивно ищет файл .sops.yaml, в котором содержатся метаданные о том, как необходимо шифровать и расшифровывать данные. Все это приводит к двум важным выводам: во-первых, пользователю не нужно учить тонну команд или флагов. Во-вторых, дополнительный файл .sops.yaml может быть добавлен в подкаталог, представляющий производственное окружение или другой проект, так, чтобы .sops.yaml мог содержать другой, отличающийся ключ шифрования.
Вы можете предоставить разным пользователям Cloud IAM разные права на каждый ключ KMS, чтобы обеспечить детальный контроль доступа. Если вы беспокоитесь об удалении вашего ключа AWS KMS посторонним, то есть возможность настроить SOPS так, что данные будут шифроваться AWS, GCP, или Azure KMS решениями. Так можно будет хранить вторичную резервную копию KMS с ограниченным доступом.
SOPS поддерживает шаблоны рабочих процессов, что делает жизнь проще. Разработчики могут хранить свои секреты зашифрованными прямо под рукой, и синхронизировать их под версию проекта актуальную для этих секретов. Управление секретами сразу получает все преимущества git: легко проверяемый менеджер изменений, рецензирование через запрос загрузки. Различия в редактировании так же значимы: только измененные значения будут обновлены, тогда как раньше приходилось заново шифровать весь файл. Этот вариант также снижает вероятность конфликтов слияния. Согласованность и стандартизация всегда делают автоматизацию и разработку CI/CD Pipeline проще, что делает инженеров почти счастливыми. SOPS предоставляет последовательное расположение кода, настроек и секретов, а это упрощает выполнение рабочих процессов GitOps.
При использовании Hashicorp Vault могут возникнуть проблемы с работой централизованного репозитория секретов, потому что пользователи находят его сложным в использовании, devops-инженеры — тяжелым в обслуживании, а руководство – дорогостоящим. SOPS, с другой стороны, прост в использовании, легко изучаем, дешев в поддержке и поддерживает шаблоны рабочих процессов, что делает жизнь проще! Все это вместе означает – если есть кому предложить эту технологию в вашей организации, серьезных препятствий к принятию не будет, зато скорее всего увеличится общий уровень безопасности. Вот почему SOPS с KMS и Git неоправданно недооценены.
Хотелось бы уточнить – цель этой статьи не в том, чтобы сказать, что Vault плохой и вы должны использовать SOPS и KMS. Я написал эту статью по трем причинам. Первая – просто люблю учить. Вторая – мое желание указать на некоторые недостатки Vault. Третья – KMS вместе с SOPS это прекрасное сочетание, неоправданно недооцененное. Кажется никто и не знает о нем. Я ни разу не сталкивался с нормальным объяснением ни того, ни другого, пока искал информацию к статье. И наконец, согласно Google Trends, существует не так уж много сравнений SOPS и Vault.
Я бы хотел закончить статью, сказав, что искренне рекомендую каждому изучить SOPS, KMS и Vault. Зачем изучать Vault, если он сложнее, а SOPS вместе с KMS делают то же самое? Всего две причины, правда. Первая — Vault один из лучших, когда речь заходит о PKI и смене секретов, что необходимо для правительственных и банковских стандартов соответствия безопасности. Вторая причина – Vault становится проще с каждым годом. Сообщество приняло его как безусловного победителя и добавляет поддержку Vault во многие продукты: Jenkins, cert-manager, и Kubernetes.
Последний, в частности, прекрасно работает с Vault. Значительная часть неприятных моментов была удалена или автоматизирована так, чтобы эти сервисы легко работали друг с другом.
Разработчики Vault показали, что стремятся сделать свой продукт проще в использовании. Они улучшили документацию, предложили Infrastructure as Code (IaC) и реагировали на нужды сообщества. После того, как сообщество создало решения для Auto Unseal, решения для миграции внутреннего хранилища и сторонние веб-интерфейсы, разработчики Vault решили встроить эти функции в Open Source версию. Учитывая все это, я не удивлюсь, если в будущем Vault’s Transit Secrets Engine (аналог KMS от Vault) будет легко взаимодействовать с Mozilla SOPS.
Частичное шифрование
Частичное шифрование поддерживается для файлов со структурой вида key/value:
yaml и json-файлы, содержащие в top-level словарь (например, secret: hide )
При частичном шифровании в файле остаются незашифрованными ключи (имена), т.е. mysecret: hide превращается в mysecret: "ENC[AES256_GCM,data. (далее неразборчиво).
Глядя в pull request вы видите какие секреты были поменяны в файле, но не видите на какие значения. С небольшой инструментацией git diff начинает показывать diff в plain-text (если у вас есть ключ для расшифровки), то есть вы видите, что, например mysecret: hide поменялся на mysecret: HIDE .
Для остальных файлов доступно полнофайловое шифрование.
При шифровании (или выполнении rekeying) sops читает свой конфигурационный файл (в текущем каталоге или в каталогах выше, .sops.yaml ), берёт оттуда все требуемые публичные ключи и шифрует данные каждым из них. Если конфига нет, sops можно вызывать с переменными среды окружения, с параметрами командной строки; хотя моё наблюдение, что конфиг - самая удобная опция.
При шифровании в файл дописывается довольно большая простыня служебных данных sops, которая должна защитить целостность файла (не дать возможности заменить один секрет на старый, а оставшиеся оставить новыми), плюс предоставить достаточно информации о том, что это и чем оно шифровано при просмотре файла "глазами" (без расшифровки).
Helm-secrets и sops
Для меня целевым инструментом является helm и его плагин helm-secrets. Репо проекта.
Обычно он используется как обертка для sops, но это только видимая часть айсберга.
При использовании helm-secrets мы получаем дополнительные фичи:
In-place шифрование секрета helm secrets enc secrets.dev.yaml;
Просмотр helm secrets view secrets.dev.yaml;
Редактирование helm secrets edit secrets.dev.yaml откроет расшифрованный файл в $EDITOR (у vscode есть плагин, который автоматически шифрует и расшифровывает секреты при редактировании);
Автоматический рендер переменных при разворачивании чарта helm secrets upgrade --install -f values.yaml -f secrets.dev.yaml project;
Возможность интеграции с различными системами хранения секретов (об этом чуть позже).
А вот расшифровка in-place подкачала – helm secrets dec secrets.dev.yaml – создаст расшифрованный файл secrets.dev.yaml.dec, а исходный останется без изменений.
Helm-secrets и envsubst
Частая задача – отрендерить переменные в каком-либо файле соответствующими переменными в ENV. В этом поможет замечательная утилита envsubst, которая принимает входящий поток и заменяет в нем переменные на значения из ENV. Как обычно это делают при деплое:
Тоже самое можно реализовать in-place при помощи helm-secrets с драйвером envsubst:
Обратите внимание, в первом случае просто helm так как мы на вход подаём уже отрендеренный конфиг, а во втором - helm secrets ибо требуется извлечение секретов.
Файл secrets.dev.yaml в данном случае выглядит приблизительно так:
Драйвер – это обертка на bash, он позволяет подключать любые системы хранения секретов.
У драйверов для helm-secrets есть один недостаток – нельзя использовать несколько драйверов одновременно.
Таким образом мы подходим к гвоздю программы – vals. Он позволяет из одного манифеста ссылаться на различные источники секретов: sops, vault, aws, gcp. Также его можно использовать как драйвер для helm secrets.
Принцип работы – в файл вставляются ссылки вида:
Но есть и особенности:
Для рендера всего чарта используйте helm secrets -d vals -f values.yaml template . Если не укажете -f values.yaml – вместо значений увидите свои ссылки.
Для просмотра секретов в конкретном файле используйте helm secrets -d vals view values.yaml - . Работает команда странно: сортирует все ключи по алфавиту. Кажется, что она выводит не весь файл. На родной интеграции helm + vault (не через vals) у меня так и не заработал рендер этой командой.
Использование vals вне helm выглядит следующим образом: vals eval -f values.yaml . Файл с подставленными переменными будет выведен в консоль.
Vals разделяет понятие переменных и секретов: для секретов можно использовать дополнительную маркировку secretref+драйвер , тогда команда vals eval --exclude-secret -f values.yaml отрендерит только ссылки, начинающиеся с ref+ , а secretref+ останутся в виде переменных. Этот функционал можно использовать, чтобы увидеть, как в итоге собрался файл конфигурации, не показывая при этом секреты всем.
Создание секрета
Есть два основных режима создания секрета: шифрование нового файла и добавление в существующий файл. Есть ещё третий режим — "создание нового файла с секретами", но он образуется сам собой при попытке редактирования несуществующего файла.
При редактировании (или создании с нуля) шифрованного файла sops запускается с именем файла без остальных параметров (например, sops foobar.sops.yaml ). Если у файла уже есть содержимое, оно расшифровывается (или нет, в зависимости от наличия приватного ключа) и показывается в редакторе. После сохранения и выхода из редактора файл шифруется обратно; причём шифруется всеми публичными ключами согласно конфига или командной строки. Если при открытии файла нет, в редактор загружается пример возможных данных с указанием того, что будет шифровано, а что нет.
Комментарии шифруются; и хоть это вызывает раздражение у многих, у этого есть существенная причина - если вы закомментировали секрет (в режиме редактирования секретов), то вы точно не хотите этот "комментарий" в гите. В этом месте безопасность поставлена выше удобства.
При шифровании существующего файла (например, приватного ключа от сертификата) указывается опция -e для шифрования в stdout, или -e -i для перезаписи файла шифрованной версией.
Аудит
Поддержка аудита есть. Sops может сообщать о всех случаях доступа к секретам. /etc/sops/audit.yaml , хотя я эту функцию не пробовал.
Заключение
Рассмотренные инструменты – это проекты c открытым исходным кодом, написанные на golang и вы можете добавить свой функционал по необходимости.
Для внедрения sops не требуется каких-либо сторонних инфраструктурных решений и специалистов, вы можете сделать это уже сегодня.
Использование комбинаций helm/sops/vals позволяют соблюсти требования безопасности на старте проекта и плавно переехать на целевую инфраструктуру по мере ее готовности.
Пожалуйста, поделитесь в комментариях своими советами и приемами по работе с секретами!
Когда я начал работу с Kubernetes, и Infrastructure as Code (IaC), я быстро понял, что мне нужно решение для работы с секретами. Когда я поискал в интернете, то не увидел единого мнения по поводу практического подхода к проблеме, подходящего ко всем ситуациям. Поэтому, в этом году, я поставил себе задачу изучить, какие решения для управления секретами приложения и инфраструктуры существуют, решить, которое из них я считаю лучшим и освоить его. В конце исследования, я пришел к выводу, что HashiCorp Vault перехвален, а Mozilla SOPS с KMS и Git неоправданно недооценены.
Я считаю, что SOPS недооценен по двум главным причинам.
- Большинство людей не имеет базы знаний достаточной, чтобы понимать, что и как делает Cloud KMS.
- Те же самые люди не осознают, что хотя в прошлом не было безопасного способа хранить зашифрованные секреты в Git, криптография сильно развилась с тех пор, и теперь надежное хранение секретов в Git стало возможно. За это спасибо Cloud Provider KMS Solutions, таким как AWS KMS, Azure KeyVault, или GCP KMS.
Популярность Vault обеспечена в основном тем, что до него десятилетиями не было хорошего решения для управления секретами. И вот на сцену выходит Vault от создателей Terraform, со встроенным изменением секретов, активной поддержкой разработчиков, прекрасной документацией, тех.поддержкой и сообществом. Vault был единственным* решением, которое соответствовало всем моим требованиям для идеального сервиса управления секретами. Я сказал, что Vault переоценен, так как часто вижу, что его рекомендуют как золотой стандарт, панацею, которая должна быть добавлена во все сценарии управления секретами.
Применение на сервере
В силу поддержки нескольких ключей для расшифрования секретов и поддержки KMS крупных облачных провайдеров, в sops есть возможность изолировать файловую систему сервера от секретов, сохраняя при этом удобство разработки и отладки.
Идея проста: один из ключей при шифровании файла секретов — KMS. Люди используют GPG, а сервер, в момент запуска приложения, использует sops и KMS для расшифровки значений на лету и передачи их в приложение. В таком режиме доступ к секретам имеют те, кому положено, и сервер только если он запущен где положено. Если кто-то утащит бэкап или запустит сервер вне ожидаемого места, то вместо секрета он получит либо ошибку запуска, либо (если будет сильно стараться) ENC[AES256_GCMinyourface .
Getting started
Одной из проблем с внедрением системам управления секретами является боль при отладке этого процесса. Пройдя этот процесс, могу дать несколько советов:
Отлаживайте процесс установки sops отдельно от всего. Это вполне себе задача (например, есть отдельный GH Action для установки mdgreenwald/mozilla-sops-action@v1.1.0 ). Её можно реализовывать без привлечения секретов, т.е. комфортно.
Разберитесь с мастер-ключами. Если это pgp, вам нужно "прикрутить" появление ключа в keyring'е в процессе (для GH Actions есть crazy-max/ghaction-import-gpg@v4 ). Так же вам нужно синхронизироваться со всеми участниками команды — все должны завести себе gpg-ключи и иметь ключи коллег в keyring'е. Возня с KMS доставит вам отдельный класс развлечений вне контекста SOPS.
Напишите .sops.yaml . Сам файл тривиальный, но он содержит в себе полиси: чьи ключи какие файлы должны шифровать.
Начните с одного маленького секрета. Я выбрал секрет для запуска стейджинга. Вероятнее всего, в процессе вам придётся преодолеть борьбу с пробелами, переводами строк и ещё чем-то невидимым.
Настройте git diff, плагины для редактора и т.д.
Только после получения look-n-feel от первого внедрения, начинайте трогать что-то большее. Возможно, стоит делать это в режиме "один секрет" (или файл секретов) за раз.
Концентрируйте секреты в одном/двух каталогах. Не стоит разбрасывать шифрованные файлы по всей файловой системе репозитория. В частности, для шифрованных блобов/сертификатов без права смены локации можно использовать симлинки.
Применение в CI
Точнее, в Github Actions, как примере для других CI'ев. При запуске workflow мы всё-таки должны иметь один секрет из самого github'а — ключ для расшифровки, но все последующие мы можем либо добавить в перменную окружения:
Первая строчка маскирует все секреты, вторая добавляет их в окружение всех последующих job.
Запуск с расшифрованным файлом секретов виден в первой строчке, где файл (точнее, именованный FIFO) передаётся как аргумент в командой строке в форме <> .Проблемы безопасности с хранением секретов в репозитории git
- Множество инструментов хранят ключи дешифровки в корневом каталоге пользователя или связке ключей, таким образом данные и ключ от них лежат на одной и той же машине.
- В таком случае раскрытие ключей дешифровки это статистическая неизбежность (уязвимости накапливаются с каждым копированием репозитория в геометрической прогрессии).
- Невозможно аннулировать уже утекший в сеть ключ дешифровки. Если вы беспокоитесь, что ваши ключи будут раскрыты, но шанс этого невелик, аннулировать ключи невозможно из-за распределенной истории git. Даже если вы сможете очистить историю git сервера и заново зашифровать все секреты с новыми ключами шифрования, все равно будет копия репозитория в истории, которую можно дешифровать со старым ключом.
- При подозрении на утечку ключей, единственная контрмера это полное изменение всех учетных данных. Это дорогостоящая операция и руководство обычно не позволяет делать так без соответствующих доказательств утечки.
- Некоторые из инструментов шифровки git сами себя раскрывают: запускают команду расшифровки секрета и забывают зашифровать обратно перед загрузкой в репозиторий.
Я заметил, что решения по управлению секретами можно отнести к одной из четырех категорий:
- Специфичные для облачных провайдеров (я сразу отметаю такие по причинам 1 и 3).
- Специфичные для одного технологического стека (Ansible, Chef, Puppet, Salt, Jenkins) (отметаю по причинам 2 и 5).
- Репозиторий Git, зашифрованный целиком (отметаю по причинам 4 и 5).
- Свой собственный сервис управления секретами (Есть несколько потенциально возможных вариантов, но каждый со своими сложностями, поэтому я решил сосредоточиться на одном. Vault от Hashicorp – абсолютный победитель с учетом количества его возможностей, документации, большого сообщества и истории долгой тех.поддержки и разработки).
Когда анализ был завершен, я потратил месяц свободного времени на работу с Vault Server по хранению статичных секретов, чтобы лучше освоиться с Vault. Хотел, чтобы все получилось безопасным, легким в обслуживании и простым в использовании. Я сделал все что мог: включил в проект TLS, добавил Vault Configuration, роли, политики, и Kubernetes IaC для высокодоступного кластера Vault/Consul в репозитории git, использовал Auto Unseal KMS, написал хорошую документацию, подключил хранилище ключей по версиям, аутентификацию LDAP, веб-интерфейс, и сторонний интерфейс для ПК — Cryptr от Adobe.
Пока изучал Vault, я заметил несколько его недостатков:
Учитывая эти недостатки, я решил копнуть глубже и дальнейшие исследования привели к Soluto’s Kamus. В нем два интересных концепта: GitOps и шифрование секретов нулевого доверия. Я запрыгнул в кроличью нору шифрования и в конце данного путешествия у меня в мыслях получилась следующая схема:
Работа с программой Scania SOPS Encrypt / Decrypt:
- Скачиваем сканером файл конфигураций из автомобиля в формате SOPS;
- Открываем скаченный файл с помощью программы;
- Расшифровываем программой файл кнопкой "Encrypt" и сохраняем в формат XML;
- Открываем для редактирования XML-файл в любом подручном редакторе ( подойдет обычный Excel);
- Ищем в файле нужные параметры, такие как: NOx Control, AdBlue и т. д. для отключения или включения в зависимости от надобности;
- Сохраняем измененный XML-файл и снова открываем в программе SOPS;
- Зашифровываем программой файл кнопкой "Decrypt" и сохраняем в формат SOPS;
- Заливаем полученный файл обратно в автомобиль.
Рассмотрим работу с программой в картинках, на примере:
Информация
Посетители, находящиеся в группе Гости, не могут оставлять комментарии к данной публикации.Задача управления секретами одна из самых неприятных в IT. Само существование секретов уже неприятно, потому надо специально прикладывать усилия, чтобы у кого-то не работало (например, чтобы анонимный пользователь не мог прочитать секрет).
Когда кто-то прикладывает осмысленные усилия, появляются баги. А баги с секретами особо плохие, потому что это секреты, и смотреть на вывод нельзя. Всё равно, что USB-A втыкать вслепую, только возможных неправильных позиций больше.
В индустрии, по мере наработки практик, появилось множество систем управления секретами: с собственными серверами (hashicorp vault), 'as a service' (их ещё называют KMS, key management system), аппаратные (токены и TPM), самописные скрипты на gpg и т.д.
Среди всего этого множества я хочу выделить Mozilla Sops, и, как мне кажется, это один из лучших инструментов. Предупреждая возражения: я говорю про инструмент, а не решение. SOPS не заменяет KMS и не претендует на отмену Hashicorp'ового vault'а.
На Хабре уже был перевод про sops с точки зрения IT-директора, весьма убедительная статья, после которой я и занялся sops всерьёз. Если вы ту статью не читали, очень рекомендую начать с неё, чтобы получить заряд мотивации.
В этой статье я расскажу про техническую часть.
Mozilla sops
Позволяет шифровать yaml/json на gpg-ключах. Репозиторий проекта тут.
Обратите внимание, у вас должна быть версия не ниже 3.7.1. В противном случае могут появляться различные мистические ошибки, которые лечатся обновлением версии.
Для того, чтобы воспользоваться инструментом, необходимо сгенерировать ключи:
Список всех ключей можно просмотреть командой gpg --list-keys
У меня в системе 2 ключа так как мы будем имитировать dev- и prod-окружение, шифруемое на разных ключах. Создадим два файла с секретами, которые будем шифровать.
Создадим файл .sops.yaml , в котором пропишем маску имени файла и отпечаток ключа, который будет к нему применяться.
Зашифруем секрет: sops -e secrets.dev.yaml > enc.secrets.dev.yaml
Команда sops -d enc.secrets.dev.yaml выведет нам в консоль расшифрованный файл:
Аналогичные манипуляции можно проделать для второго файла. Для in-place редактирования используейте sops -i . Инструмент простой, не требует дополнительных инфраструктурных решений и позволяет быстро внедрить шифрованные секреты в проект.
Из минусов: для редактирования секретов придется носить с собой ключи. Ниже приведем пример экспорта/импорта ключа:
Заключение
Sops выглядит как добротная unix-утилита. Она делает что нужно, как нужно, и очень хорошо. У неё минимальное количество полиси и максимальное количество пользы.
Практика показывает, что далеко не все инженеры знают о том, как шифровать секреты в своих репозиториях. Поэтому расскажу об инструментах helm-secrets, sops и vals, которые помогают быстро и просто решить эту задачу. Надеюсь, что после выхода моей статьи закоммиченных паролей в репах станет меньше :).
О каких инструментах я расскажу:
Mozilla sops для шифрования yaml/json (без helm)
Helm-secrets и sops
Helm-secrets и
философский каменьenvsubstЧитайте также:
- При реагировании на известное нарушение:
- Изобретение принципа шифрования KMS ввело три убойные возможности: