# AWS IAM management

Each service should have a dedicated IAM role.

## Controlplane AWS Account

The controlplane roles are configured for [IRSA](https://docs.aws.amazon.com/eks/latest/userguide/iam-roles-for-service-accounts.html) to allow service pods use the role.

For historical reasons, the AWS account `385595570414` is used as both `dev` and `staging` environment controlplane account. AWS IAM role is global resource, but we provision them per region to avoid adding too many trust policies to a global IAM role. So the role name has the prefix `{env}-{logical-region-name}` by convention.

* region-server. The role is named as `{env}-{logical-region-name}-drs`
* cluster-controller
* crossplane-aws-provider
* cert-manager
* aws-load-balancer-controller
* external-secrets-operator

## Dataplane AWS Accounts

For historical reasons, the AWS account `385595570414` is used as both controlplane account and dataplane account for `dev` and `staging` environments. The AWS account `380838443567` is used as both controlplane account and dataplane account for `prod`. But new customors' clusters are created in dataplane only AWS accounts.

* region-server assumed role: region-server uses this role to manage dataplane resources including pass this to crossplane. The role is named as `{env}-{logical-region-name}-dp4drs`
* cluster-controller assumed role: cluster-controller uses this role to manage dataplane resources including pass this to crossplane. The role is named as `{env}-{logical-region-name}-cluster-controller-assumed-role`
* full-manager-eks-role: The EKS service uses this role to manage EKS related resources in customer account https://docs.aws.amazon.com/eks/latest/userguide/service_IAM_role.html


## Dataplane EKS cluster

Due to not all TiDB components support IRSA, we are still using node role for services in dataplane EKS cluster. With 3-layer architecture refactoring, we separate tidb cluster worker nodegroup role from admin nodegroup role. And each tidb cluster has a standalone IAM role.

* tidb cluster worker node role is prefixed with `ng-role-{meta_ns}-{cluster_id}`
* admin node role name is the same as dataplane EKS cluster name which is prefixed with `dedicated-{env}-{logical-region-name}`