如何用CDK复现eksctl create iamserviceaccount配置External Secrets Operator

我尝试用CDK配置External Secrets Operator，对应AWS指南中的eksctl create iamserviceaccount步骤时遇到问题。指南中创建的blogdemosa角色信任关系如下：

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "Federated": "arn:aws:iam::<account_id>:oidc-provider/oidc.eks.us-east-1.amazonaws.com/id/<cluster_oidc_id>"
            },
            "Action": "sts:AssumeRoleWithWebIdentity",
            "Condition": {
                "StringEquals": {
                    "oidc.eks.us-east-1.amazonaws.com/id/<cluster_oidc_id>:sub": "system:serviceaccount:default:blogdemosa",
                    "oidc.eks.us-east-1.amazonaws.com/id/<cluster_oidc_id>:aud": "sts.amazonaws.com"
                }
            }
        }
    ]
}

我写出了大致的CDK代码，但不知道FederatedPrincipal的参数该如何填写：

const serviceAccountRole = new iam.Role(this, 'ServiceAccountRole', {
    roleName: 'ServiceAccountRole',
    assumedBy: new iam.FederatedPrincipal(???),
    managedPolicies: [iam.ManagedPolicy.fromAwsManagedPolicyName('SecretsManagerReadWrite')]
});

const serviceAccount = cluster.addServiceAccount('ServiceAccount', {
    name: 'eso-service-account',
    annotations: {
        'eks.amazonaws.com/role-arn': serviceAccountRole.roleArn
    }
});

手动构建FederatedPrincipal的写法 #

FederatedPrincipal需要传入三个核心参数：OIDC提供商ARN、信任条件、允许的动作。你可以通过CDK的集群对象动态获取OIDC信息，避免硬编码：

// 从EKS集群对象获取OIDC提供商信息
const oidcProviderArn = cluster.openIdConnectProvider.openIdConnectProviderArn;
const oidcIssuer = cluster.openIdConnectProvider.openIdConnectProviderIssuer;
const serviceAccountName = 'eso-service-account';
const namespace = 'default';

const serviceAccountRole = new iam.Role(this, 'ServiceAccountRole', {
  roleName: 'ServiceAccountRole',
  assumedBy: new iam.FederatedPrincipal(
    // 第一个参数：OIDC提供商的ARN
    oidcProviderArn,
    // 第二个参数：信任条件，和指南中的Condition完全匹配
    {
      StringEquals: {
        [`${oidcIssuer}:sub`]: `system:serviceaccount:${namespace}:${serviceAccountName}`,
        [`${oidcIssuer}:aud`]: 'sts.amazonaws.com'
      }
    },
    // 第三个参数：允许的STS动作
    'sts:AssumeRoleWithWebIdentity'
  ),
  managedPolicies: [iam.ManagedPolicy.fromAwsManagedPolicyName('SecretsManagerReadWrite')]
});

const serviceAccount = cluster.addServiceAccount('ServiceAccount', {
  name: serviceAccountName,
  namespace: namespace,
  annotations: {
    'eks.amazonaws.com/role-arn': serviceAccountRole.roleArn
  }
});

更简洁的CDK最佳实践写法 #

其实CDK的cluster.addServiceAccount方法可以自动创建对应的IAM角色并配置正确的信任关系，不需要手动构建FederatedPrincipal，代码更简洁：

const serviceAccount = cluster.addServiceAccount('EsoServiceAccount', {
  name: 'eso-service-account',
  namespace: 'default'
});

// 给自动创建的角色附加权限
serviceAccount.addManagedPolicy(iam.ManagedPolicy.fromAwsManagedPolicyName('SecretsManagerReadWrite'));

这种方式下，CDK会自动生成和指南中一致的信任关系，无需手动配置FederatedPrincipal，减少出错概率。

内容的提问来源于stack exchange，提问作者James Kelleher