eksctl项目中的ECR拉取缓存仓库权限优化解析

在Kubernetes集群管理工具eksctl中，关于ECR(Elastic Container Registry)拉取缓存仓库(Pull-Through Cache)的权限配置一直存在一个值得关注的技术细节。本文将深入分析这一权限问题的背景、影响以及解决方案。

问题背景

在AWS EKS集群中，节点角色需要具备从ECR拉取容器镜像的权限。当前eksctl(v0.206.0)默认使用AmazonEC2ContainerRegistryReadOnly托管策略，但这一策略缺少对ECR拉取缓存仓库(PTC)的关键权限ecr:BatchImportUpstreamImage。

ECR拉取缓存仓库是AWS提供的一项功能，允许用户创建本地缓存仓库来代理上游公共仓库(如容器镜像中心)。当节点尝试从这类缓存仓库拉取镜像时，需要额外的BatchImportUpstreamImage权限来从上游仓库导入镜像。

当前问题分析

现有配置存在两个主要问题：

1. 功能缺失：缺少BatchImportUpstreamImage权限导致无法正常使用ECR拉取缓存仓库功能
2. 权限过度：AmazonEC2ContainerRegistryReadOnly策略包含一些不必要的权限，如ecr:GetAuthorizationToken，违反了最小权限原则

解决方案

AWS已经提供了更合适的托管策略AmazonEC2ContainerRegistryPullOnly，该策略：

• 包含必需的BatchImportUpstreamImage权限
• 移除了不必要的权限
• 完全符合AWS官方对节点角色的最新建议

值得注意的是，EKS Auto Mode已经采用了这一更优的策略配置。Karpenter项目也已完成了相应变更。

实施建议

考虑到向后兼容性，建议分阶段实施：

1. 立即将AmazonEC2ContainerRegistryPullOnly加入默认策略
2. 后续版本中逐步移除AmazonEC2ContainerRegistryReadOnly

这种渐进式变更可以：

• 立即解决ECR拉取缓存仓库的功能问题
• 给予用户足够时间调整可能依赖旧权限的自定义脚本
• 最终实现更安全的权限配置

技术影响评估

这一变更主要影响两类场景：

1. 直接在节点上运行并依赖ECR写权限的脚本
2. 未使用IRSA/Pod Identity而直接使用节点IAM角色的Pod

对于大多数现代Kubernetes部署来说，这些场景已经不再常见，因此变更风险较低。

总结

eksctl作为EKS集群管理的重要工具，其默认权限配置直接影响集群的安全性和功能性。这次针对ECR拉取缓存仓库的权限优化，既解决了功能缺失问题，又推进了最小权限原则的实施，是工具持续改进的重要一步。