轮替软件包验证证书

本页面介绍了如何在 Google Distributed Cloud (GDC) 气隙环境中轮替用于软件包验证的根证书授权机构

GDC 软件包验证使用根证书授权机构 (CA) 来验证发布密钥证书。因此，定期轮换根 CA 证书至关重要。如果发布通知或升级过程中可能显示的警告消息指示您轮换根 CA，您必须轮换根 CA。如需详细了解升级流程，请参阅将制品推送到容器注册表。

准备工作

如需轮换软件包验证证书，您必须拥有必要的身份和访问权限角色：

  • 系统制品注册表调试器：拥有对所有 Harbor 资源的读取和写入权限。请让您的 Security Admin 为您授予 System Artifact Registry Debugger (sar-debugger) 集群角色。

需要验证证书轮替

在执行操作之前，请验证是否需要轮替软件包验证证书：

  1. 设置 KUBECONFIG 环境变量：

    $ KUBECONFIG=PATH_TO_KUBECONFIG_FILE

    将 PATH_TO_KUBECONFIG_FILE 替换为通过在根管理员集群中运行 gdcloud auth login 获取的 kubeconfig 文件的路径。

  2. 通过将当前信任锚与最新信任锚进行比较，确定是否需要升级。系统会将 harbor-system/package-validation-root-certs 中的 ConfigMap 数据与本地信任锚进行比较：

    $ CURRENT_TRUST_ANCHOR=$(kubectl  --kubeconfig=$KUBECONFIG get cm package-validation-root-certs -n harbor-system -o jsonpath='{.data.ca\.crt}')

$ LATEST_TRUST_ANCHOR=$(cat /root/release/staging_root_ca_certificate.crt)

$ diff <( echo "$CURRENT_TRUST_ANCHOR" ) <( echo "$LATEST_TRUST_ANCHOR" ) && echo trust anchors are same  || echo trust anchors are different, upgrade required!

  3. 如果必须轮替证书，请参阅执行证书轮替和升级。

执行证书轮替和升级

使用基础设施即代码 (IaC) 工具和流程来轮换根管理员集群中位于 harbor-system/package-validation-root-certs 的 ConfigMap 对象。

  1. 创建以下变量并为其分配值：

    USERNAME=gitlab-admin
URL=GDC_URL
TEMPLATE_FILE="/tmp/package-validation-root-certs.yaml.tpl"
TARGET_FOLDER=/tmp/${USERNAME}/infrastructure/zonal/zones/ZONE_NAME/root-admin/package-validation
OUTPUT="${TARGET_FOLDER}/package-validation-root-certs.yaml"
LATEST_TRUST_ANCHOR_CA_FILE=/root/release/staging_root_ca_certificate.crt
CONFIGMAP_NAME=package-validation-root-certs
NAMESPACE=harbor-system

    将 GDC_URL 替换为您的 GDC 项目的网址。

  2. 克隆代码库：

    git -c http.sslVerify=false clone -b main https://${USERNAME}:TOKEN@gitlab.${URL}/gdch/iac /tmp/${USERNAME}

    将 TOKEN 替换为您的 GitLab 个人访问令牌。如需了解详情，请参阅 https://docs.gitlab.com/ee/user/profile/personal_access_tokens.html#create-a-personal-access-token，了解如何创建个人访问令牌。

  3. 创建目标文件夹，用于存放证书轮换流程的输出文件：

    mkdir -p "${TARGET_FOLDER}"

  4. 更新并替换 LATEST_TRUST_ANCHOR 的值：

      cat <<EOF  > "${OUTPUT}"
  apiVersion: v1
  kind: ConfigMap
  metadata:
    name: ${CONFIGMAP_NAME}
    namespace: ${NAMESPACE}
  data:
    ca.crt: |
  $(sed 's/^/    /' "${LATEST_TRUST_ANCHOR_CA_FILE}")
  EOF

  5. 验证信任锚是否已正确更新：

    $ cat "${OUTPUT}"
apiVersion: v1
data:
  ca.crt: |
    -----BEGIN CERTIFICATE-----
    MIID3DCCAsSgAwIBAgITb1SPkse7G8syTQUFfc8NOqY4RzANBgkqhkiG9w0BAQsF
    ADB2MQswCQYDVQQGEwJ1czETMBEGA1UECBMKY2FsaWZvcm5pYTETMBEGA1UEBxMK
    c3Vubnl2aWxsZTEPMA0GA1UEChMGZ29vZ2xlMQ0wCwYDVQQLEwRnZGNoMR0wGwYD
    VQQDExRnZGNoLWNvZGUtc2lnbmluZy1jYTAeFw0yMzAzMDUwNjMyMjlaFw0zMzAz
    MDIwNjMyMjhaMHYxCzAJBgNVBAYTAnVzMRMwEQYDVQQIEwpjYWxpZm9ybmlhMRMw
    EQYDVQQHEwpzdW5ueXZpbGxlMQ8wDQYDVQQKEwZnb29nbGUxDTALBgNVBAsTBGdk
    Y2gxHTAbBgNVBAMTFGdkY2gtY29kZS1zaWduaW5nLWNhMIIBIjANBgkqhkiG9w0B
    AQEFAAOCAQ8AMIIBCgKCAQEAsD2XLR9cxbP0dnJfqdiBr1ZX1oq3AklU0IG5p7ZL
    F7NA1/qoKDWe5RuoBM/X4snI/5gnz9zuHapXA9HLN7bfEpr7orXlK00jn2AGqiNk
    jBriDFqgOF33W+/AWDG8HujlMosYK+Gp4FU9ni5S2Ay2sMk83CC+eFh7T//ji8y9
    PnUsLEwmNiCDb1UMqrcAXpmeTxd7PZlPIsujrkqLGAwjEE02XA7SqMPe/cPfzKEO
    0mK1VvxYmHdLOJtyKWgYIwy6+8Ka6Js3WgjNi0fLnxH7kbVaIvbLSvZa00JsX4GQ
    v1bxLSRUvfuI66O/vOEWH3zzKReTjQKMflz4570gciAntQIDAQABo2MwYTAOBgNV
    HQ8BAf8EBAMCAQYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQUWZ0gQZKNybd8
    BAy2gamLf7Isiq4wHwYDVR0jBBgwFoAUWZ0gQZKNybd8BAy2gamLf7Isiq4wDQYJ
    KoZIhvcNAQELBQADggEBAGtifprappLxMaPQxGS8v2DYSlF3OYcBw2+JWISR62vB
    7mRjhuwh6QmcDHxLu+9RQ7E6aNaADCKbw0/6/OtGhvaxNtmZuBaBRhYPf2juQSgW
    BtQbmdr3h99wAFtpfvt4FOFYvTMRByOm/imi8Oq1+1y3OQEp2ayiMZ9pBg8DDY59
    juuszBKNZA99cMTtAQPCFkbMODRGFDYlaM5JhxVJ8/J9TCh4tNLx1BTJUtaZYjVF
    TlkzFdCoUnHWFPsapL1Mhje1vZBrhVKkSQETBfssvWQSNamOOLL139O428pxUUrH
    a7ahVae1mO4kQce3uBp3WyKcBx3pPNmYbRtGCe2xSB0=
    -----END CERTIFICATE-----
kind: ConfigMap
metadata:
  name: package-validation-root-certs
  namespace: harbor-system

  6. 移除用于替换信任锚点值的临时文件：

    $ rm "${TEMPLATE_FILE}" "${AWK_RULE_FILE}" "${LATEST_TRUST_ANCHOR_CA_FILE}"

  7. 在提交更改之前验证对象：

    $ /root/release/gdcloud system assets validate --config "${OUTPUT}" --level object

  8. 提交更改：

    $ cd "${TARGET_FOLDER}"
$ git add -A
$ git config user.name "GitlabAdmin"
$ git config user.email "gitlab-admin@example.com"

$ git commit -am "upgrade package-validation-root-certs"
$ git checkout -b ${USERNAME}-branch

  9. 创建合并请求：

    $ git -c http.sslVerify=false push -o merge_request.create \
https://${USERNAME}:TOKEN@gitlab.${URL}/gdch/iac ${USERNAME}-branch

  10. 输出内容必须如下例所示：

    warning: redirecting to https://gitlab.zone1.google.gdch.test/gdch/iac.git/
Enumerating objects: 8, done.
Counting objects: 100% (8/8), done.
Delta compression using up to 16 threads
Compressing objects: 100% (4/4), done.
Writing objects: 100% (7/7), 920 bytes | 920.00 KiB/s, done.
Total 7 (delta 0), reused 0 (delta 0)
remote:
remote: View merge request for gitlab-admin-branch:
remote:   https://gitlab.GDC_URL/gdch/iac/-/merge_requests/1
remote:
To https://gitlab.zone1.google.gdch.test/gdch/iac
* [new branch]      gitlab-admin-branch -> gitlab-admin-branch

  11. 您的更改合并后，您必须从其他 IO 处获得证书轮换的批准。

获得证书轮替批准

另一位 IO 用户必须担任审批者的角色并验证此更改。审批 IO 必须遵循以下步骤：

  1. 将目标升级版本的受保护信任锚下载到 U 盘。如需下载此文件，您必须有权访问 Cloud Storage 存储桶。如需获取访问权限，请向 GDC 支持团队升级问题。 如需详细了解如何下载 GDC 分发版本和文件，请参阅下载文件。

  2. 使用 USB 驱动器将最新版本的信任锚复制到隔离的网络环境中。

  3. 提取证书，并将合并请求中的证书与提取的证书进行比较：

    VERSION=VERSION
DIGEST=DIGEST_INFORMATION
export GCS_BUCKET=private-cloud-release
DOWNLOADER=gdch-downloader-root-ca-$VERSION.sh
gcloud storage cp "gs://$GCS_BUCKET/$VERSION/$DOWNLOADER" .
echo "$DIGEST $DOWNLOADER" | sha256sum -c && chmod +x $DOWNLOADER && ./$DOWNLOADER --skip-unzip
$ cat root_ca_certificate.crt

    替换以下内容：

    • VERSION：GDC 发布版本。例如 1.x.y-gdch.z。
    • DIGEST_INFORMATION：您从 Google 联系人处收到的摘要信息。摘要信息因特定发布版本而异。例如，1.2.0-gdch.243 摘要与 1.2.0-gdch.321 摘要不同。出于安全考虑，此信息是手动提供的。

  4. 当 ca.crt 证书数据与下载的证书相同时，批准更改。证书必须如以下示例所示：

    -----BEGIN CERTIFICATE-----
MIID3DCCAsSgAwIBAgITb1SPkse7G8syTQUFfc8NOqY4RzANBgkqhkiG9w0BAQsF
ADB2MQswCQYDVQQGEwJ1czETMBEGA1UECBMKY2FsaWZvcm5pYTETMBEGA1UEBxMK
c3Vubnl2aWxsZTEPMA0GA1UEChMGZ29vZ2xlMQ0wCwYDVQQLEwRnZGNoMR0wGwYD
VQQDExRnZGNoLWNvZGUtc2lnbmluZy1jYTAeFw0yMzAzMDUwNjMyMjlaFw0zMzAz
MDIwNjMyMjhaMHYxCzAJBgNVBAYTAnVzMRMwEQYDVQQIEwpjYWxpZm9ybmlhMRMw
EQYDVQQHEwpzdW5ueXZpbGxlMQ8wDQYDVQQKEwZnb29nbGUxDTALBgNVBAsTBGdk
Y2gxHTAbBgNVBAMTFGdkY2gtY29kZS1zaWduaW5nLWNhMIIBIjANBgkqhkiG9w0B
AQEFAAOCAQ8AMIIBCgKCAQEAsD2XLR9cxbP0dnJfqdiBr1ZX1oq3AklU0IG5p7ZL
F7NA1/qoKDWe5RuoBM/X4snI/5gnz9zuHapXA9HLN7bfEpr7orXlK00jn2AGqiNk
jBriDFqgOF33W+/AWDG8HujlMosYK+Gp4FU9ni5S2Ay2sMk83CC+eFh7T//ji8y9
PnUsLEwmNiCDb1UMqrcAXpmeTxd7PZlPIsujrkqLGAwjEE02XA7SqMPe/cPfzKEO
0mK1VvxYmHdLOJtyKWgYIwy6+8Ka6Js3WgjNi0fLnxH7kbVaIvbLSvZa00JsX4GQ
v1bxLSRUvfuI66O/vOEWH3zzKReTjQKMflz4570gciAntQIDAQABo2MwYTAOBgNV
HQ8BAf8EBAMCAQYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQUWZ0gQZKNybd8
BAy2gamLf7Isiq4wHwYDVR0jBBgwFoAUWZ0gQZKNybd8BAy2gamLf7Isiq4wDQYJ
KoZIhvcNAQELBQADggEBAGtifprappLxMaPQxGS8v2DYSlF3OYcBw2+JWISR62vB
7mRjhuwh6QmcDHxLu+9RQ7E6aNaADCKbw0/6/OtGhvaxNtmZuBaBRhYPf2juQSgW
BtQbmdr3h99wAFtpfvt4FOFYvTMRByOm/imi8Oq1+1y3OQEp2ayiMZ9pBg8DDY59
juuszBKNZA99cMTtAQPCFkbMODRGFDYlaM5JhxVJ8/J9TCh4tNLx1BTJUtaZYjVF
TlkzFdCoUnHWFPsapL1Mhje1vZBrhVKkSQETBfssvWQSNamOOLL139O428pxUUrH
a7ahVae1mO4kQce3uBp3WyKcBx3pPNmYbRtGCe2xSB0=
-----END CERTIFICATE-----

  5. 通过检查 RootSync 资源来确认操作是否成功。RootSync 资源可用于管理集群中具有 cluster-admin 权限的任何资源。检查 RootSync 资源是否已成功呈现：

    $ kubectl --kubeconfig=$KUBECONFIG describe rootsync/root-sync -n config-management-system

  6. 如果 RootSync 渲染成功，输出将包含以下消息：Rendering succeeded。

  7. 如果操作失败，则问题很可能是由 IaC 配置问题引起的。 如需了解详情，请参阅调试提示，以缓解常见的 IaC 问题。