第 7 章 配置 MicroShift 身份验证和安全性

1. 将证书和密钥复制到主机操作系统中的首选目录中。确保只有 root 访问权限才能访问这些文件。

2. 通过在 MicroShift /etc/microshift/config.yaml 配置文件中指定证书名称和新的完全限定域名(FQDN)来更新每个自定义 CA 的 MicroShift 配置。

   每个证书配置都可以包含以下值：

   • 证书文件位置是一个必需的值。

   • 包含 API 服务器 DNS 和 IP 地址或 IP 地址范围的一个通用名称。

     提示

     在大多数情况下，MicroShift 为您的自定义 CA 生成新的 kubeconfig 文件，其中包含您指定的 IP 地址或范围。例外是在为 IP 地址指定通配符时。在这种情况下，MicroShift 会生成一个 kubeconfig 文件，其中包含服务器的公共 IP 地址。要使用通配符，您必须使用特定详情更新 kubeconfig 文件。

   • 多个主题备用名称(SAN)，其中包含 API 服务器 DNS 和 IP 地址或通配符证书。
   • 您可以列出每个证书的额外 DNS 名称。
3. MicroShift 服务重启后，您必须将生成的 kubeconfig 文件复制到客户端。

4. 在客户端系统上配置额外的 CA。例如，您可以更新 Red Hat Enterprise Linux (RHEL)信任存储中的 CA 捆绑包。

   重要

   自定义服务器证书必须针对主机操作系统信任根中配置的 CA 数据进行验证。如需更多信息，请参阅以下文档：

   • 系统范围的信任存储

5. 证书和密钥从主机上的指定文件位置读取。您可以从客户端测试和验证配置。

   • 如果任何验证失败，MicroShift 会跳过自定义配置，并使用默认证书启动。优先级是继续服务不间断。MicroShift 在服务启动时记录错误。常见错误包括过期的证书、缺失文件或错误的 IP 地址。
6. 外部服务器证书不会自动续订。您必须手动轮转外部证书。

流程

1. 复制您要添加到 MicroShift 主机的信任根中的自定义证书。确保证书和私钥只能被 MicroShift 访问。

2. 对于您需要的每个自定义 CA，使用以下示例 将名为Certificates 的 apiServer 部分添加到 /etc/microshift/config.yaml MicroShift 配置文件中：

   apiServer:
     namedCertificates:
      - certPath: ~/certs/api_fqdn_1.crt 

   1

   
        keyPath:  ~/certs/api_fqdn_1.key 

   2

   
      - certPath: ~/certs/api_fqdn_2.crt
        keyPath:  ~/certs/api_fqdn_2.key
        names: 

   3

   
        - api_fqdn_1
        - *.apps.external.com

   1

   添加证书的完整路径。

   2

   添加证书密钥的完整路径。

   3

   可选。添加显式 DNS 名称列表。允许前导通配符。如果没有列出名称，则会从证书中提取隐式名称。

3. 运行以下命令重启 MicroShift 以应用证书：

   $ systemctl microshift restart

4. 等待几分钟，让系统重新启动并应用自定义服务器。新的 kubeconfig 文件在 /var/lib/microshift/resources/kubeadmin/ 目录中生成。
5. 将 kubeconfig 文件复制到客户端。如果您为 IP 地址指定了通配符，请更新 kubeconfig 以删除服务器的公共 IP 地址，并使用您要使用的特定通配符范围替换该 IP 地址。

6. 在客户端中，执行以下步骤：

   1. 运行以下命令指定要使用的 kubeconfig ：

      $ export KUBECONFIG=~/custom-kubeconfigs/kubeconfig 

      1

      1

      使用复制的 kubeconfig 文件的位置作为路径。

   2. 使用以下命令检查是否应用了证书：

      $ oc --certificate-authority ~/certs/ca.ca get node

      输出示例

      oc get node
      NAME                             STATUS   ROLES                         AGE   VERSION
      dhcp-1-235-195.arm.example.com   Ready    control-plane,master,worker   76m   v1.32.3

   3. 运行以下命令，将新 CA 文件添加到 $KUBECONFIG 环境变量中：

      $ oc config set clusters.microshift.certificate-authority /tmp/certificate-authority-data-new.crt

   4. 运行以下命令，验证新的 kubeconfig 文件是否包含新的 CA：

      $ oc config view --flatten

      外部生成的 kubeconfig 文件示例

      apiVersion: v1
      clusters:
      - cluster:
          certificate-authority: /tmp/certificate-authority-data-new.crt 

      1

      
          server: https://api.ci-ln-k0gim2b-76ef8.aws-2.ci.openshift.org:6443
        name: ci-ln-k0gim2b-76ef8
      contexts:
      - context:
          cluster: ci-ln-k0gim2b-76ef8
          user:
        name:
      current-context:
      kind: Config
      preferences: {}

      1

      外部生成的 kubeconfig 文件中不存在 certificate-authority-data 部分。它通过之前使用的 oc config set 命令添加。

   5. 运行以下命令，验证自定义 API 服务器证书颁发机构的 主题和签发者 ：

      $ curl --cacert /tmp/caCert.pem https://${fqdn_name}:6443/healthz -v

      输出示例

      Server certificate:
        subject: CN=kas-test-cert_server
        start date: Mar 12 11:39:46 2024 GMT
        expire date: Mar 12 11:39:46 2025 GMT
        subjectAltName: host "dhcp-1-235-3.arm.eng.rdu2.redhat.com" matched cert's "dhcp-1-235-3.arm.eng.rdu2.redhat.com"
        issuer: CN=kas-test-cert_ca
        SSL certificate verify ok.

      重要

      将生成的 kubeconfig 文件中的 certificate-authority-data 替换为新的 rootCA，或者将 certificate-authority-data 添加到操作系统的信任根中。不要同时使用这两种方法。

   6. 在操作系统的信任根中配置额外的 CA。例如，在客户端系统上的 RHEL 客户端信任存储中。系统范围的信任存储。

      • 建议使用包含 CA 的配置更新证书捆绑包。
      • 如果您不想配置证书捆绑包，也可以使用 oc login localhost:8443 --certificate-authority=/path/to/cert.crt 命令，但这不是首选的方法。

流程

1. 在 MicroShift 中，确保证书由 kube-apiserver 提供，并通过运行以下命令来验证证书路径是否已附加到 the -tls-sni-cert-key FLAG 中：

   $ journalctl -u microshift -b0 | grep tls-sni-cert-key

   输出示例

   Jan 24 14:53:00 localhost.localdomain microshift[45313]: kube-apiserver I0124 14:53:00.649099   45313 flags.go:64] FLAG: --tls-sni-cert-key="[/home/eslutsky/dev/certs/server.crt,/home/eslutsky/dev/certs/server.key;/var/lib/microshift/certs/kube-apiserver-external-signer/kube-external-serving/server.crt,/var/lib/microshift/certs/kube-apiserver-external-signer/kube-external-serving/server.key;/var/lib/microshift/certs/kube-apiserver-localhost-signer/kube-apiserver-localhost-serving/server.crt,/var/lib/microshift/certs/kube-apiserver-localhost-signer/kube-apiserver-localhost-serving/server.key;/var/lib/microshift/certs/kube-apiserver-service-network-signer/kube-apiserver-service-network-serving/server.crt,/var/lib/microshift/certs/kube-apiserver-service-network-signer/kube-apiserver-service-network-serving/server.key

2. 在客户端中，运行以下命令来确保 kube-apiserver 提供正确的证书：

   $ openssl s_client -connect <SNI_ADDRESS>:6443 -showcerts | openssl x509 -text -noout -in - | grep -C 1 "Alternative\|CN"

流程

1. 运行以下命令，停止 MicroShift 服务并清理自定义证书：

   $ sudo microshift-cleanup-data --cert

   输出示例

   Stopping MicroShift services
   Removing MicroShift certificates
   MicroShift service was stopped
   Cleanup succeeded

2. 运行以下命令重启 MicroShift 服务以重新创建自定义证书：

   $ sudo systemctl start microshift