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). 可以使用经授权的 IP 范围将访问范围限制为 API 服务器终结点。You can limit access to the API server endpoint using authorized IP ranges.

可使用 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. Windows Server 节点运行已优化的 Windows Server 2019 版本,并使用 Moby 容器运行时。Windows Server nodes run an optimized Windows Server 2019 release and also use 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.

对于 Windows Server 节点,Windows 更新不会自动运行和应用最新的更新。For Windows Server nodes, Windows Update does not automatically run and apply the latest updates. 在 Windows 更新发布周期和你自己的验证过程的定期计划中,你应在 AKS 群集中的 Windows Server 节点池上进行升级。On a regular schedule around the Windows Update release cycle and your own validation process, you should perform an upgrade on the Windows Server node pool(s) in your AKS cluster. 此升级过程会创建运行最新 Windows Server 映像和修补程序的节点,然后删除旧节点。This upgrade process creates nodes that run the latest Windows Server image and patches, then removes the older nodes. 有关此过程的详细信息,请参阅升级 AKS 中的节点池For more information on this process, see Upgrade a node pool in AKS.

系统将节点部署到专用虚拟网络子网中,且不分配公共 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 like 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.

计算隔离Compute isolation

由于符合性或法规要求,某些工作负载可能需要与其他客户工作负载高度隔离。Certain workloads may require a high degree of isolation from other customer workloads due to compliance or regulatory requirements. 对于这些工作负载,Azure 提供独立虚拟机,这些虚拟机可用作 AKS 群集中的代理节点。For these workloads, Azure provides isolated virtual machines, which can be used as the agent nodes in an AKS cluster. 这些独立虚拟机独立于特定硬件类型,并专用于单个客户。These isolated virtual machines are isolated to a specific hardware type and dedicated to a single customer.

要配合使用这些独立虚拟机和 AKS 群集,请在创建 AKS 群集或添加节点池时,选择此处列出的某个独立虚拟机大小作为“节点大小”。To use these isolated virtual machines with an AKS cluster, select one of the isolated virtual machines sizes listed here as the Node size when creating an AKS cluster or adding a node pool.

群集升级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.

如果为 AKS 群集提供了自己的子网,并且希望修改流量流,请不要修改 AKS 管理的子网级网络安全组。In cases where you provide your own subnet for your AKS cluster and you wish to modify the flow of traffic, do not modify the subnet-level network security group managed by AKS. 可以创建其他子网级网络安全组来修改流量流,只要它们不干扰管理群集(例如负载均衡器访问、与控制平面的通信,以及流出量)所需的流量。You may create additional subnet-level network security groups to modify the flow of traffic as long as they do not interfere with traffic needed for managing the cluster, such as load balancer access, communication with the control plane, and egress.

Kubernetes 网络策略Kubernetes network policy

为了限制群集中 Pod 之间的网络流量,AKS 提供了对 Kubernetes 网络策略的支持。To limit network traffic between pods in your cluster, AKS offers support for Kubernetes network policies. 使用网络策略,可以选择基于命名空间和标签选择器来允许或拒绝群集中的特定网络路径。With network policies, you can choose to allow or deny specific network paths within the cluster based on namespaces and label selectors.

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.

Kubernetes 机密存储在分布式密钥-值存储 etcd 中。Kubernetes secrets are stored in etcd, a distributed key-value store. Etcd 存储由 AKS 完全托管,并且数据在 Azure 平台中静态加密Etcd store is fully managed by AKS and data is encrypted at rest within the Azure platform.

后续步骤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: