Защита секретов в Azure Pipelines
Azure DevOps Services | Azure DevOps Server 2022 | Azure DevOps Server 2020
В этой статье приведены рекомендации по защите секретов в Azure Pipelines. Секрет — это то, к чему необходимо строго контролировать доступ, например ключи API, пароли или криптографические ключи.
Azure Pipelines не создает значения секретов. Однако может потребоваться добавить секрет в конвейер для хранения конфиденциальных данных, таких как ключ API. Дополнительные сведения об определении переменных секретов см. здесь.
Не используйте секреты, если доступен другой метод
Лучший способ защиты секрета — не иметь секрет в первую очередь. Проверьте, может ли конвейер использовать другой метод, отличный от использования секрета для выполнения задачи.
- Использование подключений к службе:
- При выборе azure или других служб используйте подключения служб вместо управления секретами в переменных.
- Подключения служб позволяют безопасно подключаться к внешним службам без предоставления конфиденциальной информации непосредственно в конфигурации конвейера.
- Дополнительные сведения см. в статье "Управление подключениями к службе" и "Подключение к Microsoft Azure" с помощью подключения службы Azure Resource Manager.
Используйте управляемые удостоверения:
- Рассмотрите возможность использования управляемых удостоверений вместо непосредственной обработки секретов.
- Управляемые удостоверения позволяют приложениям и службам проходить проверку подлинности в службах Azure, не требуя явных учетных данных.
- Управляемые удостоверения можно использовать для доступа к другим службам Azure.
Задача Azure CLI:
- Если вы используете задачу Azure CLI, в конвейере рекомендуется использовать
addSpnToEnvironment
параметр для доступа к сведениям субъекта-службы в скрипте без явного передачи секретов.
- Если вы используете задачу Azure CLI, в конвейере рекомендуется использовать
Дополнительные сведения см. в разделе "Использование субъектов-служб" и управляемых удостоверений
Использование секретных переменных
Никогда не сохраняйте конфиденциальные значения в виде открытого текста в файле .yml Azure Pipelines.
Секретные переменные можно использовать для частных данных, таких как пароли, идентификаторы и другие идентифицировать данные, которые не нужны в конвейере. Рекомендуется задать секретные переменные в Azure Key Vault. Вы также можете задать секретные переменные в пользовательском интерфейсе или в группе переменных. Мы не рекомендуем использовать команду ведения журнала для задания секретной переменной. При настройке секрета с помощью команды ведения журнала любой пользователь, который может получить доступ к конвейеру, также может увидеть секрет.
Секретные переменные шифруются и могут использоваться в конвейерах без предоставления их значений. Хотя их значения не предоставляются, никогда не повторяйте секреты в качестве выходных данных и не передают секреты в командной строке. Вместо этого мы рекомендуем сопоставить секреты с переменными среды.
При создании секрета следуйте рекомендациям по именованию переменных и убедитесь, что имя секрета не раскрывает конфиденциальную информацию.
Ограничение доступа к секретным переменным
Чтобы ограничить доступ к секретам в Azure DevOps, выполните следующие рекомендации.
- Храните секреты в Azure Key Vault. С помощью Azure Key Vault можно использовать модель управления доступом на основе ролей Azure, чтобы ограничить доступ к секрету или группе секретов.
- Задайте секретные переменные в пользовательском интерфейсе для конвейера. Секретные переменные, заданные в пользовательском интерфейсе параметров конвейера для конвейера, относятся к конвейеру, в котором они задаются. Таким образом, вы можете иметь секреты, видимые только пользователям с доступом к такому конвейеру.
- Задайте секреты в группе переменных. Группы переменных соответствуют модели безопасности библиотеки. Вы можете контролировать, кто может определять новые элементы в библиотеке и использовать существующий элемент.
Не записывайте секреты в журналы
Azure Pipelines пытается свернуть секреты из журналов, где это возможно, но это не глупо. Избегайте повторения секретов в консоли, используя их в параметрах командной строки или регистрируя их в файлах. Будьте осторожны при использовании команд Azure CLI, которые выводят конфиденциальную информацию. Используйте иNone output format
, если вам нужно получить секрет из вызова Azure CLI. Use none output format and retrieve security information to a secret variable
Не используйте структурированные данные в качестве секретов
Избегайте использования структурированных форматов данных, таких как JSON, XML или YAML, для инкапсулирования секретных значений, включая символы управления, такие как возврат каретки, \r
и канал строк.\n
Вместо этого создайте отдельные секреты для каждого конфиденциального значения. Этот подход обеспечивает более высокую точность редактирования и сокращает риск предоставления конфиденциальных данных непреднамеренно.
Выполняйте аудит обработки секретов
Чтобы проверить, как секреты используются в Azure Pipelines, выполните следующие рекомендации.
- Просмотрите исходный код: изучите исходный код репозитория, на котором размещен конвейер. Чтобы обеспечить правильную обработку секретов, проверьте все задачи, используемые в конвейере. Например, убедитесь, что секреты непреднамеренно отправляются на непреднамеренные узлы или явно печатаются в выходные данные журнала.
- Проверьте журналы выполнения. После тестирования допустимых и недопустимых входных данных просмотрите журналы выполнения для конвейера. Убедитесь, что секреты правильно редактируются и не предоставляются. Иногда ошибки в командах или средствах могут случайно утечки секретов в журналы ошибок. Хотя Azure Pipelines пытается скрутировать секреты из журналов, проверка вручную по-прежнему важна.
Аудит и смена секретов
Чтобы выполнить аудит и смену секретов, выполните следующие рекомендации.
- Просмотрите зарегистрированные секреты: периодически оцените секреты, зарегистрированные в конвейерах. Убедитесь, что они по-прежнему необходимы, и удалите все, что больше не требуется, что помогает уменьшить беспорядок и потенциальные риски безопасности.
- Смена секретов: регулярно поворачивайте секреты, чтобы свести к минимуму период времени, в течение которого скомпрометированный секрет может быть использован. Периодически изменяя секреты, вы повышаете безопасность.
- Выбор правильного метода проверки подлинности
- Типы секретов, используемые:
- Личные маркеры доступа (PATs): эти маркеры используются для проверки подлинности. Следуйте рекомендациям по обеспечению безопасности при выборе правильного метода проверки подлинности. Вы можете управлять PATS с помощью REST API.
- Секретные переменные: используйте секретные переменные для безопасного хранения конфиденциальных данных, таких как ключи API, пароли или другие учетные данные в конвейере.
- Секреты Azure Key Vault. Используйте Azure Key Vault для безопасного хранения секретов и управления ими.
- Подключения к службам: эти подключения службы позволяют конвейеру подключаться к внешним службам (например, Azure, GitHub, Docker Hub). Обеспечьте правильную настройку и безопасную обработку секретов подключения службы.
- Типы секретов, используемые:
Использование шаблонов YAML
Вместо включения встроенных скриптов с параметрами секрета непосредственно в YAML конвейера используйте шаблоны. Этот подход повышает безопасность путем абстрагирования конфиденциальной информации от основного конвейера.
Чтобы реализовать этот подход, создайте отдельный файл YAML для скрипта, а затем сохраните этот скрипт в отдельном безопасном репозитории. Затем вы можете ссылаться на шаблон и передать секретную переменную в YAML в качестве параметра. Безопасная переменная должна поступать из Azure Key Vault, группы переменных или пользовательского интерфейса конвейера. Дополнительные сведения об использовании шаблонов см. в справочнике по использованию шаблона.
Ограничение секретов с помощью политик ветви и разрешений группы переменных
Чтобы убедиться, что секреты привязаны к main
ветви и недоступны для случайных ветвей, можно использовать сочетание разрешений группы переменных, вставки условного задания и политик ветви.
С помощью политик ветвей можно применить политики проверки сборки, которые разрешают сборку только из основной ветви. Затем можно использовать разрешения группы переменных, чтобы убедиться, что только авторизованные конвейеры имеют доступ к секретам, хранящимся в вашей группе переменных. Наконец, можно использовать условие в конвейере, чтобы убедиться, что группа переменных может ссылаться только на отправку в main
ветвь.
jobs:
- job: ExampleJob
condition: and(succeeded(), eq(variables['Build.SourceBranch'], 'refs/heads/main'))
pool:
vmImage: 'ubuntu-latest'
steps:
- script: echo "This runs only for the main branch"
displayName: 'Conditional Step'
variables:
- group: your-variable-group-name