Можно ли создать новую роль в AWS?

Можно ли создать новую роль в AWS? Конечно, можно!

AWS Identity and Access Management (IAM) предоставляет полную возможность создавать, настраивать и управлять пользовательскими ролями. Роли в AWS — это фундаментальный механизм для безопасного делегирования прав и соблюдения принципа наименьших привилегий (Least Privilege Principle).

Ключевые характеристики AWS IAM Role:

• Не имеет постоянных паролей или ключей доступа — это главное отличие от IAM User.
• Временные credentials выдаются через службы STS (Security Token Service).
• Используется для:
  • Назначения прав AWS-сервисам (например, Lambda, EC2).
  • Cross-account access (доступ между аккаунтами AWS).
  • Federation (внешние пользователи из корпоративных AD или через социальные сети).
• Поддерживает политики доверия (Trust Policy) и политики разрешений (Permission Policy).

Как создать роль: практические шаги и примеры

Процесс создания можно выполнить через AWS Console, CLI, Terraform, или напрямую через API.

1. Создание через AWS Console (графический интерфейс)

1. Откройте IAM Console → Roles → Create role.
2. Выберите тип доверия (Trusted entity type):
   • AWS service (например, для Lambda, EC2).
   • Another AWS account.
   • Web identity или SAML 2.0 federation.
3. Настройте Permissions policies (например, AmazonS3ReadOnlyAccess).
4. Добавьте Tags (опционально).
5. Введите Role name и Description.
6. Нажмите Create role.

2. Создание через AWS CLI (Command Line Interface)

Пример создания роли для AWS Lambda, позволяющей читать из S3 и писать в CloudWatch Logs:

# Сначала создаём файл с политикой доверия (trust policy)
cat > trust-policy.json <<EOF
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "lambda.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}
EOF

# Создаём роль с этой политикой доверия
aws iam create-role \
  --role-name MyLambdaExecutionRole \
  --assume-role-policy-document file://trust-policy.json \
  --description "Role for Lambda to access S3 and logs"

После создания роли, необходимо добавить политики разрешений:

# Прикрепляем managed policy для базовых прав Lambda
aws iam attach-role-policy \
  --role-name MyLambdaExecutionRole \
  --policy-arn arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole

# Прикрепляем custom policy для S3 (пример custom-политики в отдельном файле)
aws iam put-role-policy \
  --role-name MyLambdaExecutionRole \
  --policy-name MyS3ReadAccess \
  --policy-document file://s3-read-policy.json

3. Создание через Terraform (Infrastructure as Code)

Для автоматизации и управления состоянием инфраструктуры:

resource "aws_iam_role" "lambda_execution_role" {
  name = "terraform-lambda-execution-role"
  description = "IAM role for Lambda function"
  assume_role_policy = jsonencode({
    Version = "2012-10-17"
    Statement = [
      {
        Action = "sts:AssumeRole"
        Effect = "Allow"
        Principal = {
          Service = "lambda.amazonaws.com"
        }
      }
    ]
  })
}

resource "aws_iam_role_policy_attachment" "lambda_basic_execution" {
  role       = aws_iam_role.lambda_execution_role.name
  policy_arn = "arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole"
}

resource "aws_iam_policy" "custom_s3_policy" {
  name        = "terraform-s3-read-policy"
  description = "Custom policy for S3 read access"
  policy = jsonencode({
    Version = "2012-10-17"
    Statement = [
      {
        Action   = ["s3:GetObject", "s3:ListBucket"]
        Effect   = "Allow"
        Resource = ["arn:aws:s3:::my-data-bucket", "arn:aws:s3:::my-data-bucket/*"]
      }
    ]
  })
}

resource "aws_iam_role_policy_attachment" "custom_s3_attach" {
  role       = aws_iam_role.lambda_execution_role.name
  policy_arn = aws_iam_policy.custom_s3_policy.arn
}

Важные best practices при создании ролей:

• Следуйте принципу наименьших привилегий: выдавайте только необходимые для задачи права.
• Используйте описательные названия: EC2-SSM-Management-Role, CrossAccount-CICD-Deploy-Role.
• Регулярно ревьюите и обновляйте политики с помощью IAM Access Analyzer и инструментов типа iamlive.
• Для межаккаунтового доступа всегда ограничивайте источник в политике доверия конкретными Account ID или конкретными внешними ID (для предотвращения конфуза).
• Меньше используйте inline policies — предпочитайте managed policies (их легче версионировать и аудировать).
• Применяйте Tags для категоризации ролей по проектам, окружениям (prod/dev), стоимости (для бюджетирования).

Типичные сценарии использования созданных ролей:

1. Для сервисов AWS:

   • Роль выполнения для AWS Lambda.
   • Роль для Amazon EC2 с Instance Profile для управления ресурсами.
   • Роль для AWS ECS или EKS для работы с другими сервисами.

2. Межаккаунтовые операции:

   • Роль в аккаунте A, которую может принимать пользователь/роль из аккаунта B для централизованного управления или делегирования.

3. Идентификация извне AWS:

   • Роль для пользователей, аутентифицированных через Corporate Active Directory (через SAML).
   • Роль для мобильного приложения, использующего Amazon Cognito и социальные идентификаторы (Web Identity Federation).

Создание ролей — это ежедневная практика для DevOps и Security Engineers в AWS. Правильно настроенные роли являются краеугольным камнем безопасной, масштабируемой и автоматизированной инфраструктуры в облаке. Использование инструментов автоматизации (CLI, Terraform, CloudFormation) для их создания обеспечивает повторяемость, контроль версий и интеграцию в CI/CD pipelines для управления инфраструктурой как кодом (IaC).