23、Kubernetes 授权与管理全解析

Kubernetes 授权与管理全解析

1. 授权模块概述

授权模块负责决定是否授予访问权限，它们依据明确的策略来判断是否允许访问，若未明确定义策略，所有请求将被隐式拒绝。自 1.15 版本起，Kubernetes 自带以下授权模块：
- 基于属性的访问控制（ABAC） ：可通过本地文件配置授权策略。
- 基于角色的访问控制（RBAC） ：可通过 Kubernetes API 配置授权策略。
- Webhook ：允许通过远程 REST 端点处理请求的授权。
- Node ：专门用于授权来自 kubelet 的请求。

这些模块由集群管理员通过 API 服务器上的 --authorization - mode 标志进行配置，可配置多个模块，且按顺序检查。与准入控制器不同的是，只要有一个授权模块允许请求，请求即可继续；只有当所有模块都拒绝请求时，才会向用户返回错误。

2. ABAC 授权模块

2.1 策略定义示例

以下是一个使用 ABAC 授权模块的策略定义示例，它授予用户 Mary 对 kube - system 命名空间中 Pod 的只读访问权限：

apiVersion: abac.authorization.kubernetes.io/v1beta1
kind: Policy
spec:
  user: mary
  resource: pods
  readonly: true
  namespace: kube - system

若 Mary 发起以下请求，将会被拒绝，因为她没有访问 demo - app 命名空间中 Pod 的权限：

apiVersion: authorization.k8s.io/v1beta1
kind: SubjectAccessReview
spec:
  resourceAttributes:
    verb: get
    resource: pods
    namespace: demo - app

2.2 相关 API 及操作

引入了新的 API 组 authorization.k8s.io ，该组 API 向外部服务公开 API 服务器授权，包含以下对调试很有用的 API：
- SelfSubjectAccessReview ：用于当前用户的访问审查。
- SubjectAccessReview ：类似于 SelfSubjectAccessReview，但适用于任何用户。
- LocalSubjectAccessReview ：类似于 SubjectAccessReview，但特定于命名空间。
- SelfSubjectRulesReview ：返回用户在给定命名空间中可执行的操作列表。

可以像通常创建资源一样查询这些 API，例如使用 SelfSubjectAccessReview 进行测试：

$ cat << EOF | kubectl create -f - -o yaml
apiVersion: authorization.k8s.io/v1beta1
kind: SelfSubjectAccessReview
spec:
  resourceAttributes:
    verb: get
    resource: pods
    namespace: demo - app
EOF

输出如下：

apiVersion: authorization.k8s.io/v1beta1
kind: SelfSubjectAccessReview
metadata:
  creationTimestamp: null
spec:
  resourceAttributes:
    namespace: kube - system
    resource: pods
    verb: get
status:
  allowed: true

实际上，Kubernetes 在 kubectl 中内置了工具，使操作更简单。 kubectl auth can - i 命令通过查询相同的 API 来工作：

$ kubectl auth can - i get pods --namespace demo - app
yes

使用管理员凭据，还可以以其他用户身份运行相同的命令进行检查：

$ kubectl auth can - i get pods --namespace demo - app --as mary
yes

3. RBAC 授权模块

Kubernetes 的基于角色的访问控制（RBAC）在权限管理方面有重要应用，其主要组件包括角色（roles）、规则（rules）、主体（subjects）和角色绑定（RoleBinding）。以下是 RBAC 的一些关键信息：
| 组件 | 描述 |
| ---- | ---- |
| 角色（roles） | 定义一组权限规则 |
| 规则（rules） | 具体规定了允许的操作和资源 |
| 主体（subjects） | 可以是用户、组或服务账户 |
| 角色绑定（RoleBinding） | 将角色与主体关联起来 |

3.1 RBAC 最佳实践

• 明确角色定义 ：根据不同的职责和需求，精确地定义角色，避免角色权限过大或过小。
• 最小权限原则 ：为每个主体分配执行其任务所需的最小权限集合，降低安全风险。
• 定期审查和更新 ：随着系统的变化和业务需求的调整，定期审查和更新 RBAC 配置。

4. Webhook 授权模块

使用 Webhook 授权模块，集群管理员可以配置一个外部 REST 端点来委托授权过程。该端点应在集群外可通过 URL 访问，其配置信息存储在主文件系统的文件中，并通过 API 服务器上的 --authorization - webhook - config - file = SOME_FILENAME 进行配置。配置完成后，API 服务器会将 SubjectAccessReview 对象作为请求体的一部分发送到授权 Webhook 应用程序，该应用程序处理后返回包含完整状态字段的对象。

5. 授权最佳实践

5.1 避免使用 ABAC 和 Webhook

• ABAC ：由于 ABAC 策略需要放置在每个主节点的文件系统上并保持同步，因此不建议在多主集群中使用。此外，对这些策略文件的更改需要重启 API 服务器才能生效，这在单主集群中可能导致控制平面中断，在多主集群中可能导致配置不一致。
• Webhook ：虽然 Webhook 模块功能强大，但潜在风险很大。由于每个请求都要经过授权过程，Webhook 服务的故障可能会对集群造成毁灭性影响。因此，除非完全评估并能接受 Webhook 服务不可用或无法访问时的集群故障模式，否则一般不建议使用外部授权模块。

5.2 推荐使用 RBAC

推荐仅使用 RBAC 模块进行用户授权，因为其规则在 Kubernetes 内部进行配置和存储，避免了上述 ABAC 和 Webhook 模块的问题。

6. 授权流程 mermaid 图

graph LR
    A[请求发起] --> B{授权模块检查}
    B --> C{ABAC 模块}
    B --> D{RBAC 模块}
    B --> E{Webhook 模块}
    B --> F{Node 模块}
    C --> G{是否允许}
    D --> G
    E --> G
    F --> G
    G --> H{有模块允许?}
    H -- 是 --> I[请求继续]
    H -- 否 --> J[返回错误]

7. 总结

在进行集群授权模块配置更改之前，应充分考虑上述最佳实践，选择最合适的授权配置，以定制集群所需的控制和策略。同时，理解 Kubernetes 的模块化和通用性，掌握其 API 和组件的工作原理，对于成功应用 Kubernetes 至关重要。无论是应用开发、管理还是部署，合理的授权和管理策略都能让 Kubernetes 发挥出最大的效能。

8. Kubernetes 其他管理要点

8.1 资源管理

资源管理在 Kubernetes 中至关重要，涉及到多个方面：
- 命名空间 ：可用于资源管理，通过设置 ResourceQuotas 可以限制命名空间内的资源使用。操作步骤如下：
1. 创建命名空间：

kubectl create namespace my - namespace

2. 设置 `ResourceQuotas`：

apiVersion: v1
kind: ResourceQuota
metadata:
  name: my - quota
  namespace: my - namespace
spec:
  hard:
    pods: "10"
    requests.cpu: "1"
    requests.memory: 1Gi
    limits.cpu: "2"
    limits.memory: 2Gi

3. 应用配置：

kubectl apply -f quota.yaml -n my - namespace

• Pod 资源管理 ：Pod 的资源管理包括资源请求和限制，以及服务质量（QoS）的设置。Pod 的 QoS 分为以下三种：
  | QoS 类型 | 描述 |
  | ---- | ---- |
  | Guaranteed | 为 Pod 分配固定的资源，保证资源的可用性 |
  | Burstable | Pod 可以使用超出请求的资源，但有一定的限制 |
  | BestEffort | 不保证资源的可用性，Pod 可以使用空闲资源 |

8.2 网络管理

Kubernetes 的网络管理遵循一定的原则，并且有多种网络插件可供选择：
- 网络原则 ：Kubernetes 网络要求每个 Pod 都有自己的 IP 地址，并且 Pod 之间可以直接通信。
- 网络插件 ：常见的网络插件有 Kubenet 和 CNI 插件。以下是 Kubenet 的配置步骤：
1. 安装 Kubenet ：

kubectl apply -f https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube - flannel.yml

2. 验证安装：

kubectl get pods - n kube - system | grep flannel

8.3 存储管理

存储管理涉及到持久卷（PersistentVolume）和持久卷声明（PersistentVolumeClaim）的使用：
- 持久卷（PersistentVolume） ：是集群中的存储资源，独立于 Pod 的生命周期。创建持久卷的示例：

apiVersion: v1
kind: PersistentVolume
metadata:
  name: my - pv
spec:
  capacity:
    storage: 10Gi
  accessModes:
    - ReadWriteOnce
  hostPath:
    path: "/data/my - pv"

• 持久卷声明（PersistentVolumeClaim） ：是 Pod 对存储资源的请求。创建持久卷声明的示例：

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: my - pvc
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 5Gi

9. 开发与部署管理

9.1 开发集群搭建

搭建开发集群的目标是为开发者提供一个高效的开发环境，具体步骤如下：
1. 确定目标 ：明确开发集群的功能和性能要求。
2. 选择合适的工具 ：如 kubectl 等。
3. 创建集群 ：可以使用云服务提供商的 Kubernetes 服务，也可以使用本地工具如 Minikube 。
4. 配置环境 ：设置 kubectl 与集群的连接。

9.2 CI/CD 管道

CI/CD 管道可以实现应用的自动化构建、测试和部署，以下是 CI/CD 管道的主要步骤：
| 步骤 | 描述 |
| ---- | ---- |
| 持续集成（CI） | 代码提交后自动进行编译、测试等操作 |
| 持续部署（CD） | 将通过测试的代码部署到生产环境 |

9.3 部署策略

常见的部署策略有滚动更新、蓝绿部署和金丝雀部署：
- 滚动更新 ：逐步替换旧版本的 Pod 为新版本，保证服务的连续性。
- 蓝绿部署 ：同时维护两个环境，一个是旧版本，一个是新版本，通过切换流量来实现部署。
- 金丝雀部署 ：先将新版本部署到一小部分 Pod 上，进行测试和验证，然后逐步扩大范围。

10. 监控与安全管理

10.1 监控

监控是保障 Kubernetes 集群稳定运行的重要手段，常见的监控指标包括 CPU 使用率、内存使用率等。可以使用以下工具进行监控：
- Prometheus ：用于收集和存储监控数据。
- Grafana ：用于可视化监控数据。

10.2 安全管理

安全管理涉及到多个方面，如认证、授权和网络安全：
- 认证 ：可以使用证书、令牌等方式进行认证。
- 授权 ：通过授权模块控制用户的访问权限。
- 网络安全 ：使用 NetworkPolicy API 来控制 Pod 之间的网络通信。

11. 总结与展望

Kubernetes 作为一个强大的容器编排平台，提供了丰富的功能和工具来实现资源管理、网络管理、存储管理等多个方面的需求。在实际应用中，我们需要根据具体的业务需求和场景，选择合适的管理策略和工具。同时，持续关注 Kubernetes 的发展和更新，不断优化和改进我们的管理方案，以确保集群的高效、稳定和安全运行。未来，随着云计算和容器技术的不断发展，Kubernetes 有望在更多的领域得到广泛应用，为企业的数字化转型提供更强大的支持。

graph LR
    A[开发环境] --> B[代码提交]
    B --> C{CI 流程}
    C --> D[编译]
    C --> E[测试]
    D --> F{CD 流程}
    E --> F
    F --> G[部署策略选择]
    G --> H[滚动更新]
    G --> I[蓝绿部署]
    G --> J[金丝雀部署]
    H --> K[生产环境]
    I --> K
    J --> K