配置

流程

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

   $ cat /etc/microshift/config.yaml

   Copy to Clipboard Toggle word wrap

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

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

   Copy to Clipboard Toggle word wrap
   重要

   其他远程访问 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

   Copy to Clipboard Toggle word wrap

   1

   主机名

   2

   DNS 名称

   3

   IP 地址或范围

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

   $ sudo systemctl restart microshift

   Copy to Clipboard Toggle word wrap

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

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

   Copy to Clipboard Toggle word wrap

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

   Copy to Clipboard Toggle word wrap

   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 会生成一个 kubeconfig，其中包含服务器的公共 IP 地址。要使用通配符，您必须使用特定详情更新 kubeconfig 文件。

   • 多个主题备用名称(SAN)，其中包含 API 服务器 DNS 和 IP 地址或通配符证书。
   • 您可以为每个证书提供额外的 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

   Copy to Clipboard Toggle word wrap

   1

   添加证书的完整路径。

   2

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

   3

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

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

   $ systemctl microshift restart

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

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

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

      $ export KUBECONFIG=~/custom-kubeconfigs/kubeconfig 

      1

      Copy to Clipboard Toggle word wrap

      1

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

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

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

      Copy to Clipboard Toggle word wrap

      输出示例

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

      Copy to Clipboard Toggle word wrap

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

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

      Copy to Clipboard Toggle word wrap

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

      $ oc config view --flatten

      Copy to Clipboard Toggle word wrap

      外部生成的 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: {}

      Copy to Clipboard Toggle word wrap

      1

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

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

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

      Copy to Clipboard Toggle word wrap

      输出示例

      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.

      Copy to Clipboard Toggle word wrap

      重要

      将生成的 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

   Copy to Clipboard Toggle word wrap

   输出示例

   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

   Copy to Clipboard Toggle word wrap

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

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

   Copy to Clipboard Toggle word wrap

流程

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

   $ sudo microshift-cleanup-data --cert

   Copy to Clipboard Toggle word wrap

   输出示例

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

   Copy to Clipboard Toggle word wrap

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

   $ sudo systemctl start microshift

   Copy to Clipboard Toggle word wrap

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

流程

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

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

   默认 auditLog 配置示例

   apiServer:
   # ....
     auditLog:
       maxFileAge: 7 

   1

   
       maxFileSize: 200 

   2

   
       maxFiles: 1 

   3

   
       profile: Default 

   4

   
   # ....

   Copy to Clipboard Toggle word wrap

   1

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

   2

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

   3

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

   4

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

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

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

      $ sudo systemctl stop microshift

      Copy to Clipboard Toggle word wrap

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

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

      1

      Copy to Clipboard Toggle word wrap

      1

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

   3. 如果为日志指定新目录，请运行以下命令到位于 /var/log/kube-apiserver 的自定义目录：

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

      1

      Copy to Clipboard Toggle word wrap

      1

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

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

   $ sudo systemctl restart microsohift

   Copy to Clipboard Toggle word wrap