EKS Security Best Practices

In this blog we are going to see the security best practices for EKS cluster related to IRSA roles and service account tokens.

Restrict IRSA Trust policy to Service Account Name Scope and Don't use *.

Sample Trust policy for the IRSA role.

{
"Version": "2012-10-17",
"Statement": [{
"Effect": "Allow",
"Principal": {
"Federated": "arn:aws:iam::CI_ACCOUNT_ID:oidc-provider/OIDC_PROVIDER"
},
"Action": "sts:AssumeRoleWithWebIdentity",
"Condition": {
"StringEquals": {
"<OIDC_PROVIDER>:sub": "system:serviceaccount:<namespace>:<serviceaccount>"
}
}
}]
}

Assume a demo namespace has two IRSA roles create with trust policy system:serviceaccount:demo:*

IAM Role 1 - ServiceAccount01 - access to S3
IAM Role 2 - ServiceAccount02 - access to S3 and DynamoDB

Pod1 with ServiceAccount01 can access Role 2 just by exporting the AWS_ROLE_ARN = <ARN OF IAM ROLE 2> so that it will get access to S3 and DynamoDB .

Enable IRSA role for aws-node daemonset.

EKS supports IRSA roles for the aws-node daemonset, it is security best practice to use IRSA role instead of system node role.

Disable auto-mounting of service account tokens

Update the pod spec with automountServiceAccountToken=false attribute if there is no need for the application to access EKS Control plane API.