创建从属证书授权机构

本页面介绍了创建从属证书授权机构 (Sub CA) 的步骤。

子 CA 负责直接向最终实体（例如用户、计算机和设备）颁发证书。它们由父 CA（通常是根 CA）以加密方式签名。信任根 CA 的系统会自动信任子 CA 及其颁发的证书。

CA 证书签名者可以是 CA Service 中创建的另一个 CA（例如根 CA），也可以是外部 CA。对于外部 CA，CA Service 会生成证书签名请求 (CSR)，外部 CA 必须对该请求进行签名。

准备工作

在创建子 CA 之前，请确保您拥有所需的权限和 kubeconfig 文件。

所需权限

如需获得创建子证书授权机构所需的权限，请让组织 IAM 管理员向您授予 Certificate Authority Service Admin (certificate-authority-service-admin) 角色。如需详细了解角色，请参阅角色定义。

获取 kubeconfig 文件

如需针对管理 API 服务器运行命令，请执行以下操作：

1. 登录并生成管理 API 服务器的 kubeconfig 文件（如果您还没有）。

2. 使用管理 API 服务器的 kubeconfig 文件路径替换这些说明中的 MANAGEMENT_API_SERVER_KUBECONFIG。

创建受管理的从属 CA

对于受管理的从属 CA，CA 证书的签名者是在 CA Service 中创建的另一个 CA（根 CA）。

如需创建受管理的子 CA，请将自定义资源应用到 Distributed Cloud Appliance 实例。

1. 创建 CertificateAuthority 资源并将其保存为名为 subca.yaml 的 YAML 文件：

   apiVersion: pki.security.gdc.goog/v1
   kind: CertificateAuthority
   metadata:
     Name: SUB_CA_NAME
     namespace: USER_PROJECT_NAMESPACE
   spec:
     caProfile:
       commonName: COMMON_NAME
       duration: DURATION
       renewBefore: RENEW_BEFORE
       organizations:
       - ORGANIZATIONS
       organizationalUnits:
       - ORGANIZATIONAL_UNITS
       countries:
       - COUNTRIES
       localities:
       - LOCALITIES
       provinces:
       - PROVINCES
       streetAddresses:
       - STREET_ADDRESSES
       postalCodes:
       - POSTAL_CODES
     caCertificate:
       managedSubCA:
         certificateAuthorityRef:
           name: ROOT_CA_NAME
           namespace: USER_PROJECT_NAMESPACE
     certificateProfile:
       keyUsage:
         - digitalSignature
         - keyCertSign
         - crlSign
       extendedKeyUsage:
         - EXTENDED_KEY_USAGE
     secretConfig:
       secretName: SECRET_NAME
       privateKeyConfig:
         algorithm: KEY_ALGORITHM
         size: KEY_SIZE
     acme:
       enabled: ACME_ENABLED
   

   执行以下变量替换操作：

   变量	说明
   SUB_CA_NAME	子 CA 的名称。
   USER_PROJECT_NAMESPACE	用户项目所在的命名空间的名称。
   COMMON_NAME	CA 证书的通用名称。
   DURATION	CA 证书的请求有效期。
   ROOT_CA_NAME	根 CA 的名称。
   SECRET_NAME	包含私钥和已签名的 CA 证书的 Kubernetes Secret 的名称。

   以下变量是可选值：

   变量	说明
   RENEW_BEFORE	在 CA 证书过期之前进行轮替的时间。
   ORGANIZATIONS	证书上要使用的组织。
   ORGANIZATIONAL_UNITS	证书上要使用的组织部门。
   COUNTRIES	证书上要使用的国家/地区。
   LOCALITIES	证书上要使用的城市。
   PROVINCES	证书上要使用的州或省/直辖市/自治区。
   STREET_ADDRESSES	证书上要使用的街道地址。
   POSTAL_CODES	证书上要使用的邮政编码。
   EXTENDED_KEY_USAGE	证书的扩展密钥用途。如果提供，允许的值为 serverAuth 和 clientAuth。
   KEY_ALGORITHYM	相应证书所用的私钥算法。允许的值为 RSA、Ed25519 或 ECDSA。如果未提供大小，则对于 ECDSA，默认值为 256；对于 RSA，默认值为 2048。对于 Ed25519，系统会忽略密钥大小。
   KEY_SIZE	相应证书的私钥大小（以位为单位）取决于算法。RSA 允许 2048、3072、4096 或 8192 位（默认 2048 位）。ECDSA 允许 256、384 或 521（默认 256）。Ed25519 会忽略大小。
   ACME_ENABLED	如果设置为 true，CA 将在 ACME 模式下运行，并输出 ACME 服务器网址。然后，您可以使用 ACME 客户端和协议来管理证书。

2. 将自定义资源应用于 Distributed Cloud 实例：

   kubectl apply -f subca.yaml --kubeconfig MANAGEMENT_API_SERVER_KUBECONFIG
   

   将 MANAGEMENT_API_SERVER_KUBECONFIG 替换为管理 API 服务器的 kubeconfig 文件的路径。

3. 验证子 CA 的就绪情况。CA 大约需要 40 分钟才能准备就绪：

   kubectl --kubeconfig MANAGEMENT_API_SERVER_KUBECONFIG -n USER_PROJECT_NAMESPACE get certificateauthority.pki.security.gdc.goog/SUB_CA_NAME -ojson | jq -r ' 
   .status.conditions[] | select( .type as $id | "Ready" | index($id))'
   

   输出类似于以下内容：

   {
     "lastTransitionTime": "2025-01-24T17:09:29Z",
     "message": "CA reconciled",
     "observedGeneration": 2,
     "reason": "Ready",
     "status": "True",
     "type": "Ready"
   }
   

从外部 CA 创建从属 CA

此子 CA 支持使用外部 CA 或用户管理的 CA 签署叶证书。它会生成供用户签名的 CSR。

1. 创建 CertificateAuthority 资源并将其保存为名为 subca-external.yaml 的 YAML 文件：

   apiVersion: pki.security.gdc.goog/v1
   kind: CertificateAuthority
   metadata:
     Name: SUB_CA_NAME
     namespace: USER_PROJECT_NAMESPACE
   spec:
     caProfile:
       commonName: COMMON_NAME
       duration: DURATION
       renewBefore: RENEW_BEFORE
       organizations:
       - ORGANIZATION
       organizationalUnits:
       - ORGANIZATIONAL_UNITS
       countries:
       - COUNTRIES
       localities:
       - LOCALITIES
       provinces:
       - PROVINCES
       streetAddresses:
       - STREET_ADDRESSES
       postalCodes:
       - POSTAL_CODES
     caCertificate:
       externalCA: {}
     certificateProfile:
       keyUsage:
         - digitalSignature
         - keyCertSign
         - crlSign
       extendedKeyUsage:
         - EXTENDED_KEY_USAGE
     secretConfig:
       secretName: SECRET_NAME
       privateKeyConfig:
         algorithm: KEY_ALGORITHM
         size: KEY_SIZE
     acme:
       enabled: ACME_ENABLED
   

   执行以下变量替换操作：

   变量	说明
   SUB_CA_NAME	子 CA 的名称。
   USER_PROJECT_NAMESPACE	要将映像导入到的项目的项目 ID。
   COMMON_NAME	CA 证书的通用名称。
   DURATION	CA 证书的请求有效期
   SECRET_NAME	包含私钥和已签名的 CA 证书的 Kubernetes Secret 的名称。

   以下变量是可选值：

   变量	说明
   RENEW_BEFORE	在 CA 证书过期之前进行轮替的时间。
   ORGANIZATION	证书上要使用的组织。
   ORGANIZATIONAL_UNITS	证书上要使用的组织部门。
   COUNTRIES	证书上要使用的国家/地区。
   LOCALITIES	证书上要使用的城市。
   PROVINCES	证书上要使用的州或省/直辖市/自治区。
   STREET_ADDRESSES	证书上要使用的街道地址。
   POSTAL_CODES	证书上要使用的邮政编码。
   EXTENDED_KEY_USAGE	证书的扩展密钥用途。如果提供，允许的值为 serverAuth 和 clientAuth。
   KEY_ALGORITHYM	相应证书所用的私钥算法。允许的值为 RSA、Ed25519 或 ECDSA。如果未提供大小，则对于 ECDSA，大小默认为 256；对于 RSA，大小默认为 2048。系统会忽略 Ed25519 的密钥大小。
   KEY_SIZE	相应证书的私钥大小（以位为单位）取决于算法。RSA 允许 2048、3072、4096 或 8192（默认 2048）。 ECDSA 允许 256、384 或 521（默认值为 256）。Ed25519 会忽略大小。
   ACME_ENABLED	如果设置为 true，CA 将在 ACME 模式下运行，并输出 ACME 服务器网址。然后，您可以使用 ACME 客户端和协议来管理证书。

2. 将自定义资源应用于 Distributed Cloud 实例：

   kubectl apply -f subca-external.yaml --kubeconfig MANAGEMENT_API_SERVER_KUBECONFIG
   

3. 在 GDC 管理 API 服务器中生成从属 CA 的 CSR。您必须下载 CSR 并对其进行签名。签名后，您可以将签名后的证书上传到 GDC Management API 服务器。

4. 从 Distributed Cloud 环境中收集证书签名请求 (CSR)：

   kubectl get certificateauthorities SUB_CA_NAME -n USER_PROJECT_NAMESPACE -ojson | jq -j '"echo ", .status.externalCA.csr, " | base64 -d > ","sub_ca.csr\n"' | bash
   

   该命令会在当前目录中生成一个名为 sub_ca.csr 的 CSR 文件。此文件包含 X.509 CA 证书的 CSR。

5. 使用客户的根 CA 为 sub_ca.csr 文件请求已签名的 CA 证书。

6. 对于已获批准的证书签名请求，您必须获取由客户的根 CA 签名的 CA 证书。将证书存储在当前目录的 sub_ca.crt 文件中。

7. 如果适用，请获取客户的根 CA 证书，并将其存储在当前目录中的 ca.crt 文件中。

8. 验证证书中的主题备用名称 (SAN) 扩展项：

   openssl x509 -text -noout -in sub_ca.crt | grep -A 1 "Subject Alternative Name"
   

   如果 CA 证书具有公用名 (CN) 而不是 SAN，请验证证书中的 CN：

   openssl x509 -text -noout -in sub_ca.crt | grep -A 1 "Subject: CN"
   

9. 生成 spec 以修补 CertificateAuthority 资源：

   echo "spec:
     caCertificate:
       externalCA:
         signedCertificate:
           certificate: $(base64 -w0 SUB_CA_NAME.crt)
           ca: $(base64 -w0 ca.crt)" > patch.txt
   

   patch.txt 文件中的内容类似于以下内容：

   spec:
     caCertificate:
       externalCA:
         signedCertificate:
           certificate: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSURSekNDQ…
           ca: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSURRVENDQ…
   

10. 修改 CertificateAuthority 资源的 spec 字段：

    kubectl patch certificateauthority SUB_CA_NAME -n USER_PROJECT_NAMESPACE--patch-file patch.txt --type='merge'
    

11. 验证自带 (BYO) 子 CA 的就绪情况。CA 通常需要大约 40 分钟才能准备就绪：

    kubectl -n USER_PROJECT_NAMESPACE get certificateauthority.pki.security.gdc.goog/SUB_CA_NAME -ojson | jq -r ' .status.conditions[] | select( .type as $id | "Ready" | index($id))'
    

    输出类似于以下内容：

    {
      "lastTransitionTime": "2024-04-30T22:10:50Z",
      "message": "Certificate authority is ready for use",
      "observedGeneration": 3,
      "reason": "Ready",
      "status": "True",
      "type": "Ready"
    }
    

12. 验证已签名的 CA 证书的失效日期：

    kubectl -n USER_PROJECT_NAMESPACE get secret SECRET_NAME -ojson | jq -j '"echo ", .metadata.name, " $(echo ", .data["tls.crt"], "| base64 -d | openssl x509 -enddate -noout)\n"' | bash
    

列出 CA

如需列出 Distributed Cloud 空气隔离实例中的所有 Certificate Authority Service 资源，请执行以下操作：

使用 certificateauthorities 参数列出所有 CertificateAuthority 资源：

   kubectl --kubeconfig MANAGEMENT_API_SERVER_KUBECONFIG -n USER_PROJECT_NAMESPACE get certificateauthorities

输出类似于以下内容：

   NAMESPACE    NAME              READY   REASON   AGE
   foo          root-ca           True    Ready    7h24m
   foo          sub-ca            True    Ready    7h24m