EKS 权限管理，还在复杂操作吗？🤔 为什么你应该切换到 Pod Identity

大家好！今天，我们将深入探讨如何在AWS EKS中管理容器（Pod）权限。当您的应用程序需要访问S3或DynamoDB等AWS服务时，您是如何安全高效地授予权限的呢？

可能很多人都在使用IRSA (IAM Roles for Service Accounts)。但是，在设置IRSA时，您是否也曾因复杂的IAM信任策略而头疼不已呢？🤯

最近，AWS为了解决这个问题，推出了一个新功能：EKS Pod Identity。今天，我们将彻底比较现有的强者IRSA和新挑战者EKS Pod Identity，并明确地为您整理在何种情况下应该选择哪一个！

---

🧐 IRSA: 熟悉但棘手的朋友

IRSA是一种将Kubernetes的服务账户(Service Account)与AWS的IAM角色直接关联起来的方式。它利用EKS集群的OIDC(OpenID Connect)信息，配置IAM角色以信任特定的服务账户。

✨ IRSA是如何工作的？

1. OIDC身份提供者配置: 创建EKS集群时，会生成一个唯一的OIDC提供者(Provider) URL。这就像一张身份证，让AWS IAM能够识别我们的集群。🆔
2. IAM角色创建和信任策略配置: 创建一个具有授予Pod权限的IAM角色。这里的核心是信任策略(Trust Policy)，它必须非常具体地声明：“此角色信任EKS集群的OIDC提供者，并且只向my-app命名空间中名为my-service-account的服务账户颁发临时凭证！”
3. 向服务账户添加注解: 通过注解(eks.amazonaws.com/role-arn)明确指定应用程序将使用的Kubernetes服务账户应使用哪个IAM角色。
4. 获取凭证: Pod运行时，内部的AWS SDK会根据这些信息向AWS请求临时凭证，并使用获得的密钥调用AWS API。🚀

🔧 IRSA配置示例

我们来看看最令人头疼的部分：IAM角色的信任策略。它确实又长又复杂。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "Federated": "arn:aws:iam::111122223333:oidc-provider/oidc.eks.ap-northeast-2.amazonaws.com/id/EXAMPLED539D4633E53BF441"
            },
            "Action": "sts:AssumeRoleWithWebIdentity",
            "Condition": {
                "StringEquals": {
                    "oidc.eks.ap-northeast-2.amazonaws.com/id/EXAMPLED539D4633E53BF441:sub": "system:serviceaccount:my-namespace:my-app-sa",
                    "oidc.eks.ap-northeast-2.amazonaws.com/id/EXAMPLED539D4633E53BF441:aud": "sts.amazonaws.com"
                }
            }
        }
    ]
}

在这个冗长的策略中，OIDC地址、命名空间、服务账户名称中只要有一个出错，就会导致权限错误。😭

Kubernetes服务账户的配置如下：

apiVersion: v1
kind: ServiceAccount
metadata:
  name: my-app-sa
  namespace: my-namespace
  annotations:
    # 您必须在此处直接插入IAM角色的ARN！
    eks.amazonaws.com/role-arn: arn:aws:iam::111122223333:role/my-app-s3-access-role

👍 IRSA的优点

• 无需代理: 无需在节点上安装额外的代理，配置简洁。
• 基于标准技术: 使用OIDC这一开放标准，原理清晰。
• 显式配置: 所有权限连接信息都以代码形式在Kubernetes清单中管理（有利于GitOps）。

👎 IRSA的缺点

• 信任策略过于复杂: IAM信任策略冗长复杂，容易出错且难以管理。
• 紧密耦合(Tight Coupling): IAM角色的ARN硬编码在服务账户的YAML中。更改角色需要重新部署Kubernetes资源。
• 管理点分散: 角色越多，需要管理的IAM信任策略也成比例增加，管理起来很麻烦。

---

😎 EKS Pod Identity: 以简洁为武器的新解决方案

EKS Pod Identity是为解决IRSA的复杂性而出现的救星。其核心在于将权限设置的中心从Kubernetes转移到了AWS。

✨ EKS Pod Identity是如何工作的？

1. 安装EKS Pod Identity Agent: 在集群中作为EKS Add-on安装代理。这个代理在每个节点上运行，是施展魔法的主体。🪄
2. 创建简单的IAM角色: 现在，IAM角色的信任策略变得惊人地简单。“EKS Pod Identity服务可以信任我！”一句话就搞定。
3. 创建Pod Identity Association: 通过AWS控制台或CLI，将IAM角色和Kubernetes服务账户进行映射(Association)。此操作在Kubernetes外部，即在AWS中完成。
4. 获取凭证: 当Pod请求AWS凭证时，节点上的代理会拦截请求。然后，它会检查AWS中配置的映射信息，并代表Pod获取正确IAM角色的临时凭证，然后将其传递给Pod。

🔧 EKS Pod Identity配置示例

与IRSA相比，看看IAM信任策略变得多么简单。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "Service": "pods.eks.amazonaws.com"
            },
            "Action": "sts:AssumeRole"
        }
    ]
}

是的，这就是全部。不需要OIDC URL，不需要命名空间，也不需要服务账户名称！✨

IAM角色和服务账户的连接可以通过AWS CLI这样一行命令完成：

aws eks create-pod-identity-association 
    --cluster-name my-eks-cluster 
    --namespace my-namespace 
    --service-account my-app-sa 
    --role-arn arn:aws:iam::111122223333:role/my-app-s3-access-role

现在，开发人员无需在服务账户的YAML文件中添加复杂的注解，只需指定serviceAccountName: my-app-sa即可。

👍 EKS Pod Identity的优点

• 革命性的简洁: 复杂的信任策略消失，IAM角色管理变得非常简单。
• 集中管理和职责分离: 基础设施团队可以在AWS中管理权限映射，开发团队可以专注于应用程序代码。职责分工明确！
• 灵活性和可重用性: 一个IAM角色可以轻松映射到多个命名空间、多个服务账户，最大限度地提高了角色的可重用性。
• 配置与代码分离: IAM角色信息与Kubernetes清单分离，权限更改时无需重新部署应用程序。

👎 EKS Pod Identity的缺点

• 代理依赖: 必须在所有节点上安装和管理EKS Pod Identity代理插件。
• 相对较新功能: 与IRSA相比，社区的使用案例或故障排除信息可能较少。

---

🆚 IRSA vs EKS Pod Identity: 一目了然的比较

类别	IRSA (IAM Roles for Service Accounts)	EKS Pod Identity
工作方式	K8s服务账户 ↔️ IAM角色 (OIDC直接连接)	Pod ➡️ 代理 ➡️ IAM角色 (基于映射)
配置中心	Kubernetes (服务账户注解)	AWS (Pod Identity Association)
IAM信任策略	非常复杂 😭 (明确OIDC、命名空间、SA条件)	非常简单 😊 (“Service”: “pods.eks.amazonaws.com”)
管理便捷性	低 (单独策略管理繁琐)	高 (集中管理映射信息)
灵活性	低 (IAM角色与服务账户1:1紧密耦合)	高 (角色与SA分离，易于N:M映射)

—

🎯 那么，您的选择是？

现在，您应该清楚该选择哪一个了。

🚀 选择EKS Pod Identity！

• 如果您正在构建新的EKS集群，或者刚刚开始配置权限（强烈推荐！）
• 如果您运营着众多微服务，希望简化IAM角色管理
• 如果您希望明确分离基础设施团队和开发团队的职责
• 如果您希望将一个通用角色在多个应用程序中重用

🤔 您可以继续使用或考虑IRSA。

• 如果您的所有系统已经基于IRSA稳定运行，并且没有迁移的余力
• 如果由于安全策略或其他原因，难以在节点上安装额外的代理
• 如果您偏好在Kubernetes清单中以代码形式显式管理(GitOps)所有权限设置

✨ 结论

EKS Pod Identity解决了IRSA的复杂性，并为云原生环境提供了更合适的权限管理范式。配置的简洁性、管理的集中化、灵活的可重用性是其不可抗拒的吸引力。

当然，这并不意味着IRSA是一种不好的技术。但是，如果出现了一条更简单、更高效的道路，我们又有什么理由不选择它呢？如果您目前正在考虑EKS权限管理，强烈建议您积极考虑EKS Pod Identity！

---