4.2. 配置自定义证书颁发机构


要使用自定义证书颁发机构(CA)配置外部生成的证书和域名,请将它们添加到 MicroShift /etc/microshift/config.yaml 配置文件中。您还必须配置主机操作系统信任 root。

注意

外部生成的 kubeconfig 文件在 /var/lib/microshift/resources/kubeadmin/<hostname>/kubeconfig 目录中创建。如果您需要在外部生成的配置之外使用 localhost,请在其默认位置保留原始 kubeconfig 文件。localhost kubeconfig 文件使用自签名证书颁发机构。

先决条件

  • 已安装 OpenShift CLI (oc)。
  • 您可以使用具有集群管理角色的用户访问集群。
  • 证书颁发机构已发布自定义证书。
  • MicroShift /etc/microshift/config.yaml 配置文件存在。

流程

  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-service} 以应用证书:

    $ 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.30.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 命令,但这不是首选的方法。
Red Hat logoGithubRedditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

通过我们的产品和服务,以及可以信赖的内容,帮助红帽用户创新并实现他们的目标。

让开源更具包容性

红帽致力于替换我们的代码、文档和 Web 属性中存在问题的语言。欲了解更多详情,请参阅红帽博客.

關於紅帽

我们提供强化的解决方案,使企业能够更轻松地跨平台和环境(从核心数据中心到网络边缘)工作。

© 2024 Red Hat, Inc.