Kube API Server中的身份验证与授权 - Ezy Infra

了解 Kubernetes 组件

随着越来越多的 DevOps 工程师转向容器编排，Kubernetes（简称 K8s）已经成为不可或缺的工具。尽管它看起来可能很复杂，但通过了解其架构的基础知识，您可以更轻松地掌握它。

Kubernetes 通过集群运行，集群主要由两个核心组件组成：控制平面（或主节点）和数据平面（工作节点）。数据平面是实际运行应用程序的地方，应用程序以 Pod 的形式运行。接下来，我们将进一步分解这些组件，帮助您更好地理解。

控制平面组件

控制平面组件的主要职责是确保应用程序的当前状态与期望状态相匹配。它们负责对整个集群做出全局决策。

API 服务器（kube-apiserver）

API 服务器是 Kubernetes 集群的核心网关。无论何时与 Kubernetes 交互，都会通过 API 服务器完成。它将高级命令（如 kubectl）转换为 HTTP REST API，处理请求并公开集群的端点。

• 安全通信：API 服务器通过 TLS 加密通信，确保访问安全并防止未经授权的干扰。
• 高效通信：内部使用 gRPC 调用与其他组件交互，保持高效运行。
• 身份验证与授权：API 服务器负责处理身份验证和授权，控制谁可以访问集群以及可以执行哪些操作。

身份验证

Kubernetes API 服务器的身份验证机制遵循最小特权原则，确保用户仅能访问必要的资源。以下是三种主要的身份验证方法：

1. 客户端证书身份验证

客户端证书身份验证通常用于管理员对用户或开发人员的身份验证。

• 适用场景：适合小型团队，因为需要手动配置和轮换证书。
• 依赖技术：基于 TLS 证书进行身份验证。
• 局限性：手动配置容易出错，且随着团队规模扩大，可能面临可扩展性问题。

以下是客户端证书身份验证的工作流程：

2. 服务帐户身份验证

服务帐户是 Kubernetes 内置的身份验证机制，主要用于 Pods 和其他工作负载。

• 特点：
  • 自动生成 JWT 令牌，简化身份验证流程。
  • 与角色和角色绑定配合使用，管理集群内的访问权限。
• 优势：适用于自托管集群，无需依赖外部 IAM 解决方案。
• 挑战：
  • 如果令牌泄露，可能导致安全风险。
  • 默认情况下，服务帐户令牌不会过期，需要手动轮换以确保安全。

以下是服务帐户身份验证的工作流程：

3. OpenID Connect 身份验证

OpenID Connect（OIDC）身份验证适用于使用第三方身份提供商（如 Google、Azure AD 和 Okta）的企业环境。

• 特点：
  • 提供集中化的访问控制。
  • 通过现有身份系统实现可扩展性。
• 配置步骤：
  1. 使用 Kubernetes RBAC 配置 Google Cloud IAM。
  2. 开发人员通过 Google OAuth2 令牌进行身份验证。
  3. 为集群访问分配 IAM 角色。

以下是配置示例：

apiVersion: v1
kind: Pod
metadata:
  name: kube-apiserver
spec:
  containers:
  - name: kube-apiserver
    args:
    - --oidc-issuer-url=https://accounts.google.com
    - --oidc-client-id=my-client-id
    - --oidc-ca-file=/etc/kubernetes/pki/oidc-ca.crt
    - --oidc-username-claim=email
    - --authorization-mode=RBAC

授权

授权是指确定特定用户或服务是否被允许在特定资源上执行某些操作。Kubernetes 提供了两种主要的授权机制：

1. RBAC（基于角色的访问控制）

RBAC 是 Kubernetes 中最常用的授权方法，通过角色和角色绑定来定义权限。

• 示例配置：

角色定义（Role）：

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: default
  name: pod-reader
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "list"]

角色绑定（RoleBinding）：

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: read-pods
  namespace: default
subjects:
- kind: ServiceAccount
  name: user-service-account
  namespace: default
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

上述配置允许用户服务帐户以 Pod 阅读器角色访问 Pods。

2. ABAC（基于属性的访问控制）

ABAC 基于用户身份、命名空间、资源类型等属性授予访问权限。

• 特点：通过策略文件定义访问规则。
• 挑战：策略文件的创建和维护较为复杂。

示例策略文件：

{
  "apiVersion": "abac.authorization.k8s.io/v1",
  "kind": "Policy",
  "spec": {
    "user": "user1",
    "namespace": "default",
    "resource": "pods",
    "verb": "get"
  }
}

结论

Kubernetes API 服务器通过身份验证和授权机制，为集群提供了安全的访问控制。身份验证方法包括客户端证书、服务帐户和 OIDC，而授权机制则主要依赖 RBAC 和 ABAC。通过这些机制，Kubernetes 能够有效地管理用户权限，确保集群的安全性和稳定性。

原文链接: https://ezyinfra.dev/blog/auth-in-kube-apiserver