配置

流程

1. 可选： 您可以显示 config.yaml 的内容。运行以下命令:

   $ cat /etc/microshift/config.yaml

2. 可选： 您可以显示远程访问 kubeconfig 文件的内容。运行以下命令:

   $ cat /var/lib/microshift/resources/kubeadmin/<hostname>/kubeconfig

   重要

   其他远程访问 kubeconfig 文件必须包含 MicroShift config.yaml 文件中列出的服务器名称之一。其他 kubeconfig 文件还必须使用相同的 CA 进行验证。

3. 要为额外的 DNS 名称 SAN 或外部 IP 地址生成额外的 kubeconfig 文件，请将您需要的条目添加到 apiServer.subjectAltNames 字段。在以下示例中，所用的 DNS 名称为 alt-name-1，IP 地址为 1.2.3.4。

   带有额外身份验证值的 config.yaml 示例

   dns:
     baseDomain: example.com
   node:
     hostnameOverride: "microshift-rhel9" 1
     nodeIP: 10.0.0.1
   apiServer:
     subjectAltNames:
     - alt-name-1 2
     - 1.2.3.4 3

   1

   主机名

   2

   DNS 名称

   3

   IP 地址或范围

4. 运行以下命令，重启 MicroShift 以应用配置更改并自动生成您需要的 kubeconfig 文件：

   $ sudo systemctl restart microshift

5. 要检查额外的远程访问 kubeconfig 文件的内容，请将 config.yaml 中列出的名称或 IP 地址插入到 cat 命令中。例如，以下示例命令中使用 alt-name-1 ：

   $ cat /var/lib/microshift/resources/kubeadmin/alt-name-1/kubeconfig

6. 选择 kubeconfig 文件，以使用其中包含您要用于连接集群的 SAN 或 IP 地址。在本例中，在 cluster.server 字段中包含'alt-name-1' 的 kubeconfig 是正确的文件。

   其他 kubeconfig 文件的内容示例

   clusters:
   - cluster:
       certificate-authority-data: <base64 CA>
       server: https://alt-name-1:6443 1

   1

   /var/lib/microshift/resources/kubeadmin/alt-name-1/kubeconfig 文件值来自 apiServer.subjectAltNames 配置值。

1. 将证书和密钥复制到主机操作系统中首选目录中。确保仅可由 root 访问这些文件。

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

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

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

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

     提示

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

   • 包含 API 服务器 DNS 和 IP 地址或通配符证书的多个主题备用名称(SAN)。
   • 您可以为每个证书提供额外的 DNS 名称。
3. MicroShift 服务重启后，您必须将生成的 kubeconfig 文件复制到客户端。
4. 在客户端系统上配置其他 CA。例如，您可以在 Red Hat Enterprise Linux (RHEL)信任存储中更新 CA 捆绑包。
5. 证书和密钥从主机上的指定文件位置读取。配置的测试和验证是从客户端进行的。
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-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.29.2

   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 添加到操作系统的信任 root 中。不要同时使用这两种方法。

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

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

流程

1. 在 MicroShift 中，通过运行以下命令，确保 kube-apiserver 提供证书，并验证证书路径是否已附加到 --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

1. 敏感资源（如 Secret、Route 和 OAuthClient 对象）仅在元数据级别上记录。

流程

1. 在 /etc/microshift/ 目录中复制提供的 config.yaml.default 文件，将它重命名为 config.yaml。将您创建的新 MicroShift config.yaml 保留在 /etc/microshift/ 目录中。每当 MicroShift 服务启动时都会读取新的 config.yaml。创建后，config.yaml 文件优先于内置设置。

2. 将 YAML 的 auditLog 部分中的默认值替换为您需要的有效值。

   默认 auditLog 配置示例

   apiServer:
   # ....
     auditLog:
       maxFileAge: 7 1
       maxFileSize: 200 2
       maxFiles: 1 3
       profile: Default 4
   # ....

   1

   指定日志文件保留的最长时间（以天为单位）。超过这个限制的文件会被删除。在本例中，日志文件超过 7 天后，它将被删除。无论 live 日志是否已达到 maxFileSize 字段中指定的最大文件大小，文件都会被删除。文件年龄由轮转日志文件名称写入的时间戳决定，例如 audit-2024-05-16T17-03-59.994.log。当值为 0 时，会禁用限制。

   2

   以 MB 为单位的最大审计日志文件大小。在本例中，当实时日志达到 200 MB 限制时，该文件就会立即轮转。当值设为 0 时，会禁用限制。

   3

   轮转审计日志文件的最大数量。达到限制后，日志文件将从最旧的到最新的顺序删除。在这个示例中，除了当前活跃的日志外，值 1 只会保留 1 个大小 maxFileSize 的文件。当值设为 0 时，会禁用限制。

   4

   仅记录读取和写入请求的日志元数据 ；除了 OAuth 访问令牌请求外，不记录请求正文。如果没有指定此字段，则使用 Default 配置集。

3. 可选： 要为日志指定新目录，您可以停止 MicroShift，然后将 /var/log/kube-apiserver 目录移到所需位置：

   1. 运行以下命令来停止 MicroShift：

      $ sudo systemctl stop microshift

   2. 运行以下命令，将 /var/log/kube-apiserver 目录移到所需的位置：

      $ sudo mv /var/log/kube-apiserver <~/kube-apiserver> 1

      1

      将 < ~/kube-apiserver > 替换为您要使用的目录的路径。

   3. 如果您为日志指定了新目录，请运行以下命令在 /var/log/kube-apiserver 上创建一个指向自定义目录的符号链接：

      $ sudo ln -s <~/kube-apiserver> /var/log/kube-apiserver 1

      1

      将 < ~/kube-apiserver > 替换为您要使用的目录的路径。这会在 sos 报告中启用日志集合。

4. 如果要在正在运行的实例中配置审计日志策略，请输入以下命令重启 MicroShift：

   $ sudo systemctl restart microsohift