Azure Kubernetes 服务 (AKS) 中应用程序和群集的安全性相关概念Security concepts for applications and clusters in Azure Kubernetes Service (AKS)

在 Azure Kubernetes 服务 (AKS) 中运行应用程序工作负荷的过程中,若要保护客户数据,关键是要确保群集的安全性。To protect your customer data as you run application workloads in Azure Kubernetes Service (AKS), the security of your cluster is a key consideration. Kubernetes 包括安全组件,如网络策略和机密 。Kubernetes includes security components such as network policies and Secrets. Azure 会添加组件,例如网络安全组和协调群集升级。Azure then adds in components such as network security groups and orchestrated cluster upgrades. 这些安全组件共同确保 AKS 群集运行最新的 OS 安全更新和 Kubernetes 版本,并确保安全的 pod 流量和对敏感凭据的安全访问。These security components are combined to keep your AKS cluster running the latest OS security updates and Kubernetes releases, and with secure pod traffic and access to sensitive credentials.

本文介绍用于保护 AKS 中应用程序的核心概念:This article introduces the core concepts that secure your applications in AKS:

主组件安全Master security

在 AKS 中,Kubernetes 主组件是 Azure 提供的托管服务的一部分。In AKS, the Kubernetes master components are part of the managed service provided by Azure. 每个 AKS 群集都有其自己的单租户专用 Kubernetes 主组件,用于提供 API 服务器、计划程序等。此主组件由 Azure 管理和维护。Each AKS cluster has its own single-tenanted, dedicated Kubernetes master to provide the API Server, Scheduler, etc. This master is managed and maintained by Azure.

默认情况下,Kubernetes API 服务器使用公共 IP 地址和完全限定域名 (FQDN)。By default, the Kubernetes API server uses a public IP address and a fully qualified domain name (FQDN). 可使用 Kubernetes 基于角色的访问控制和 Azure Active Directory 控制对 API 服务器的访问。You can control access to the API server using Kubernetes role-based access controls and Azure Active Directory. 有关详细信息,请参阅 Azure AD 与 AKS 集成For more information, see Azure AD integration with AKS.

节点安全性Node security

AKS 节点是由你管理和维护的 Azure 虚拟机。AKS nodes are Azure virtual machines that you manage and maintain. Linux 节点通过 Moby 容器运行时运行经过优化的 Ubuntu 发行版。Linux nodes run an optimized Ubuntu distribution using the Moby container runtime. 创建或纵向扩展了 AKS 群集时,会自动使用最新的 OS 安全更新和配置来部署节点。When an AKS cluster is created or scaled up, the nodes are automatically deployed with the latest OS security updates and configurations.

Azure 平台会在夜间自动将 OS 安全修补程序应用于 Linux 节点。The Azure platform automatically applies OS security patches to Linux nodes on a nightly basis. 如果 Linux OS 安全更新需要重启主机,系统不会自动执行重启操作。If a Linux OS security update requires a host reboot, that reboot is not automatically performed. 可以手动重启 Linux 节点,或使用常用的方法,即使用 Kured,这是一个适用于 Kubernetes 的开源重启守护程序。You can manually reboot the Linux nodes, or a common approach is to use Kured, an open-source reboot daemon for Kubernetes. Kured 作为 DaemonSet 运行并监视每个节点,用于确定指示需要重启的文件是否存在。Kured runs as a DaemonSet and monitors each node for the presence of a file indicating that a reboot is required. 通过使用相同的 cordon 和 drain 进程作为群集升级,来跨群集管理重启。Reboots are managed across the cluster using the same cordon and drain process as a cluster upgrade.

系统将节点部署到专用虚拟网络子网中,且不分配公共 IP 地址。Nodes are deployed into a private virtual network subnet, with no public IP addresses assigned. 出于故障排除和管理的目的,会默认启用 SSH。For troubleshooting and management purposes, SSH is enabled by default. 只能使用内部 IP 地址访问此 SSH。This SSH access is only available using the internal IP address.

为提供存储,节点使用 Azure 托管磁盘。To provide storage, the nodes use Azure Managed Disks. 这些是由高性能固态硬盘支持的高级磁盘,适用于大多数规模的 VM 节点。For most VM node sizes, these are Premium disks backed by high-performance SSDs. 托管磁盘上存储的数据在 Azure 平台内会自动静态加密。The data stored on managed disks is automatically encrypted at rest within the Azure platform. 为提高冗余,还会在 Azure 数据中心内安全复制这些磁盘。To improve redundancy, these disks are also securely replicated within the Azure datacenter.

目前,在恶意的多租户使用情况下,AKS 或其他位置中的 Kubernetes 环境并不完全安全。Kubernetes environments, in AKS or elsewhere, currently aren't completely safe for hostile multi-tenant usage. 用于节点的其他安全功能(例如 Pod 安全策略或更细粒度的基于角色的访问控制 (RBAC))可增加攻击的难度。Additional security features such as Pod Security Policies or more fine-grained role-based access controls (RBAC) for nodes make exploits more difficult. 但是,为了在运行恶意多租户工作负荷时获得真正的安全性,虚拟机监控程序应是你唯一信任的安全级别。However, for true security when running hostile multi-tenant workloads, a hypervisor is the only level of security that you should trust. Kubernetes 的安全域成为整个群集,而不是单个节点。The security domain for Kubernetes becomes the entire cluster, not an individual node. 对于这些类型的恶意多租户工作负荷,应使用物理隔离的群集。For these types of hostile multi-tenant workloads, you should use physically isolated clusters. 有关如何隔离工作负荷的详细信息,请参阅 AKS 中的群集隔离最佳做法For more information on ways to isolate workloads, see Best practices for cluster isolation in AKS,

群集升级Cluster upgrades

为实现安全性和符合性及使用最新功能,Azure 提供相应工具来协调 AKS 群集和组件的升级。For security and compliance, or to use the latest features, Azure provides tools to orchestrate the upgrade of an AKS cluster and components. 此升级业务流程同时包括 Kubernetes 主组件和代理组件。This upgrade orchestration includes both the Kubernetes master and agent components. 可查看适用于 AKS 群集的可用 Kubernetes 版本的列表You can view a list of available Kubernetes versions for your AKS cluster. 若要开始进行升级,先指定一个可用版本(在上述版本中)。To start the upgrade process, you specify one of these available versions. 接着 Azure 会安全隔离和排空每个 AKS 节点并执行升级。Azure then safely cordons and drains each AKS node and performs the upgrade.

隔离和排空Cordon and drain

在升级过程中,AKS 节点会单独从群集中隔离出来,以便系统不会在其上计划新 Pod。During the upgrade process, AKS nodes are individually cordoned from the cluster so new pods aren't scheduled on them. 然后将节点排空并进行升级,操作如下:The nodes are then drained and upgraded as follows:

  • 将新节点部署到节点池中。A new node is deployed into the node pool. 此节点运行最新的 OS 映像和修补程序。This node runs the latest OS image and patches.
  • 其中一个现有的节点已确定要升级。One of the existing nodes is identified for upgrade. 妥善终止此节点上的 Pod 并在节点池中的其他节点上对其进行安排。Pods on this node are gracefully terminated and scheduled on the other nodes in the node pool.
  • 从 AKS 群集中删除此现有节点。This existing node is deleted from the AKS cluster.
  • 使用相同的过程隔离和排空群集中的下一个节点,直到在升级过程中成功替换所有节点。The next node in the cluster is cordoned and drained using the same process until all nodes are successfully replaced as part of the upgrade process.

有关详细信息,请参阅升级 AKS 群集For more information, see Upgrade an AKS cluster.

网络安全性Network security

如需实现本地网络的连接和安全性,可将 AKS 群集部署到现有 Azure 虚拟网络子网。For connectivity and security with on-premises networks, you can deploy your AKS cluster into existing Azure virtual network subnets. 这些虚拟网络可具有指向本地网络的 Azure 站点到站点 VPN 或 Express Route 连接。These virtual networks may have an Azure Site-to-Site VPN or Express Route connection back to your on-premises network. 可以使用专用的内部 IP 地址定义 Kubernetes 入口控制器,以便只能通过此内部网络连接访问服务。Kubernetes ingress controllers can be defined with private, internal IP addresses so services are only accessible over this internal network connection.

Azure 网络安全组Azure network security groups

为筛选虚拟网络中的通信流量,Azure 使用网络安全组规则。To filter the flow of traffic in virtual networks, Azure uses network security group rules. 这些规则定义要允许或拒绝哪些源和目标 IP 范围、端口和协议访问资源。These rules define the source and destination IP ranges, ports, and protocols that are allowed or denied access to resources. 会创建默认规则以允许 TLS 流量流向 Kubernetes API 服务器。Default rules are created to allow TLS traffic to the Kubernetes API server. 在使用负载均衡器、端口映射或入口路由创建服务时,AKS 会自动修改网络安全组,以便流量流向正确的方向。As you create services with load balancers, port mappings, or ingress routes, AKS automatically modifies the network security group for traffic to flow appropriately.

Kubernetes 机密Kubernetes Secrets

Kubernetes 机密用于将敏感数据注入到 pod,例如访问凭据或密钥。A Kubernetes Secret is used to inject sensitive data into pods, such as access credentials or keys. 首先使用 Kubernetes API 创建机密。You first create a Secret using the Kubernetes API. 在定义 pod 或部署时,可以请求特定机密。When you define your pod or deployment, a specific Secret can be requested. 机密仅提供给所计划的 pod 需要该机密的节点,且机密存储在 tmpfs 中,不写入磁盘。Secrets are only provided to nodes that have a scheduled pod that requires it, and the Secret is stored in tmpfs, not written to disk. 当节点上最后一个需要该机密的 pod 被删除后,将从该节点的 tmpfs 中删除该机密。When the last pod on a node that requires a Secret is deleted, the Secret is deleted from the node's tmpfs. 机密存储在给定的命名空间中,只有同一命名空间中的 pod 能访问该机密。Secrets are stored within a given namespace and can only be accessed by pods within the same namespace.

使用机密会减少 pod 或服务 YAML 清单中定义的敏感信息。The use of Secrets reduces the sensitive information that is defined in the pod or service YAML manifest. 可以请求存储在 Kubernetes API 服务器中的机密,作为 YAML 清单的一部分。Instead, you request the Secret stored in Kubernetes API Server as part of your YAML manifest. 此方法仅为 pod 提供特定的机密访问权限。This approach only provides the specific pod access to the Secret. 请注意:原始机密清单文件包含 base64 格式的机密数据(如需更多详细信息,请参阅官方文档)。Please note: the raw secret manifest files contains the secret data in base64 format (see the official documentation for more details). 因此,此文件应被视为敏感信息,不应提交给源代码管理。Therefore, this file should be treated as sensitive information, and never committed to source control.

后续步骤Next steps

若要开始为 AKS 群集提供保护,请参阅升级 AKS 群集To get started with securing your AKS clusters, see Upgrade an AKS cluster.

如需相关的最佳做法,请参阅 AKS 中群集安全性和升级的最佳做法AKS 中的 Pod 安全的最佳做法For associated best practices, see Best practices for cluster security and upgrades in AKS and Best practices for pod security in AKS.

有关核心 Kubernetes 和 AKS 概念的详细信息,请参阅以下文章:For additional information on core Kubernetes and AKS concepts, see the following articles: