Разрешения IAM для конвейера CI / CD - PullRequest
Новая
       2

Разрешения IAM для конвейера CI / CD

2 голосов
/ 17 июня 2020

Я хочу настроить свои конвейеры развертывания так, чтобы они придерживались принципа наименьших привилегий при развертывании ресурсов в AWS. Это означает, что я не хочу предоставлять административный доступ к политике развертывания или привилегии "*: *".

Проблема в том, что каждый раз, когда я создаю новый конвейер, мне приходится go методом проб и ошибок процесс:

  • Развертывание
  • Ошибка из-за отсутствия разрешений IAM
  • Обновите политику IAM, чтобы добавить недостающее разрешение
  • Повторить

Я искал ресурсы, чтобы помочь с этим, но общий подход, кажется, сводится к избыточному предоставлению политике IAM, что я считаю очень плохим подходом.

Существуют ли какие-либо инструменты, которые вы можете использовать для анализа шаблона CloudFormation и создания документа JSON с необходимой политикой развертывания? (Или для Serverless Framework или CDK?)

1 Ответ

1 голос
/ 17 июня 2020

Отличный вопрос, к сожалению, ответ немного сложен.

Вы сталкиваетесь с небольшой проблемой курицы и яйца со всеми поставщиками Infrastructure As Code (Serverless, CDK, CloudFormation, Terraform , et c).

Помните, что пользователь IAM, который развертывает ваше приложение, не такой же, как роль IAM вашего приложения (Lambda) запускает под.

Это означает, что если вы хотите строго ограничить разрешения своего пользователя развертывания, чтобы он мог развертывать только указанные c ресурсы, это нормально - однако, как вы отметили, вам нужно будет расширять эти разрешения каждый раз, когда вы хотите развернуть новые ресурсы. Примечательно, что если вы автоматизируете этот процесс таким образом, что разрешения ролей расширяются каждый раз, когда вы добавляете новую инфраструктуру, вы фактически предоставляете своему пользователю развертывания административный доступ.

Вот почему большинство людей используют развернутого пользователя с избыточной подготовкой для развертывания своих приложений. Это не считается плохим подходом по двум причинам:

  1. Ваше приложение не использует эту роль при выполнении, поэтому, если у вас есть серьезная уязвимость в лямбда-выражении, которая допускает удаленное выполнение кода, злоумышленник не сможет ' t поставить под угрозу всю вашу AWS учетную запись
  2. Вы полагаетесь на своего провайдера IA C, чтобы гарантировать, что вы не создадите ненужную инфраструктуру. (IE: вы и ваш провайдер IA C имеете одинаковый уровень доступа)

Пока роль Lambda Execution имеет строгую политику IAM, можно использовать пользователя развертывания с избыточным выделением ресурсов.

...