导读

Kubernetes集群可能是一个复杂的环境，包含多个组件和配置。保护您的软件供应链、控制平面、工作节点和Pod安全策略对于防止未经授权的访问、资源滥用和数据泄露至关重要。在本次会议中，您将了解可以帮助您保护Amazon EKS集群的功能。获取有关安全和平台管理员如何保护依赖于Amazon EKS的信息、系统和资产，同时为客户提供业务价值的指导。本次会议涵盖了特定于Amazon EKS、Amazon ECR、Amazon Identity and Access Management (IAM)和网络安全的安全指南。

演讲精华

以下是小编为您整理的本次演讲的精华。

演讲者Micah Howsler和Jordan John首先阐明了确保在Amazon Elastic Kubernetes Service (EKS)上运行的Kubernetes工作负载的安全性的重要性。他们强调Kubernetes的采用率大幅上升，2023年Cloud Native Computing Foundation年度调查显示，84%的受访者已在生产环境中使用或正在评估实施Kubernetes。这一趋势也体现在Amazon EKS的使用量不断增长，客户每年在EKS上运行数千万个集群，且数量持续攀升。

六年多前推出EKS的动机源于客户反馈，管理大规模Kubernetes存在诸多困难。客户需耗费大量时间和精力来监控、扩展和管理Kubernetes控制平面，因此希望与各种亚马逊云科技服务实现本地集成。自问世以来，EKS已成为在亚马逊云科技上运行Kubernetes的最可靠途径，不仅免去了管理Kubernetes控制平面的繁重工作，还简化了集群管理的其他方面。

Howsler和John强调了亚马逊云科技和EKS的安全性的至关重要性，并阐述了共享责任模式，其中亚马逊云科技负责云端的安全性，而客户则负责确保云端工作负载和数据的安全。他们解释说，亚马逊云科技管理着底层三个层面，包括Kubernetes控制平面、底层基础设施、区域、本地区域以及控制平面所依赖的基础服务，如计算、存储、网络和Kubernetes API服务器。相反，客户则负责确保在其虚拟私有云(VPC)中运行的EC2实例和工作节点的安全性，包括操作系统补丁、健康监控、自动扩缩容管理以及确保在工作节点上运行的Kubernetes二进制文件的完整性。

考虑到共享责任，亚马逊云科技和EKS为客户提供了一系列工具和功能，如安全组、子网、私有端点访问、EKS插件和EKS优化的Amazon Machine Images (AMIs)，以帮助客户安全配置数据平面和VPC基础设施。但最终责任仍在客户。

转而讨论第一层安全控制措施，Howsler和John深入探讨了集群级别的措施。首先，他们探讨了使用Kubernetes原生的aws-auth配置映射进行集群身份验证的方法。该方法允许将IAM主体映射到Kubernetes权限，从而利用IAM的优势，如多因素身份验证和通过CloudTrail日志进行审计。然而，这种方法也存在一些权衡，包括需要在集群创建和权限配置时使用不同的API，以及可能出现脆弱配置和意外超级用户访问权限的情况。

为解决这些挑战，亚马逊云科技在上一次re:Invent活动后不久推出了集群访问管理功能。该功能统一了API，使客户能够使用EKS API创建集群、设置权限并撤销自动授予的权限。它简化了配置流程，并提供了对访问管理的精细控制。

演讲者强烈建议采用集群访问管理，并强调它是EKS未来发展的方向，所有新功能和能力都将建立在这一基础之上。他们还指出，对于现有使用aws-auth配置映射的集群，有一条简单的迁移路径。

Howsler和John详细阐述了幕后的流程:客户首先会与IAM交互，创建一个IAM主体(角色或用户)。然后，他们将利用作为集群访问管理功能一部分引入的新API(可通过EKS控制台和API使用)，创建两个主要实体:一个访问条目，将IAM实体与集群关联;一个访问策略，定义授予访问条目的权限。

一旦完成这些步骤，当用户尝试访问API服务器时，亚马逊云科技 STS将被隐式调用(由IAM身份验证器或CLI get token操作触发)。请求将被控制平面中的一个Webhook拦截，该Webhook会检查STS令牌、识别相关用户身份，并将其与访问条目进行匹配。如果身份验证成功，一系列授权者将评估访问策略，以确定用户身份是否映射到适当的权限，如果授权则允许请求继续进行。

在讨论如何为集群内运行的应用程序分配亚马逊云科技权限时，演讲者介绍了IAM Roles for Service Accounts (IRSA)和更新的Pod Identity功能。IRSA于2019年推出，允许为Pod授予精细的亚马逊云科技权限，使同一EC2实例上运行的多个应用程序拥有不同的权限集。然而，IRSA也存在一些权衡，例如需要集群管理员创建IAM OIDC提供程序(这是一项特权操作，在受监管行业中需要与IAM管理员协调)。此外，IRSA对可使用的角色数量和集群数量有限制，而且在跨集群重用角色时，需要频繁更新信任策略。

为解决这些限制，亚马逊云科技推出了Pod Identity功能，旨在简化信任管理，并使EKS服务能够创建可由整个服务承担的角色。Pod Identity提供了新的功能，包括基于属性的访问控制(通过IAM角色会话标签)、跨集群重用策略和角色的能力，以及在单个步骤中创建具有所有所需权限的集群的能力。

演讲者强调，虽然IRSA将继续得到支持，但Pod Identity是专门为EKS托管集群而设计的，不适用于EKS Anywhere或在EC2上自行管理的Kubernetes集群。这为客户提供了选择最适合其用例和需求的解决方案的选择。

演讲者阐述了Pod Identity的工作流程:客户首先会与IAM交互，创建一个IAM角色，其权限策略指定对所需亚马逊云科技资源(如S3存储桶)的访问权限，信任策略则指明该角色可由EKS服务主体承担。然后，客户将使用Pod Identity API或控制台创建一个Pod Identity关联，将IAM角色映射到Kubernetes服务账户。

当部署具有关联服务账户的Pod时，一个Webhook将拦截请求并修改Pod规范，添加众所周知的环境变量。亚马逊云科技 SDK随后将挂载服务账户令牌，调用Pod Identity代理，该代理将验证令牌并通过assume role for Pod Identity API承担IAM角色，返回一个临时亚马逊云科技凭证，该凭证将被注入到Pod中，使应用程序能够访问指定的亚马逊云科技资源。

演讲者强调了Pod Identity的最新增强功能，包括在所有商业亚马逊云科技区域的可用性、代理的开源以实现部署灵活性，以及在EKS插件中对Pod Identity的支持，简化了需要亚马逊云科技权限的操作软件的设置体验。

在讨论检测控制措施时，演讲者介绍了日志记录和监控机制。他们解释说，对EKS集群API服务器的请求将记录在控制平面审计日志中，该日志可启用流向CloudWatch。这允许利用CloudWatch Log Insights进行进一步分析，并设置警报以检测未经授权的访问或其他安全事件。

同样，对EKS服务API的请求将记录在CloudTrail中，可通过CloudTrail Insights和Amazon Detective与EKS的VPC Flow Logs集成进行分析和可视化。

演讲者还强调了加密功能，如EBS、EFS和FSx for Lustre等本地亚马逊云科技存储选项支持使用亚马逊云科技托管密钥或客户提供的密钥进行静态加密。此外，存储在Kubernetes Secrets对象中的敏感信息可使用Amazon Key Management Service (KMS)密钥进行加密，并受益于自动密钥轮换。

演讲者接着深入探讨了其他集群范围的控制措施，如将Kubernetes集群端点配置为私有模式，确保流量保持在VPC内部。他们还讨论了使用Amazon PrivateLink实现从VPC内部到EKS API的私有连接。

演讲者强调使用托管组件的重要性，建议利用EKS插件、EKS优化的AMI和其他托管产品，因为亚马逊云科技将负责对这些组件进行补丁和解决漏洞。此外，他们建议与Amazon Security Hub集成，后者提供了预定义的检查，用于评估EKS集群的安全状况。

在讨论基础设施级别的安全控制措施时，演讲者介绍了新推出的EKS Auto Mode功能。EKS Auto Mode自动化了整个Kubernetes集群基础设施，亚马逊云科技将负责根据客户定义的Pod创建和部署节点。该功能利用了由亚马逊云科技管理的开源Carpenter项目，通过为指定的Pod要求创建适当的EC2节点类型，优化资源利用率并提高性能。

EKS自动模式通过消除为客户创建和配置节点组的需求，减少了与更新机器映像相关的操作开销。节点的最长生命周期为21天，确保应用程序可以平稳地迁移到具有最新安全补丁的最新Amazon机器映像，从而提高了敏捷性并加速了创新。

在EKS自动模式下，共享责任模型进行了调整，亚马逊云科技承担维护容器、VPC基础设施以及自动包含的kubelet、容器网络接口、kube-proxy和CSI驱动程序等附加组件的安全责任。客户仍然负责他们安装的任何其他附加组件。

演讲者还讨论了网络安全控制，强调利用由亚马逊云科技 VPC容器网络接口(CNI)插件支持的Kubernetes网络策略，根据标签、网络命名空间和第7层属性(如主机名或TCP端口)定义细粒度的pod到pod通信规则。或者，客户可以通过弹性网络接口(ENI)将EC2安全组应用于Kubernetes pod，提供一种离主机机制来控制网络访问。

演讲者建议与Amazon GuardDuty集成，以实现基础设施层的检测控制。GuardDuty通过引入Kubernetes审计日志并使用机器学习和已知攻击模式来检测错误配置或潜在威胁，从而提供审计日志保护，并向客户发出警报以进行补救。

此外，GuardDuty的运行时保护功能通过EKS附加组件将代理部署到工作节点，监控已知的攻击模式和可能无法在Kubernetes审计日志中捕获但可能在Linux审计日志中检测到的文件更改。

其他推荐的基础设施安全控制包括使用亚马逊云科技 Systems Manager Session Manager而不是SSH来限制和最小化对实例的访问，利用容器优化的操作系统(如Amazon EKS优化的AMI或经过强化的Bottlerocket OS)，并根据CIS Kubernetes基准验证集群配置。

转移到应用层，演讲者强调了pod安全性的重要性，并建议使用Kubernetes Pod安全标准或外部pod安全策略代码解决方案(如Kyverno、Open Policy Agent Gatekeeper或其他)来实施安全标准。

重点强调的最佳实践包括限制特权容器、禁用不需要访问Kubernetes API的应用程序的服务帐户令牌挂载、限制使用hostPath挂载以及为不需要对文件系统进行写访问的应用程序配置只读文件系统。

演讲者还强调了镜像安全性，建议定期使用Amazon Inspector的本机集成扫描来自Amazon Elastic Container Registry(ECR)等源的容器镜像是否存在漏洞。此外，演讲者建议使用ECR与Amazon PrivateLink将镜像拉取限制在VPC内，并将镜像配置为以非root用户身份运行，以降低潜在的权限提升风险。

演讲者介绍了一个令人兴奋的新的开源原型Cedar，它使用Open Policy Agent(OPA)重新设计了Kubernetes授权。Cedar解决了传统Kubernetes基于角色的访问控制(RBAC)的局限性，例如无法定义拒绝或条件，通过利用OPA的访问控制语言和运行时评估引擎。

使用Cedar，客户可以定义指定主体、操作、资源和条件的策略，实现细粒度和基于属性的访问控制。演讲者通过现场演示展示了Cedar的功能，演示了如何根据用户组、资源标签和其他条件定义策略以允许或禁止特定操作，提供了比RBAC更灵活和强大的授权机制。

虽然Cedar目前是一个原型，但演讲者对将其集成到EKS表现出了热情，并鼓励客户下载、尝试并为这个开源项目提供反馈。

在结束会议时，演讲者分享了一些进一步学习和探索的资源，包括EKS最佳实践指南、EKS研讨会、用于Terraform和Amazon CDK配置的EKS蓝图，以及GitHub上即将推出的EKS功能公共路线图，客户可以在其中为功能请求投票并订阅。

总之，演讲者全面概述了在Amazon EKS上保护Kubernetes工作负载的安全控制和最佳实践，涵盖了集群、基础设施和应用层。他们介绍了亚马逊云科技的新功能和服务，如集群访问管理、Pod身份、EKS自动模式和Cedar原型，旨在简化和增强EKS集群的安全态势。在整个会议过程中，他们强调了共享责任模型、利用托管组件和亚马逊云科技安全服务的重要性，以及有效保护Kubernetes工作负载所需的多层方法。

我们正处在 Agentic AI 爆发前夜。 2025 亚马逊云科技中国峰会提出，企业要从 " 成本优化 " 转向 " 创新驱动 " ，通过完善的数据战略和 AI 云服务，把握全球化机遇。亚马逊将投入 1000 亿美元在 AI 算力、云基础设施等领域，通过领先的技术实力和帮助“中国企业出海“和”服务中国客户创新“的丰富经验，助力企业在 AI 时代突破。