K8s-Day9

1. Kubernetes可以为用户创建普通账号吗？比如为研发创建一个单独的账号，只能操作某个命名空间。有哪些方式可以实现

Kubernetes 支持为用户创建普通账号，例如为研发人员创建一个只能操作特定命名空间的账号。这主要通过 Kubernetes 的 RBAC（基于角色的访问控制） 机制来实现。以下是具体的实现方式：

1. 创建普通用户的认证信息

Kubernetes 不直接管理用户账号，而是依赖外部的认证系统（如证书、OAuth2、OpenID Connect、Bearer Token 等）。以下是常见的几种方法：

a. 使用客户端证书认证

这是最常见的方式之一，适合内部使用或开发环境。

步骤：

1. 生成用户证书
   使用 openssl 或其他工具生成一个客户端证书和私钥。

2. 将证书提交到集群 用户可以通过配置 kubeconfig 文件来使用该证书访问 Kubernetes 集群。

3. 绑定 RBAC 权限 通过 RoleBinding 或 ClusterRoleBinding 绑定权限。

b. 使用 OAuth2/OpenID Connect

适用于企业级身份验证系统，比如集成 LDAP、Google、GitHub 等。

2. 使用 RBAC 授权用户权限

RBAC 是 Kubernetes 中的核心授权机制，可以精确控制用户对资源的访问权限。

a. 创建 Role（角色）

定义某个命名空间内的权限规则。

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: dev-role
  namespace: dev-namespace
rules:
- apiGroups: [""]
  resources: ["pods", "services", "deployments"]
  verbs: ["get", "list", "watch", "create", "update", "delete"]

b. 创建 RoleBinding（绑定角色到用户）

将 Role 绑定到具体用户或 ServiceAccount。

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: dev-rolebinding
  namespace: dev-namespace
subjects:
- kind: User
  name: dev-user
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: dev-role
  apiGroup: rbac.authorization.k8s.io

c. 如果需要跨命名空间权限，使用 ClusterRole 和 ClusterRoleBinding

ClusterRole 定义的是集群范围内的权限，而 ClusterRoleBinding 可以将权限绑定到整个集群中的用户或 ServiceAccount。

2. Bearer Token是什么，可以实现第一题中的要求吗

earer Token 是 Kubernetes 中用于身份验证的一种机制，它是一种简单的字符串令牌（token），客户端在请求 API 时将其附加到 HTTP 请求头中以证明自己的身份。Kubernetes 使用这种 Token 来识别用户或服务账户的身份，并结合 RBAC（基于角色的访问控制）来决定该身份可以执行哪些操作。

Bearer Token 的基本原理

1. Token 的生成

   • 对于 ServiceAccount，Kubernetes 自动为其生成一个 Token，存储在 Secret 资源中。

   • 对于普通用户，如果使用外部认证系统（如 OAuth2、OpenID Connect 等），Token 通常由这些系统生成。

2. Token 的使用

   1. 用户通过 kubectl 或其他工具发送请求时，将 Token 添加到请求头中：

      Authorization: Bearer <token>

      • Kubernetes API Server 接收到请求后，会验证 Token 的有效性，并解析出对应的用户身份。

   2. RBAC 授权

      • 根据解析出的用户身份，Kubernetes 会查找与之绑定的 Role/ClusterRole，判断其是否有权限执行当前操作。

是的，Bearer Token 完全可以实现第一题中“为研发创建一个只能操作某个命名空间”的需求。
使用 Bearer Token 认证

适用于临时用户或者服务账户。

apiVersion: v1
kind: ServiceAccount
metadata:
  name: dev-user
  namespace: dev-namespace

步骤：

创建 ServiceAccount

apiVersion: v1
kind: ServiceAccount
metadata:
  name: dev-user
  namespace: dev-namespace

获取 Token Kubernetes 会自动生成一个 Token，存储在 Secret 中：

kubectl get secret <serviceaccount-secret-name> -o jsonpath='{.data.token}' | base64 --decode

配置 kubeconfig 文件 将 Token 添加到 kubeconfig 文件中，以便用户访问集群。

3. X.509证书是什么，有哪些使用场景。

X.509证书是什么？

X.509 是一种公钥基础设施（PKI）中的标准格式，用于定义数字证书的结构和用途。它主要用于验证某个实体（如用户、服务器、设备等）的身份，并通过加密技术确保通信的安全性。

X.509 证书通常包含以下关键信息：

• 主体（Subject）：证书持有者的身份信息（例如域名、组织名称、IP地址等）。

• 颁发者（Issuer）：签发该证书的证书颁发机构（CA）。

• 公钥（Public Key）：与私钥配对使用的公钥，用于加密或验证签名。

• 有效期（Validity Period）：证书的有效起始时间和过期时间。

• 签名算法（Signature Algorithm）：证书使用哪种算法进行签名。

• 数字签名（Digital Signature）：由 CA 对证书内容进行签名，确保其真实性。

X.509证书的主要使用场景

1. HTTPS 网站安全通信

• 作用：确保浏览器与网站之间的通信是加密的，防止中间人攻击（MITM）。

• 实现方式：网站部署 SSL/TLS 证书（基于 X.509 标准），浏览器验证证书后建立加密连接。

• 典型应用：

  • 电商网站

  • 银行/金融类网站

  • 企业门户

2. 客户端身份认证（mTLS）

• 作用：不仅服务器向客户端证明自己的身份，客户端也必须提供证书以供服务器验证。

• 实现方式：双向 TLS（Mutual TLS）通信，双方都使用 X.509 证书进行身份认证。

• 典型应用：

  • Kubernetes 中的 API 访问控制

  • 微服务间的通信（如 Istio、Linkerd）

  • IoT 设备接入认证

3. Kubernetes 用户身份认证

• 作用：Kubernetes 支持使用 X.509 客户端证书来识别用户身份。

• 实现方式：

  • 用户生成自己的证书并提交给集群管理员；

  • 管理员配置 kubeconfig 文件，将证书作为身份凭证；

  • Kubernetes API Server 使用内置的证书验证机制确认用户身份；

• 结合 RBAC：可以为不同证书绑定不同权限，实现细粒度访问控制。

4. 代码签名

• 作用：开发者使用 X.509 证书对其发布的软件或脚本进行签名，确保其来源可信且未被篡改。

• 典型应用：

  • Windows 应用程序签名

  • PowerShell 脚本签名

  • iOS 和 Android 应用签名

5. 电子邮件加密与签名

• 作用：使用 S/MIME 协议，基于 X.509 证书对电子邮件进行加密和签名，确保邮件内容的机密性和完整性。

• 典型应用：

  • 企业内部邮件系统

  • 法律文件传输

  • 医疗健康数据交换

6. 物联网（IoT）设备认证

• 作用：每个 IoT 设备拥有唯一的 X.509 证书，用于在连接云平台时进行身份认证。

• 优势：

  • 每个设备具有唯一身份标识；

  • 可防止非法设备接入；

  • 支持大规模设备管理。

• 典型应用：

  • 智能家居设备

  • 工业传感器

  • 远程监控设备

7. API 网关与微服务安全通信

• 作用：在 API 网关和服务之间使用 X.509 证书进行双向认证，确保只有合法服务才能访问敏感接口。

• 典型应用：

  • 金融行业 API 接口

  • 多租户 SaaS 架构

  • 内部服务间通信

8. 容器镜像签名

• 作用：使用 X.509 证书对容器镜像进行签名，确保镜像来源可信且未被篡改。

• 典型应用：

  • Docker Content Trust

  • Kubernetes PodSecurityPolicy 验证机制

  • 企业级容器仓库镜像签名

X.509证书的优点

4. k8s中各个组件的交互与x.509证书有关吗？

Kubernetes（k8s）中各个组件之间的交互与 X.509 证书密切相关。X.509 证书在 Kubernetes 中主要用于 身份验证（Authentication）和通信加密（TLS），确保集群组件之间的安全通信，并防止未经授权的访问。

各组件之间如何使用 X.509 证书

1. API Server 与客户端通信

• 客户端：包括 kubectl、Pod 内部服务、外部 API 请求者。

• 认证方式：

  • 使用 Bearer Token；

  • 使用 X.509 客户端证书（双向 TLS 认证）；

• X.509 作用：

  • 用户生成自己的客户端证书并提交给集群管理员；

  • 管理员配置 kubeconfig 文件，将证书作为身份凭证；

  • kube-apiserver 验证证书合法性后确认用户身份；

• 结合 RBAC：可为不同证书绑定不同权限，实现细粒度访问控制。

2. API Server 与 kubelet 通信

• 通信方式：kube-apiserver 通过 HTTPS 与 kubelet 通信。

• 证书用途：

  • kubelet 使用服务器证书（server certificate）供 kube-apiserver 验证其身份；

  • kube-apiserver 使用客户端证书（client certificate）向 kubelet 证明自己；

• 安全性：

  • 所有请求必须通过 HTTPS 加密；

  • 双向 TLS（mTLS）用于加强身份验证；

• 证书路径：

  • 默认位于 /var/lib/kubelet/pki/；

  • 包括 kubelet.crt、kubelet.key 等文件。

3. API Server 与 etcd 通信

• 通信方式：kube-apiserver 通过 HTTPS 与 etcd 通信。

• 证书用途：

  • etcd 提供服务器证书供 kube-apiserver 验证；

  • kube-apiserver 提供客户端证书供 etcd 验证；

• 安全性：

  • 所有数据读写必须通过加密通道；

  • 双向 TLS（mTLS）防止中间人攻击；

• 证书路径：

  • etcd 证书通常位于 /etc/kubernetes/pki/etcd/；

  • kube-apiserver 使用 --etcd-certfile 和 --etcd-keyfile 指定客户端证书。

4. API Server 自身证书

• 用途：

  • kube-apiserver 使用服务器证书（server certificate）供客户端（如 kubectl、kubelet）验证；

• 证书内容：

  • 必须包含 SAN（Subject Alternative Name），包含集群域名（如 kubernetes.default.svc.cluster.local）和 IP 地址（如 10.96.0.1）；

• 证书路径：

  • 通常位于 /etc/kubernetes/pki/apiserver.crt；

5. Controller Manager 与 API Server 通信

• 认证方式：

  • 使用客户端证书（client certificate）或 Bearer Token；

• 证书用途：

  • kube-controller-manager 使用客户端证书向 kube-apiserver 证明身份；

• 最佳实践：

  • 不推荐使用默认的 system:kube-controller-manager 用户；

  • 应为每个 controller manager 创建专用证书。

6. Scheduler 与 API Server 通信

• 认证方式：

  • 使用客户端证书或 Bearer Token；

• 证书用途：

  • kube-scheduler 使用客户端证书向 kube-apiserver 证明身份；

• 最佳实践：

  • 不推荐使用默认的 system:kube-scheduler 用户；

  • 应为 scheduler 创建专用证书。

7. 其他组件通信

• kube-proxy：使用 kubeconfig 文件中的 Token 或证书与 kube-apiserver 通信；

• kube-dns/coredns：通常不直接使用证书，但依赖 kube-apiserver 获取服务发现信息；

• Ingress Controller：如果启用 HTTPS，需要加载证书以终止 TLS 连接；

• Operator / Webhook：通常使用自签名证书进行 TLS 终止和 mTLS 身份验证。

Kubernetes 中证书的签发机制

Kubernetes 使用内置的 kubelet CSR（Certificate Signing Request）机制自动申请和更新证书：

1. kubelet 启动时生成私钥和 CSR 请求；

2. CSR 请求发送到 kube-apiserver；

3. 管理员批准 CSR 请求（或自动批准）；

4. CA 签发证书并返回给 kubelet；

5. kubelet 将证书保存在 /var/lib/kubelet/pki/ 并定期轮换。

5. k8s中各个组件的x.509证书是怎么生成的，签发证书的CA证书是怎么生成的（使用kubeadm安装的情况）

在使用 kubeadm 安装 Kubernetes 集群时，X.509 证书的生成和签发是由 kubeadm 自动完成的。它会创建一个本地 CA（Certificate Authority），并为各个核心组件生成相应的客户端和服务端证书。

一、CA 证书的生成

1. CA 的作用

• CA（Certificate Authority）是集群中所有证书的信任根。

• 所有其他组件的证书都由这个 CA 签发，并被各组件信任。

2. CA 证书路径

默认位于：

/etc/kubernetes/pki/ca.crt
/etc/kubernetes/pki/ca.key

• ca.crt：CA 的公钥证书；

• ca.key：CA 的私钥，用于签署其他证书；

注意：ca.key 是极其敏感的文件，一旦泄露，整个集群的 TLS 信任体系将被破坏。

3. CA 证书是如何生成的？

a. 使用 kubeadm init 初始化时自动生成

当你执行：

kubeadm init

kubeadm 会自动检测 /etc/kubernetes/pki/ 目录是否存在有效的 CA 证书对。如果不存在，则自动生成：

• 使用默认配置生成 10 年有效期的 CA；

• 默认 SAN（Subject Alternative Name）包括：

  • kubernetes.default.svc.cluster.local

  • kubernetes.default.svc

  • kubernetes.default

  • kubernetes

  • localhost

  • 127.0.0.1

  • 10.96.0.1（默认 service IP）

b. 可以手动指定 CA

你也可以通过提供自己的 CA 证书和私钥来控制证书签发流程：

kubeadm init --cert-dir /etc/kubernetes/pki \
             --pod-network-cidr=10.244.0.0/16 \
             --upload-certs \
             --control-plane-endpoint "LOAD_BALANCER_IP:6443"

6. 如果需要为集群更换CA证书，应该怎么操作（只描述步骤）

更换 CA 证书的步骤如下：

1. 备份现有证书和配置

• 备份 /etc/kubernetes/pki/ 目录下的所有证书和私钥；

• 备份 /etc/kubernetes/manifests/ 和 /etc/kubernetes/*.conf 等配置文件；

2. 准备新的 CA 证书和私钥

• 使用 OpenSSL 或企业 PKI 生成新的 CA 证书（ca.crt）和私钥（ca.key）；

• 确保新 CA 的 SAN 包含集群域名（如 kubernetes.default.svc.cluster.local）；

• 将新证书和私钥复制到所有控制平面节点的 /etc/kubernetes/pki/ 目录下；

3. 重新签发各组件证书

使用新 CA 为以下组件重新签发证书：

• kube-apiserver

• kube-apiserver-etcd-client

• etcd server/client

• kubelet client/server（需重新生成 CSR 并批准）

• kube-controller-manager client

• kube-scheduler client

可使用工具如 openssl 或 cfssl 手动生成，确保 SAN 和用途正确。

4. 更新 kubeconfig 文件中的客户端证书

• 更新以下文件中引用旧 CA 的内容：

  • /etc/kubernetes/admin.conf

  • /etc/kubernetes/controller-manager.conf

  • /etc/kubernetes/scheduler.conf

  • /etc/kubernetes/kubelet.conf

5. 重启控制平面组件

重启 kubelet：

systemctl restart kubelet

删除静态 Pod，等待 kubelet 重新加载新证书：

rm /etc/kubernetes/manifests/*.yaml

6. 更新 Worker 节点上的 kubelet 证书

• 在每个 Worker 节点上：

  • 替换 /var/lib/kubelet/pki/kubelet.crt 和 kubelet.key；

  • 重启 kubelet；

  • 确保与 API Server 的 mTLS 连接正常；

7. 更新集群外部访问配置

• 更新 kubectl 用户的 kubeconfig 文件；

• 更新 Ingress 控制器、监控系统（如 Prometheus）、CI/CD 工具等使用的证书或信任链；

8. 验证所有组件通信正常

检查节点状态：

kubectl get nodes

查看 Pod 状态：

kubectl get pods -A

• 测试 API 请求是否正常；

• 检查 etcd 是否正常工作；

• 查看 kubelet 日志是否有 TLS 错误；

journalctl -u kubelet -n 1h

7. kubeconfig 是什么，文件里面都包含哪些内容

kubeconfig 是 Kubernetes 中用于配置客户端访问集群信息的文件，它定义了用户、集群、上下文（Context）等信息，使得 kubectl 或其他 Kubernetes 客户端工具能够正确连接和操作集群。

kubeconfig 文件的基本结构

一个典型的 kubeconfig 文件包含以下 4 类核心内容：

1. clusters

定义 Kubernetes 集群的访问地址、CA 证书（或跳过验证）、集群名称等。

clusters:
- name: my-cluster
  cluster:
    server: https://192.168.0.100:6443
    certificate-authority-data: <base64-encoded-ca-cert>

• server: API Server 的访问地址；

• certificate-authority-data: CA 证书（用于验证服务器身份），也可以使用 insecure-skip-tls-verify: true 跳过验证（不推荐）；

2. users

定义用户身份认证信息，包括：

• 客户端证书（client-certificate-data + client-key-data）

• Bearer Token

• 用户名密码（基本认证，已逐渐淘汰）

users:
- name: admin-user
  user:
    client-certificate-data: <base64-encoded-client-cert>
    client-key-data: <base64-encoded-client-key>

• 使用证书认证时，kube-apiserver 会验证客户端证书是否由信任的 CA 签发；

• 使用 Token 时，格式为：token: <your-bearer-token>；

3. contexts

定义上下文，即哪个用户连接哪个集群、使用哪个命名空间。

contexts:
- name: dev-context
  context:
    cluster: my-cluster
    user: admin-user
    namespace: development

• cluster: 引用 clusters 中定义的集群；

• user: 引用 users 中定义的用户；

• namespace: 设置默认命名空间；

4. current-context

指定当前使用的上下文名称：

current-context: dev-context

• 可通过命令切换上下文：kubectl config use-context <context-name>；

• 支持多集群、多用户管理，适用于开发、测试、生产环境切换；

8. 默认kubeconfig中使用的用户名是什么

在使用 kubeadm 初始化的 Kubernetes 集群中，默认生成的 kubeconfig 文件（如 /etc/kubernetes/admin.conf）使用的用户名是：

kubernetes-admin

这个用户是由集群 CA 签发证书的身份标识，具有管理员权限，通常绑定的是 cluster-admin 角色（ClusterRole），具备对整个集群的完全控制权限。

9. 这个kubeconfig中是否包含用户的证书，如何还原出来

是的，kubeconfig 文件中通常包含用户的证书信息（X.509 客户端证书），尤其是使用 kubeadm 初始化集群时生成的默认 kubeconfig 文件（如 /etc/kubernetes/admin.conf），其中会通过 client-certificate 和 client-key 字段指定用户的身份认证凭据。

一、如何判断 kubeconfig 是否包含用户证书

你可以通过以下命令查看当前 kubeconfig 的内容：

kubectl config view --raw

如果看到 client-certificate 和 client-key 字段，说明该用户配置使用的是 客户端证书认证方式（X.509 证书）。

二、如何从 kubeconfig 中还原出用户证书

方法 1：直接从文件路径提取（适用于本地访问）

如果你有权限访问集群节点上的 kubeconfig 文件和证书路径（如 /etc/kubernetes/admin.conf），可以直接复制证书文件：

# 复制客户端证书
cp /etc/kubernetes/pki/apiserver.crt admin.crt

# 复制私钥
cp /etc/kubernetes/pki/apiserver.key admin.key

这两个文件组合起来就是用户的 X.509 客户端证书对。

方法 2：通过 kubeconfig 内容提取（适用于远程导出）

如果 kubeconfig 文件是以 base64 编码嵌入证书内容的形式存在（例如 ~/.kube/config 中某些云厂商提供的 kubeconfig），可以按以下步骤提取：

步骤 1：查看 kubeconfig 文件中的用户证书内容

kubectl config view --raw -o jsonpath='{.users[?(@.name == "kubernetes-admin")].user.client-certificate-data}'

这将输出一段 Base64 编码的证书内容。

步骤 2：解码并保存为证书文件

kubectl config view --raw -o jsonpath='{.users[?(@.name == "kubernetes-admin")].user.client-certificate-data}' | base64 --decode > admin.crt

步骤 3：同样可提取私钥（如果有）

kubectl config view --raw -o jsonpath='{.users[?(@.name == "kubernetes-admin")].user.client-key-data}' | base64 --decode > admin.key

10. 查看还原出来的证书内容，其用户名和组名是什么

可以使用 openssl 命令查看 X.509 证书的内容，其中会包含 用户名（Common Name, CN） 和 组名（Organization, O） 等信息。

查看证书内容的命令：

openssl x509 -in admin.crt -text -noout

其中：

• admin.crt 是你从 kubeconfig 中还原出来的用户证书文件；

• -text 表示输出可读文本格式；

• -noout 表示不输出原始编码内容，只显示解析后的字段；

11. 如何查看这个组名在集群中绑定的权限

你可以使用 kubectl 命令查看某个 组名（Organization, O） 在 Kubernetes 集群中绑定的权限。通常，这些权限是通过 RoleBinding 或 ClusterRoleBinding 绑定到用户或用户组的。

查看指定组名绑定的 ClusterRole

以组名 system:masters 为例：

kubectl get clusterrolebinding -o wide | grep 'system:masters'

查看具体 ClusterRole 的权限规则

你可以查看绑定的 ClusterRole 的详细权限：

kubectl describe clusterrole cluster-admin

12. 描述创建单独的用户，需要做哪些操作（只描述步骤即可）

要在 Kubernetes 中创建一个单独的用户并为其分配特定权限，需完成以下步骤：

1. 生成用户的私钥和证书签名请求（CSR）
   使用 openssl 生成用户的私钥和 CSR 文件。

2. 由 CA 签发证书
   使用集群的 CA 证书对用户的 CSR 进行签名，生成客户端证书。

3. 创建 kubeconfig 文件
   将签发的客户端证书、CA 证书和 API Server 地址写入 kubeconfig 文件，配置用户身份信息。

4. 在 Kubernetes 中创建 Role 或 ClusterRole
   定义该用户所需的命名空间级或集群级操作权限（如 get, list, watch 等）。

5. 创建 RoleBinding 或 ClusterRoleBinding
   将用户绑定到对应的 Role/ClusterRole，授予其访问权限。

6. 分发 kubeconfig 文件
   将生成的 kubeconfig 文件安全地提供给用户，用于访问集群资源。

7. 验证用户权限
   使用新用户的 kubeconfig 登录集群，测试是否只能执行授权的操作。