AWS cross-account access – пояснения к статье

Если вам надо выдать доступ к ресурсам аккаунта AWS, вы можете это сделать с помощью создания отдельной учетки. Но в таком случае будут выданы статичные логин и пароль, которые по-хорошему надо будет иногда менять, а также заботиться о их сохранности. Гораздо более безопасный вариант – создание отдельной роли в целевом аккаунте и выдача разрешения AssumRole для роли из другого аккаунта (cross-account access). Технически это более запутанная операция, а потому требует пояснений, в том числе когда речь заходит об официальных статьях.

AWS cross-account access

Сегодня хочу рассказать о небольшом опыте, который получил, когда возился с предоставлением cross-account доступа по статье Enabling cross-account access to Amazon EKS cluster resources.

Задача

Имеется EKS-кластер – source account – с развернутым в нем cloudwatch_exporter. Требуется делегировать экспортеру доступ на чтение метрик CloudWatch в другом аккаунте – target account. Для наглядности предположим следующее:

source account id: 111111111111
target account id: 222222222222

Пояснения

В пункте №3 инструкции после политики AssumeRole сразу ниже найдете приписку:

Once the role is created, attach the IAM policy that you want to associate with the serviceaccount

В этой IAM policy должны предоставляться права из source account (политику надо создавать именно в нем) до роли в target account. Сама политика при этом в terraform может выглядеть так (пример также доступен в пункте 3 в статье):

Все в том же пункте 3 статьи заметка:

Note that if you haven’t created the target account IAM role, please proceed to step 4 and complete configuring the target AWS account and then finish associating this policy.

Но она бесполезна, потому что создать в целевом аккаунте роль AWS вам не позволит. А все потому, что в этой роли придется прописывать Assume policy, в которой должен быть в явном виде указан принципал безопасности и AWS проверяет факт его существования. В нашем случае им является имя роли (AllowCWAccessToTargetAccount) в source account.

А вот создать роль в source account с указанием фейкового ресурса вполне себе получится. Поэтому смело игнорируем заметки в пункте 3 и спокойно его выполняем полностью. В крайнем случае потом измените имя ресурса дополнительным коммитом в свой репозиторий. Либо вообще пока не создавайте политику, докиньте её позже.

Примечание: строго говоря, в политике выше вы можете и не указывать конкретный arn. Можно указать wildcard – * – и пусть роль позволяет ассюмить любой ресурс, для которого у неё будут разрешения. Напомню, что разрешения эти должны выдать на противоположной стороне, то есть сами из ниоткуда они не появятся, а значит и угроз безопасности нет.

Итак, пункт 3 вы выполнили и теперь у вас есть роль с arn arn:aws:iam::111111111111:role/AllowCWAccessToTargetAccount. Самое время переходить к пункту 4, в котором нужно проделать следующее. Внутри target account создаем политику с разрешениями для R/O доступа до CloudWatch. Далее создаем роль и в Assume policy у нее вписываем arn роли из source account (см. выше arn). Разумеется после этого подключаем политику к роли. Вот так это может выглядеть в terraform:

На всякий случай делаем output с arn роли, чтобы подправить её в source account:

Применяйте изменения.

Если вы не стали создавать политику в source account или засунули в неё фейковый ресурс, то самое время сейчас это исправить, потому что arn этой роли вы получили на предыдущем пункте.

Сама же конфигурация cloudwatch_exporter может выглядеть так:

Обратите внимание на role_arn – берется arn именно той роли, которая находится в целевом аккаунте (target account). Это становится возможно, потому что операцию assume role под выполняет с правами назначенной ему роли в исходном аккаунте (source account). Ну а между ролями существуют доверительные отношения. Вот и вся магия

Яндекс.Метрика