#amazon-web-services #continuous-integration #aws-cdk #aws-codepipeline #infrastructure-as-code
#amazon-web-services #непрерывная интеграция #aws-cdk #aws-codepipeline #инфраструктура как код
Вопрос:
Конвейеры CDK отлично подходят, особенно для развертывания с несколькими учетными записями. Это позволяет разработчикам определять и настраивать конвейер CI / CD для своего приложения по своему усмотрению.
Но чтобы оставаться совместимым с SoC, нам нужно убедиться, что необходимые элементы управления, подобные приведенным ниже, проверены / применены
- Этап утверждения вручную должен присутствовать перед этапом, на котором выполняется развертывание между учетными записями в производство
- Прямое развертывание в рабочей среде в обход среды разработки / промежуточной среды не допускается
- Перед развертыванием должны быть пройдены тестовые примеры (модульные тесты / интеграционные тесты) и тесты InfoSec
Я знаю, что вышеуказанные вещи легко реализовать в конвейерах CDK, но я не совсем уверен в том, как гарантировать, что каждый конвейер CDK всегда соответствует этим стандартам.
Я могу придумать следующие решения
- Ограничения ветвей — Слияние с главной веткой (которую отслеживает конвейер CDK) должно быть ограничено и разрешено только с помощью запросов на извлечение
- Тесты — добавьте модульные тесты или интеграционные тесты, которые подтверждают, что созданный шаблон формирования облака имеет определенные ресурсы / свойства
- Создайте стандартный производственный этап со всеми необходимыми элементами управления и оберните его в библиотеку, которую разработчики должны использовать при определении конвейера CDK, если они хотят развернуть в производство
Но как обеспечить соблюдение вышеуказанных элементов управления в автоматическом режиме? Разработчики могут обойти вышеуказанные элементы управления, просто не указав их при определении конвейера. И мы не хотим полагаться на утверждающего, чтобы проверять эти вещи вручную.
Итак, вкратце, вопрос заключается в следующем: как при использовании конвейеров CDK предоставить разработчикам максимальную настраиваемость и свободу при разработке их решения CI / CD, гарантируя при этом, что ограничения SoC и обязательные элементы управления проверяются и применяются автоматически?
Комментарии:
1. Вы можете не предоставлять им разрешения IAM на развертывание стеков и самостоятельно развертывать стек конвейера (с помощью любого автоматизированного процесса), только если он правильно использует вашу библиотеку.
2. @kichik Это сведет на нет всю цель использования конвейеров CDK — мы хотим, чтобы разработчики могли указывать конвейер в соответствии со своими требованиями — при условии, что он соответствует установленным стандартам, например, развертывание в учетной записи prod должно быть одобрено вручную.
3. FTR — github.com/aws/aws-cdk-rfcs/blob/master/text /… документирует проектирование трубопроводов CDK
4. Они все еще не могут спроектировать конвейер. Они просто не могут развернуть его напрямую, не пройдя сначала ваши тесты.
Ответ №1:
Open Policy Agent может быть полезен для проверки infra на соответствие пользовательским политикам в конвейере.
Комментарии:
1. Спасибо, Сухайб. Это очень полезно. Этап проверки, который выполняет проверки с использованием Open Policy Agent, был бы одним из потенциальных способов решения указанной проблемы. Но, к сожалению, это также будет страдать от той же проблемы — как обеспечить, чтобы разработчики всегда добавляли этот этап при создании своего конвейера CI / CD с использованием CDK?
2. Существует 2 способа: Процесс 1. разрешить только утвержденные пользовательские модули NPM / PIP, созданные с помощью AWS CDK. В конвейере для развертывания этих модулей в Artifactory (частный репозиторий) вы можете обеспечить соблюдение требований безопасности с помощью OPA. Таким образом, вы можете создать целую библиотеку шаблонов сверхурочно. Процесс 2. разрешите разработчикам использовать общедоступные модули AWS CDK и на этапе развертывания запустите ‘cdk synth> templete. yml’ перед запуском ‘cdk deploy’. Это позволяет запускать классические инструменты компоновки cloudformation, такие как cfn-lint, на этой облачной платформе, созданной aws cdk. Пользовательские правила безопасности можно настроить в cfn-lint.
3. Я согласен, что процесс-1 является одним из вариантов. Но я не уверен, что полностью понимаю процесс-2. Как я могу гарантировать, что разработчики настроят этап развертывания на запуск
cdk synth > template.yml, а затем запустят cfn-lint?4. Вы создаете конвейер таким образом, что этап развертывания управляется инженерами, а не разработчиками. Фактически вы можете разбить этап развертывания на 2 (этап безопасности и этап развертывания). Оба эти этапа поддерживаются инженерами. Разработчики должны управлять только этапом сборки, на котором модули npm / pip извлекаются из Artifactory (репозиторий частного пакета) и выполняются этапы сборки. Роль IAM на этапе сборки не должна иметь доступа к развертыванию. Если вы используете Codepipeline, где каждый этап представляет собой отдельную сборку кода. Спецификация для этапа сборки передается разработчиком в коде. Остальная часть buildspec управляется инженерами.
5. Спасибо за предложение @Suhaib. Здесь хочу отметить, что мы очень маленькая команда без какого-либо четкого различия между Dev / Eng, и я думаю, именно поэтому нам нравятся конвейеры CDK — позволяет легко указать конвейер с минимальными усилиями. Похоже, что предлагаемый вами подход лишит конвейера простоты, от которой мы в настоящее время многое выигрываем и не уверены, хотим ли мы отказаться. В настоящее время я думаю о том, чтобы иметь какой-то крюк . который выполняет проверку и блокирует развертывание.
Ответ №2:
После долгих исследований я пришел к выводу, что наилучшим подходом является реализация этих проверок с помощью настраиваемого правила конфигурации AWS.
Допустим, мы хотим убедиться, что
Этап утверждения вручную всегда присутствует в каждом конвейере, который имеет этап развертывания для prod.
Нам необходимо
- Включите AWS Config и настройте его для записи всех изменений в Codepipeline
- Создайте пользовательское правило конфигурации AWS с помощью функции AWS Lambda (скажем, pipeline-compliance-checker).
- Функция lambda запускается при каждом изменении конфигурации любого кодового конвейера и получает последнюю конфигурацию рассматриваемого конвейера
- Он анализирует последнюю конфигурацию конвейера и проверяет, есть ли в конвейере этап утверждения вручную перед этапом развертывания в prod. Если да, он считает конвейер СОВМЕСТИМЫМ, иначе NON_COMPLIANT
- Создайте правило AWS EventBridge для получения уведомления в теме SNS (скажем, конвейер-несоответствие), когда какой-либо конвейер помечен как НЕСООТВЕТСТВУЮЩИЙ — (документ)
- Создайте другую функцию AWS Lambda (скажем, pipeline-compliance-enforcer), которая подписана на этот раздел SNS. Он останавливает соответствующий несоответствующий конвейер (если он находится в ЗАПУЩЕННОМ состоянии), а затем отключает входящий переход на этап, который развертывается в prod. Мы также можем удалить конвейер здесь, если требуется.
Протестировали вышеуказанную настройку, и она соответствует требованиям.
Позже также стало известно, что AWS рассказывает о том же решении этой проблемы в этом докладе — Безопасность конвейера CI / CD: передовые рекомендации по непрерывной доставке