Ответ 1
К сожалению, это еще не доступно, по крайней мере, не в автоматическом режиме, который вы, вероятно, ищете - ваш прецедент имеет два аспекта:
Разрешения на уровне ресурса
Недавнее введение Разрешения на уровне ресурсов для ресурсов EC2 и RDS, наконец, позволяет ограничить Amazon EC2 Действия API для конкретных экземпляров, что позволяет использовать ваш вариант использования под этим углом, например:
- Разрешить пользователям работать с ограниченным набором ресурсов в более крупной многопользовательской среде EC2.
- [...]
- Управлять тем, какие пользователи могут завершать какие экземпляры.
Пример политики IAM показывает, как Разрешить пользователь выполняет все действия в таблице DynamoDB Amazon, имя которой соответствует имени пользователя, демонстрируя использование переменной политики ${aws:username}
(см. Переменные политики IAM Обзор):
{
"Version": "2012-10-17",
"Statement": [{
"Effect": "Allow",
"Action": ["dynamodb:*"],
"Resource": "arn:aws:dynamodb:us-east-1:123456789012:table/${aws:username}"
}
]
}
Caveat
Эти разрешения на уровне ресурсов еще не доступны для всех действий API:
Это сложная и далеко идущая функция, и мы будем ее развертывать поэтапно. На первом этапе следующие действия по указанному ресурсы теперь поддерживают разрешения на уровне ресурсов:
Instances - Reboot, Start, Stop, Terminate. EBS Volumes - Attach, Delete, Detach.
Действия EC2, не перечисленные выше, не будут регулироваться уровнем ресурсов разрешений в это время. Мы планируем добавить поддержку дополнительных API-интерфейсов в течение всего остального 2013 года.
В частности, ему не хватает действий ec2:Describe*
, которые вы, похоже, ищете, также.
Аудит трейла
Однако AWS еще не публично выпустила какую-либо функцию аудита (которая должна быть доступна из-за способа Amazon IAM работает), что означает, что нет возможности узнать, какой конкретный пользователь IAM создал конкретный ресурс.
Update
Как и ожидалось, AWS тем временем выпустила AWS CloudTrail, который является веб-сервисом, который записывает вызовы API AWS для вашей учетной записи и доставляет файлы журналов вам:
Записанная информация включает идентификатор вызывающего API, время вызова API, исходный IP-адрес вызывающего API-адреса, параметры запроса и элементы ответа, возвращаемые AWS обслуживание.
См. мой ответ на Журналы действий для амазонок s3/других сервисов AWS для нескольких деталей и начальных ограничений.
Частичное обходное решение
Мне не известно о каком-либо автономном обходном пути - в рамках совместной работы вы можете приблизиться к тому, что хотите, применив соответствующий мониторинг и автоматизацию следующим образом:
1) вам нужно указать, что пользователи только запускают экземпляры EC2 с какой-либо схемой мечения, например. owner=<username>
2) с этой схемой, вы можете применить политику на основе ${aws:username}
, как указано выше, соответственно. небольшое изменение на основе тегов - блог безопасности AWS содержит исчерпывающее сообщение Разрешения на уровне ресурсов для EC2 - контроль доступа к управлению на конкретных экземплярах, иллюстрирующий это подход - ваша политика может выглядеть следующим образом:
{
"Version": "2012-10-17",
"Statement": [
{
"Action": [
"ec2:StartInstances",
"ec2:StopInstances",
"ec2:RebootInstances",
"ec2:TerminateInstances"
],
"Condition": {
"StringEquals": {
"ec2:ResourceTag/owner":"${aws:username}"
}
},
"Resource": [
"arn:aws:ec2:your_region:your_account_ID:instance/*"
],
"Effect": "Allow"
}
]
}
3) обратите внимание, что это означает, что пользователь не сможет управлять своими экземплярами, если он забудет запустить их с правильным тегом, поэтому кроме того вы могли бы использовать что-то вроде Netflix ' "Согласие обезьяны" , чтобы обеспечить соблюдение политики на основе эвристики, т.е. как только экземпляр будет обнаружен без необходимого тега, тот, кто отвечает за него, получает уведомление и может попытаться обеспечить его соблюдение путем запроса пользователей или закрытие экземпляра (что также может быть сделано автоматически, конечно).