AWS IAM migration to STACKIT

ECS task roles to STACKIT service accounts

From the published AWS Retail Store run. Left: the AWS source exactly as AWS publishes it. Right: the resource blocks StackToIT wrote; the review comments above each block in the file are left out here.

resource "aws_iam_role" "task_execution_role" {
  name               = "${var.environment_name}-${var.service_name}-te"
  assume_role_policy = data.aws_iam_policy_document.assume_role_policy.json
  tags               = var.tags
}

resource "aws_iam_role_policy_attachment" "task_execution_role_policy" {
  role       = aws_iam_role.task_execution_role.name
  policy_arn = "arn:aws:iam::aws:policy/service-role/AmazonECSTaskExecutionRolePolicy"
}

resource "aws_iam_role_policy_attachment" "task_execution_role_additional" {
  count      = length(var.additional_task_execution_role_iam_policy_arns)
  role       = aws_iam_role.task_execution_role.name
  policy_arn = var.additional_task_execution_role_iam_policy_arns[count.index]
}

resource "aws_iam_role" "task_role" {
  name               = "${var.environment_name}-${var.service_name}-task"
  assume_role_policy = data.aws_iam_policy_document.assume_role_policy.json
  tags               = var.tags
}

resource "stackit_service_account" "retail_app_ecs_carts_service_task_execution_role" {
  project_id = var.project_id
  name       = "retail-app-ec-e66809"
}

resource "stackit_authorization_project_role_assignment" "retail_app_ecs_carts_service_task_execution_role" {
  for_each    = toset(var.carts_task_execution_project_roles)
  resource_id = var.project_id
  role        = each.value
  subject     = stackit_service_account.retail_app_ecs_carts_service_task_execution_role.email
}

• Roles become service accounts

  Each task role and execution role becomes a STACKIT service account, named within STACKIT’s limit of 20 characters.

• Permissions become role assignments

  AWS actions do not map one to one to STACKIT roles, so the roles are a variable per service account that your architect fills.

• Service roles fall away

  Roles that only an AWS-managed service uses, such as the EKS control plane, are named as not needed on STACKIT.

• Trust policies named

  A STACKIT service account has no trust policy. The code says so, and references to role ARNs are listed for update.

What the Retail Store run produced

Identity is more than roles. These are the facts of the published AWS Retail Store run.

• Ten roles, ten service accounts

  Five services (ui, catalog, carts, checkout, orders) each have a task role and an execution role. Each becomes one stackit_service_account.

• One variable per account

  Every service account gets a role assignment driven by a variable, such as carts_service_task_project_roles or carts_task_execution_project_roles. The run wrote ten of them for your architect to fill.

• Names within the limit

  A service account name has at most 20 characters, lowercase letters, digits and single dashes, and is unique in a project. The draft cuts the name and adds a suffix of the SHA-256 of the source address, for example retail-app-ec-e66809. Set the name you prefer.

• Attachment stays a decision

  For all five ECS services the identity attachment is marked as a decision. The Identity Architect owns the work package Set up the identities and access, with ten steps.

• Switched-off roles still classified

  In the Retail estate the two RDS enhanced monitoring roles and the VPC flow log role are switched off with count = 0. The run still records how it would treat them: a monitoring role that a database instance uses counts as a role of an AWS-managed service, and a role whose purpose depends on values known only at plan time goes to your architect.

• Secrets alongside

  Four Secrets Manager secrets map to STACKIT Secrets Manager. A script writes them through its Vault-compatible API once you accept the decision to depend on that API.

Questions security teams ask

Sources

• AWS Docs: IAM roles
• STACKIT Docs: Platform (IAM, service accounts, roles, projects)