2. 保护对 Kubernetes 控制平面（API 服务器）的访问
Kubernetes 中的 API 访问控制是一个三步过程。首先，对请求进行身份验证，然后检查请求的有效授权，然后执行请求准入控制，最后授予访问权限。但在身份验证过程开始之前，确保正确配置网络访问控制和 TLS 连接应该是第一要务。
2.1 Kubernetes API 网络访问最佳实践
2.1.1 随处配置和使用 TLS
与 API 服务器的连接、控制平面内部的通信以及控制平面和 Kubelet 之间的通信只能使用 TLS 连接进行配置。尽管 API 服务器可以通过向 kube-apiserver 提供 --tls-cert-file=[file] 和 --tls-private-key-file=[file] 标志轻松配置为使用 TLS，但鉴于 Kubernetes 能够根据需要快速扩展或缩减，在集群内配置连续的 TLS 证书管理具有挑战性。为了解决这个问题，Kubernetes 引入了 TLS 引导功能，它允许在 Kubernetes 集群内进行自动证书签名和 TLS 配置。
以下是 Kubernetes 管理员应注意的 kube-apiserver 支持的与 TLS 相关的标志：
全局 TLS 连接设置：
–secure-port
用于 HTTPS 连接到 kube-apiserver 的网络端口。默认端口为 6443。您还可以通过使用 --secure-portflag 提供所需的端口号来更改默认安全端口 (6443)。
–tls-cert-file, –tls-private-key-file
这些标志为 HTTPS 连接配置 x509 证书和私钥。
--cert-dir
配置 TLS 证书和密钥文件目录。 --tls-cert-file 和 --tls-private-key-file 标志将优先于该目录中的证书。 --cert-dir 的默认位置是 /var/run/kubernetes。
–tls-cipher-suites
为 TLS 配置首选密码套件。如果未提供此标志，kube-apiserver 将使用 Golang 提供的默认密码套件运行。
–tls-min-version
配置支持的最低 TLS 版本。值可以是：VersionTLS10、VersionTLS11、VersionTLS12、VersionTLS13。
–tls-sni-cert-key
将服务器名称指示 (SNI) 配置为对值 –tls-sni-cert-key=testdomain.crt,testdomain.key。
–strict-transport-security-directives
配置 HTTP 严格传输安全 (HSTS)。
–requestheader-client-ca-file, –proxy-client-cert-file, –proxy-client-key-file
Kubernetes 允许使用聚合层使用自定义 API 扩展 kube-apiserver。聚合层允许您构建自己的 API Server（对 kube-apiserver 的扩展）。为了保护 kube-apiserver 和自定义 API 服务器之间的通信，这些标志允许您配置 x509 证书以实现安全和可信的通信。
API 服务器和 Kubelet 之间的 TLS 连接：
–kubelet-certificate-authority, –kubelet-client-certificate, –kubelet-client-key
这些标志允许您为 Kubernetes API 服务器和 Kubelet 之间的 TLS 配置配置 CA、客户端证书和客户端私钥。
API server 和 etcd 之间的 TLS 连接：
–etcd-cafile, –etcd-certfile, –etcd-keyfile
这些标志让您可以配置 API 和 etcd 之间的 TLS 连接。
2.1.2 API 服务器的安全直接网络访问
不要在生产中启用 localhost 端口。
默认情况下，Kubernetes API 在两个端口上提供 HTTP：localhost 和 Secure 端口。 localhost 端口不需要 TLS，对该端口的请求可以绕过认证和授权模块。因此，请确保在 Kubernetes 集群的测试设置之外未启用此端口。
使用 Kubectl Proxy 管理安全的客户端访问。
安全通信（身份验证、传输）需要在客户端和服务器中进行仔细的秘密管理。如果您的团队是分布式的，那么 kubectl 很可能被来自不同位置的多个用户使用，从而增加了凭据（证书文件、令牌）泄露的可能性。您可以配置一个堡垒服务器，其中配置了 kubectl 代理，以便用户将 HTTPS 请求发送到此堡垒服务器，而 kubectl 代理（使用所需的凭据）转发到 API 服务器。这样，可以确保安全的客户端凭据永远不会离开经过安全强化的堡垒服务器。该方法也可用于防止用户通过网络直接访问 API 服务器。
了解并保护 API 服务器代理功能。
Kubernetes 具有一个内置的堡垒服务器（在 API 服务器内），它代理对集群上运行的服务的访问。通过 URL 方案可以访问服务，例如 http://kubernetes_master_address/api/v1/namespaces/namespace-name/services/service-name[:port_name]/proxy 例如，如果在集群中运行 elasticsearch-logging 服务，它可以通过 URL 方案 https://ClusterIPorDomain/api/v1/namespaces/kube-system/services/elasti… 访问
此功能的主要目的是允许访问可能无法从外部网络直接访问的内部服务。尽管此功能可能对管理目的有用，但恶意用户也可以访问内部服务，否则这些服务可能无法通过分配的角色获得授权。如果您希望允许对 API 服务器进行管理访问，但希望阻止对内部服务的访问，请使用 HTTP 代理或 WAF 来阻止对这些端点的请求。
使用 HTTP 代理、负载平衡器和网络防火墙。
添加一个简单的 HTTP 代理服务器（例如，使用 Nginx 代理）可以帮助在 Kubernetes API 前快速应用 URL 和安全规则。为了获得最终的安全性，请在 Kubernetes API 服务器前投资负载均衡器（例如 AWS ELB、Google Cloud Load Balancer）和网络防火墙，以控制对 Kubernetes API 服务器的直接访问。
原文：https://goteleport.com/blog/kubernetes-api-access-security/