k8s学习第19天--证书认证

k8s的认证机制

Kubernetes (k8s) 提供了多种用于认证管理的机制，这些机制可以确保只有经过授权的用户和服务能够访问Kubernetes集群。

以下是Kubernetes中常用的一些认证管理机制：

1. 证书认证：通过使用X.509证书来进行身份验证和授权。Kubernetes集群必须配置CA证书颁发机构，以便在证书过期之前对颁发的证书进行撤销并更新。

2. Token认证：在Kubernetes API服务器上创建一个持久令牌，该令牌可用于访问API服务器。每个Token都有一组绑定到它上面的权限，从而可以限制对资源的访问。

3. OpenID Connect（OIDC）认证：支持使用OpenID Connect作为身份验证协议。OIDC是建立在OAuth2协议之上的标准化协议，用于处理用户身份验证和授权操作。

4. Webhook认证：Kubernetes API服务器允许开发人员编写Webhook插件，以执行自定义逻辑来检查用户请求中的身份验证令牌或证书是否有效。

5. Service Account认证：用于自动化流程中的应用程序和容器，使它们能够与Kubernetes API交互。Service Account会分配给特定的命名空间，并与一组RBAC规则相关联，以限制其对资源的访问。

这些认证管理机制可以与Kubernetes的授权管理机制一起使用，以实现更强大和安全的访问控制。

证书认证

在 Kubernetes 中，证书认证是一种常见的身份验证机制。它基于 X.509 证书进行身份验证和授权。

Kubernetes 证书

Kubernetes 集群中使用的主要证书包括：

• CA 证书：签发其它证书的根证书。
• API Server 证书：用于保护 Kubernetes API Server。
• Service Account 证书：用于在 Kubernetes (k8s) 内部进行自动化流程的应用程序和容器。

Kubernetes 证书颁发机构

Kubernetes 集群必须配置一个 CA 证书颁发机构 (CA Issuer)，以便向集群中的用户和服务颁发证书。

CA 证书颁发机构可以是 Kubernetes 的内置机制，也可以是外部证书颁发机构。当 Kubernetes 集群需要向一个新用户或服务颁发证书时，它会使用 CA 证书颁发机构来签署该证书。

Kubernetes 身份验证过程

1. 用户通过 kubectl 或者其它客户端工具向 Kubernetes API Server 发出请求。
2. Kubernetes API Server 验证请求中的证书签名是否有效，并检查该证书是否为受信任的 CA 签发的。
3. 如果证书验证通过，则 Kubernetes API Server 将确定该用户是否有足够的权限执行该请求。如果没有足够的权限，则请求将被拒绝。

Kubernetes 证书管理

为了确保 Kubernetes 集群的安全性，必须定期对证书进行管理。证书管理包括以下操作：

• 颁发新的证书。
• 撤销过期或者失效的证书。
• 更新 CA 证书。

在 Kubernetes 中，可以使用一些工具来管理证书，如 cfssl、cert-manager 等。

证书认证配置

在 Kubernetes 中，配置证书认证需要以下步骤：

1. 配置 CA 证书颁发机构 (CA Issuer)。可以使用 Kubernetes 内置的 kubeadm 工具来配置 CA 证书颁发机构。

2. 配置 API Server 证书。可以使用 Kubernetes 内置的 kubeadm 工具来生成 API Server 证书，并将其复制到正确的位置。

3. 配置 Service Account 证书。Service Account 证书是自动生成的，可以在容器中作为一个 secret 进行挂载。

4. 配置 kubectl，以便使用证书进行身份验证。可以使用 kubectl config set-credentials 命令来配置 kubectl 的证书。

下面是更详细的配置步骤：

步骤1. 配置 CA 证书颁发机构

可以使用 kubeadm 工具来初始化 Kubernetes 集群并配置 CA 证书颁发机构：

sudo kubeadm init --pod-network-cidr=10.244.0.0/16

此命令将初始化 Kubernetes 集群，并使用默认的 kubeadm-certs 证书颁发机构来颁发证书。

步骤2. 配置 API Server 证书

可以使用 kubeadm 工具来生成 API Server 证书：

sudo kubeadm init phase certs apiserver --apiserver-advertise-address=${MASTER_IP} --apiserver-cert-extra-sans=${MASTER_IP}

此命令将生成 API Server 证书，并将其保存到 /etc/kubernetes/pki/apiserver.crt 和 /etc/kubernetes/pki/apiserver.key 文件中。

步骤3. 配置 Service Account 证书

Service Account 证书是自动生成的，可以在容器中作为一个 secret 进行挂载：

kubectl create sa my-service-account kubectl get sa my-service-account -o yaml

此命令将创建一个名为 my-service-account 的 Service Account，并返回其 secret 名称。

然后可以将该 secret 挂载到容器中：

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  serviceAccountName: my-service-account
  containers:
  - name: my-container
    image: nginx
    volumeMounts:
    - name: my-service-account-token
      mountPath: /var/run/secrets/kubernetes.io/serviceaccount
      readOnly: true
  volumes:
  - name: my-service-account-token
    secret:
      secretName: my-service-account-token-dz6f5

此 YAML 文件将创建一个名为 my-pod 的 Pod，其中的 serviceAccountName 字段指定了使用的 Service Account。然后将该 secret 挂载到 /var/run/secrets/kubernetes.io/serviceaccount 目录下。

步骤4. 配置 kubectl 的证书

可以使用以下命令来配置 kubectl 的证书：

kubectl config set-credentials my-user --client-certificate=/path/to/client.crt --client-key=/path/to/client.key

此命令将创建一个名为 my-user 的 kubectl 用户，并将其证书和私钥配置为:/path/to/client.crt 和 /path/to/client.key。在完成了这些步骤之后，就可以使用证书进行身份验证和授权了。

证书认证配置验证

1. 使用 kubectl 命令行工具进行验证。例如，可以使用以下命令获取集群的版本信息：

   kubectl version

   如果证书认证成功，则应该能够看到正确的版本信息。

2. 使用 Kubernetes Dashboard 进行验证。如果已经设置了 Kubernetes Dashboard，则可以通过浏览器访问 Dashboard 页面，并检查是否已显示正确的信息。通常情况下，会要求输入用户名和密码进行身份验证，但是在配置了证书认证之后，就可以直接登录。

3. 检查 kube-apiserver 的日志。可以使用以下命令来查看 kube-apiserver 的日志：

   journalctl -u kube-apiserver -f

   如果证书认证失败，则可能会看到类似以下的错误消息：

   x509: certificate signed by unknown authority

如果以上步骤都没有发现问题，则可以确认证书认证已经成功地配置好了。

如何查看认证管理机制

您可以使用以下命令来查看 Kubernetes 中的认证管理机制：

kubectl config view

此命令将返回一个 YAML 格式的配置文件，其中包含了当前用户、集群和上下文的信息。在该配置文件中，可以查找 user、cluster 和 context 字段，以确定当前所使用的认证管理机制。

例如，在以下示例输出中，可以看到当前所使用的认证管理机制是基于证书认证的：

 kubectl config view
apiVersion: v1
clusters:
- cluster:
    certificate-authority-data: DATA+OMITTED
    server: https://172.16.2.220:6443
  name: kubernetes
contexts:
- context:
    cluster: kubernetes
    user: kubernetes-admin
  name: kubernetes-admin@kubernetes
current-context: kubernetes-admin@kubernetes
kind: Config
preferences: {}
users:
- name: kubernetes-admin
  user:
    client-certificate-data: DATA+OMITTED
    client-key-data: DATA+OMITTED

• users: 该字段列出了当前配置文件中定义的所有用户。如果您使用的是基于证书认证的机制，则可以在这里找到相关的证书信息。

• clusters: 该字段列出了当前配置文件中定义的所有集群。如果您使用的是基于证书认证的机制，则可以在这里找到 CA 根证书以及 API Server 地址等信息。

• contexts: 该字段列出了当前配置文件中定义的所有上下文（context）。每个上下文都包含了一个 cluster 和一个 user，用于指定当前所连接的 Kubernetes 集群和使用的用户。如果您使用的是基于证书认证的机制，则可以在这里确定当前使用的证书。

在实际操作中，最常用的是 users 和 contexts 字段。可以通过查看这两个字段来确定当前所使用的认证管理机制。

client-certificate-data 字段通常用于指定客户端证书的数据。为了防止敏感信息泄露，Kubernetes 会将证书数据通过 BASE64 进行编码，并在输出时使用 DATA+OMITTED 进行替换。

因此，当您在查看 Kubernetes 配置文件时，如果看到 client-certificate-data 等字段值为 DATA+OMITTED，则表示该证书数据已经被隐藏起来，无法直接查看。如果需要查看实际的证书数据，可以将该字段值复制到文本编辑器中，并使用 BASE64 解码工具进行解码。

如果您需要查看 Kubernetes 中实际的证书数据，可以使用以下命令来解码 BASE64 编码的数据：

echo "<DATA+OMITTED>" | base64 --decode

在上面的命令中，将 <DATA+OMITTED> 替换为您要查看的具体证书数据（即 kubectl config view 命令输出中的 client-certificate-data 字段值），然后将该命令执行在终端中。

例如，如果要查看名为 john-doe 的用户的客户端证书数据，可以运行以下命令：

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

此命令将返回一个解码后的 PEM 格式证书数据。