创建从属证书授权机构

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

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

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

本文档面向应用运维人员组内的受众，例如应用开发者或数据科学家，他们负责管理项目中的证书生命周期。如需了解详情，请参阅 GDC 网闸隔离配置文档的受众。

准备工作

您必须先请求必要的权限并准备环境，然后才能创建 Sub CA。

请求 IAM 角色

如需创建、更新和删除证书授权机构资源，请与组织 IAM 管理员联系，以在证书授权机构的项目命名空间中请求 Certificate Authority Service Admin (certificate-authority-service-admin) 角色。

准备环境

• 下载并 安装 gdcloud CLI（如果您尚未这样做）。

• 安装 kubectl CLI。

• 生成 kubeconfig 文件 以配置 kubectl 访问权限。

创建受管 Sub CA

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

如需创建受管 Sub 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	Sub CA 的名称。
   USER_PROJECT_NAMESPACE	用户项目所在的命名空间的名称。
   COMMON_NAME	CA 证书的通用名称。
   DURATION	CA 证书的请求生命周期。以小时为单位指定时长（例如 1000h）。不支持以天 (d) 或年 (y) 为单位。
   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 替换为 Management API 服务器的 kubeconfig 文件的路径。

3. 验证 Sub 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 创建 Sub CA

此 Sub 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	subCA 的名称。
   USER_PROJECT_NAMESPACE	您要将映像导入到的项目的项目 ID。
   COMMON_NAME	CA 证书的通用名称。
   DURATION	CA 证书的请求生命周期。以小时为单位指定时长（例如 1000h）。不支持以天 (d) 或年 (y) 为单位。
   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 Management API 服务器中生成 Sub 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. 验证 CA 证书的通用名称 (CN)：

   openssl x509 -noout -subject -in sub_ca.crt
   

   如果您的设置需要正文备用名称 (SAN) 扩展项，请验证证书中的 SAN 扩展项：

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

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) Sub 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