Регистрация Войти
Рейтинг:1
viniciuskneves avatar Server

Безопасное хранение пользовательских ключей AWS IAM (доступа и секрета), созданных IaC

флаг de
viniciuskneves

У меня следующая установка:

  1. Инфраструктура настраивается с помощью AWS CDK;
  2. У меня есть один стек/среда (производство, постановка...);
  3. У каждого стека есть отдельный сегмент S3 (используемый для хостинга веб-сайтов);
  4. У меня есть стек, который создает пользователя IAM (используется CI/CD);
  5. CI/CD в данном случае — это GitHub Actions (развертывание каждый раз при слиянии с главный бывает);
  6. Пользователь IAM имеет только права на размещение всех сегментов (развернуть означает поместить активы в сегмент);

Каков наилучший способ хранения/обработки ключей для этого пользователя?

Я начал печатать его в выходных данных, но это небезопасно. Его могут видеть все (например, если у них есть доступ к логам CI/CD).

Мне предложили хранить их в SSM: это работает, но вы не можете создать его как SecureString, поэтому это будет просто строка.

Я также заглянул в Secrets Manager: он также работает и кажется более безопасным (хотя не уверен, что мое мнение здесь справедливо).

Любые идеи/мнения здесь?

Спасибо!

В коде это выглядит примерно так:

// Производственный стек
константное ведро = новое ведро (это, "Ведро", {
  ведроНазвание: "производство",
});

// Промежуточный стек
константное ведро = новое ведро (это, "Ведро", {
  BucketName: "постановка",
});

// IAM-стек
const user = новый пользователь (это, "Пользователь", {
  имя пользователя: "ci-cd-пользователь",
});
const userAccessKey = новый AccessKey (это, "UserAccessKey", {пользователь});

// Это просто пример, я просматриваю все доступные Buckets
BucketProduction.grantPut(пользователь);
ведроStaging.grantPut(пользователь);
61
0 + 0
Tim avatar
флаг gp
Tim
Какой инструмент CI/CD вы используете? Это в АВС? Пожалуйста, обновите свой вопрос более подробно, а затем ответьте здесь, чтобы я мог видеть, что он был обновлен. Ответ зависит от этой информации.
0
Ответить
viniciuskneves avatar
флаг de
viniciuskneves
Привет, @Tim, я только что добавил дополнительную информацию: CI/CD — это действия GitHub, а развертывание означает размещение ресурсов в Buckets. Помогает или нужны подробности?
0
Ответить
Tim avatar
флаг gp
Tim
Лично я бы создал пользователя IAM или, по крайней мере, его ключ доступа вручную, а затем передал бы учетные данные туда, где они нужны, в Github, а не хранил бы их в AWS. Если вы должны хранить их внутри AWS, тогда я выберу хранилище параметров или диспетчер секретов, и то, и другое подходит, если они зашифрованы. Я бы, вероятно, ограничил, кто может просматривать учетные данные, где бы вы ни решили их хранить.
0
Ответить
viniciuskneves avatar
флаг de
viniciuskneves
Хммм.. Понял. Я пытался максимально автоматизировать процесс, но действительно имеет смысл ручное управление ключами. Будут ли роли через федерацию лучшим решением? Что я имею в виду: https://docs.github.com/en/actions/deployment/security-hardening-your-deployments/configuring-openid-connect-in-amazon-web-services
0
Ответить
Tim avatar
флаг gp
Tim
Роли почти всегда лучше, чем учетные данные IAM.Я ничего не знаю о действиях github, но если он может взять на себя роль, выберите этот вариант. Просто убедитесь, что роль правильно защищена, чтобы только действия github могли взять на себя эту роль.
0
Ответить
viniciuskneves avatar
флаг de
viniciuskneves
Спасибо! Я добавлю его в качестве ответа здесь, как только смогу правильно попробовать его с ролями.
0
Ответить
флаг cn
shearn89
Похоже, чтобы заставить его принять на себя роль, которую вы просто указываете без учетных данных, и он использует OIDC, поэтому он должен быть намного более безопасным. https://github.com/aws-actions/configure-aws-credentials
0
Ответить
viniciuskneves avatar
флаг de
viniciuskneves
Да, @ shearn89, я попробовал это вчера, и это работает как шарм. Я не был полностью осведомлен об этом или о том, как это работает ... Я подытожу свои выводы в ответе. Спасибо, что указали на это âï¸
1
Ответить
Рейтинг:0
viniciuskneves avatar Server
флаг de
viniciuskneves

Это заняло у меня некоторое время, но я, наконец, обобщил свои мысли здесь: https://dev.to/viniciuskneves/use-aws-through-github-actions-without-secret-keys-32eo

Идея состоит в том, чтобы использовать Подключиться к OpenID к связаться с GitHub а затем иметь роль, которую может взять на себя GitHub Actions, и выполнять развертывание (те же политики, которые я бы дал пользователю GitHub Actions).

При использовании AWS CDK решение выглядит следующим образом:

const provider = новый OpenIdConnectProvider(этот, "GitHubProvider", {
  URL-адрес: «https://token.actions.githubusercontent.com»,
  clientIds: ["sts.amazonaws.com"], // В документации упоминается как "Аудитория"
});
константная роль = новая роль (эта, "Роль", {
  предполагаемый по: новый OpenIdConnectPrincipal (поставщик, {
    StringEquals: {
      "token.actions.githubusercontent.com:aud": "sts.amazonaws.com", // "Аудитория" сверху
    },
    StringLike: {
      "token.actions.githubusercontent.com:sub":
      "repo:<ORGANIZATION>/<REPOSITORY>:*", // Организация и репозиторий, которым разрешено выполнять эту роль
    },
  }),
});

ведро.grantPut(роль); // Создает политику

После этого нам нужно обновить GitHub Actions, чтобы использовать это вместо наших пользовательских ключей:

...
разрешения:
  id-токен: написать
  content: read # Это необходимо для действий/оформления заказа (это упоминается в документации GitHub)
...
- имя: Настройка учетных данных AWS 
  использует: aws-actions/[email protected] # Версия на момент написания этой статьи
  with: # Мы загружаем ключи, хранящиеся в секретах
    role-to-assume: arn:aws:iam::<ACCOUNT>:role/<ROLE-NAME> # Вы можете указать имя роли при ее создании, иначе AWS автоматически сгенерирует его для вас
    aws-регион: eu-central-1
- run: npm run deploy # Просто пример
0 + 0
флаг Moldova
Admin
Этот вопрос на других языках:

Ответить или комментировать

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