Beralih ke mode PKI yang berbeda

Google Distributed Cloud (GDC) dengan air gap menyediakan API infrastruktur kunci publik (PKI) untuk mendapatkan sertifikat web. Halaman ini memberikan petunjuk untuk beralih dari satu mode sertifikat PKI ke mode lainnya. Untuk mengetahui informasi selengkapnya tentang jenis konfigurasi mode PKI, lihat Konfigurasi sertifikat TLS web

Sebelum memulai

Untuk mendapatkan izin yang diperlukan guna mengonfigurasi penerbit sertifikat default PKI, minta Admin IAM Organisasi Anda untuk memberi Anda peran Admin PKI Infra (infra-pki-admin) di namespace sistem.

Transisi ke mode subCA BYO

Bagian ini memberikan serangkaian langkah untuk bertransisi ke mode sertifikat SubCA bawa sendiri (BYO).

Membuat subCA BYO

Untuk membuat subCA BYO, terapkan resource kustom ke zona Distributed Cloud Anda.

  1. Buat resource CertificateAuthority dan simpan sebagai file YAML. Dalam contoh berikut, Anda melihat contoh resource CertificateAuthority

    apiVersion: pki.security.gdc.goog/v1
kind: CertificateAuthority
metadata:
  name: CA_NAME
  namespace: pki-system
spec:
  caProfile:
    commonName: COMMON_NAME
    duration: DURATION
    renewBefore: RENEW_BEFORE
  caCertificate:
    externalCA: {}
  certificateProfile:
    keyUsage:
    - digitalSignature
    - keyCertSign
    - crlSign
    extendedKeyUsage:
    - serverAuth
  secretConfig:
    secretName: SECRET_NAME

    Ganti variabel berikut:

    • CA_NAME: nama subCA.
    • COMMON_NAME: nama umum sertifikat CA.
    • DURATION: masa aktif yang diminta untuk sertifikat CA.
    • RENEW_BEFORE: waktu rotasi sebelum masa berlaku sertifikat CA berakhir.
    • SECRET_NAME: nama Secret Kubernetes yang akan menyimpan kunci pribadi dan sertifikat CA yang ditandatangani.

  2. Terapkan resource kustom ke zona Distributed Cloud Anda.

    kubectl apply -f byo-subca.yaml --kubeconfig MANAGEMENT_API_SERVER

    Ganti MANAGEMENT_API_SERVER dengan file kubeconfig server Management API.

CSR untuk CA Subordinat dibuat dan menunggu Anda menandatanganinya. Untuk menandatangani CSR, ikuti petunjuk di bagian Menandatangani sertifikat subCA BYO.

Menandatangani sertifikat subCA BYO

  1. Dapatkan permintaan penandatanganan sertifikat (CSR) dari lingkungan GDC Anda:

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

    Perintah ini akan menghasilkan file sub_ca.csr di direktori saat ini. File ini berisi CSR untuk sertifikat CA X.509.

  2. Gunakan protokol CA root pelanggan untuk meminta sertifikat CA yang ditandatangani untuk file sub_ca.csr.

  3. Untuk permintaan penandatanganan sertifikat yang disetujui, Anda akan mendapatkan sertifikat CA yang ditandatangani oleh CA root pelanggan. Simpan sertifikat ke file sub_ca.crt di direktori saat ini. Selain itu, dapatkan sertifikat CA root pelanggan dan simpan ke file ca.crt di direktori saat ini. Hubungi PMO untuk mendapatkan petunjuk yang tepat.

  4. Verifikasi hal berikut untuk memastikan integritas dan akurasi sertifikat:

    1. Pastikan sub_ca.crt sesuai dengan format sertifikat berenkode PEM standar:

      -----BEGIN CERTIFICATE-----
      <Certificate>
-----END CERTIFICATE-----

    2. Pastikan bahwa sub_ca.crt adalah Otoritas Sertifikat (CA) yang valid dalam ekstensi "Batasan Dasar":

      openssl x509 -text -noout -in sub_ca.crt | grep -A 1 "Basic Constraints"

      Output harus menyertakan CA:TRUE atau penyelidikan lebih lanjut diperlukan:

      X509v3 Basic Constraints: critical
    CA:TRUE

    3. Verifikasi ekstensi Nama Alternatif Subjek (SAN) dalam sertifikat:

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

      Jika sertifikat CA memiliki Nama Umum (CN), bukan SAN, verifikasi CN dalam sertifikat:

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

  5. Buat spesifikasi untuk menerapkan patch pada resource CertificateAuthority:

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

    Isi dalam file patch.txt akan terlihat mirip dengan cuplikan berikut:

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

  6. Edit spesifikasi resource CertificateAuthority:

    kubectl patch certificateauthority CA_NAME -n pki-system --patch-file patch.txt --type='merge'

  7. Verifikasi kesiapan subCA BYO:

    kubectl get certificateauthority CA_NAME -n pki-system -ojson | jq -r ' .status.conditions[] | select( .type as $id | "Ready" | index($id))'

    Anda akan melihat output yang mirip dengan berikut ini:

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

  8. Verifikasi masa berlaku sertifikat CA yang ditandatangani:

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

  9. Buat file YAML resource CertificateIssuer dan simpan file tersebut. Misalnya, byo-subca-issuer.yaml:

    apiVersion: pki.security.gdc.goog/v1
kind: CertificateIssuer
metadata:
  name: BYO_SUBCA_ISSUER
  namespace: pki-system
spec:
  caaasConfig:
    certificateAuthorityRef:
      namespace: pki-system
      name: CA_NAME

    Ganti BYO_SUBCA_ISSUER dengan nama penerbit subCA BYO.

  10. Terapkan resource kustom ke zona Distributed Cloud di server Management API menggunakan CLI kubectl:

    kubectl apply -f byo-subca-issuer.yaml --kubeconfig MANAGEMENT_API_SERVER

  11. Verifikasi kesiapan penerbit baru:

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

Transisi ke mode Bawa Sertifikat Anda Sendiri

Bagian ini memberikan serangkaian langkah untuk beralih ke mode BYO-cert.

Membuat CertificateIssuer BYO

  1. Buat resource CertificateIssuer dan simpan sebagai file YAML, misalnya, byo-cert-issuer.yaml. Penerbit sertifikat BYO ini menggunakan default-tls-ca terkelola sebagai CA pengganti:

    apiVersion: pki.security.gdc.goog/v1
kind: CertificateIssuer
metadata:
  name: BYO_CERT_ISSUER_NAME
  namespace: pki-system
spec:
  byoCertConfig:
    fallbackCertificateAuthority:
      name: default-tls-ca
      namespace: pki-system

    Ganti BYO_CERT_ISSUER_NAME dengan nama penerbit sertifikat BYO.

  2. Terapkan resource kustom ke zona Distributed Cloud Anda di server Management API:

    kubectl apply -f byo-cert-issuer.yaml --kubeconfig MANAGEMENT_API_SERVER

  3. Verifikasi kesiapan penerbit baru.

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

    Outputnya terlihat mirip dengan yang berikut ini:

    {
  "lastTransitionTime": "2024-05-01T22:25:20Z",
  "message": "",
  "observedGeneration": 1,
  "reason": "FallbackCAReady",
  "status": "True",
  "type": "Ready"
}

Menandatangani Sertifikat BYO

  1. Saat menunggu CSR ditandatangani secara eksternal, sertifikat BYO dapat dikeluarkan sementara oleh CA pengganti yang ditentukan di penerbit sertifikat BYO. Mendapatkan status BYO-cert default-wildcard-cert saat ini:

    kubectl get certificate.pki.security.gdc.goog/default-wildcard-cert -n istio-system -o json | jq -r ' .status.conditions[] | select( .type as $id | "Ready" | index($id))'

    Outputnya terlihat mirip dengan yang berikut ini:

    {
  "lastTransitionTime": "2024-05-03T08:42:10Z",
  "message": "Certificate is issued by a fallback CA",
  "observedGeneration": 1,
  "reason": "UsingFallbackCA",
  "status": "True",
  "type": "Ready"
}

    Alasan siap menyatakan UsingFallbackCA untuk menunjukkan bahwa CA pengganti menerbitkan sertifikat. Kemudian, nilai tersebut disimpan dalam secret dan siap digunakan.

  2. Dapatkan nama rahasia sertifikat:

    kubectl -n istio-system get certificate.pki.security.gdc.goog/default-wildcard-cert -ojson | jq -r '.spec.secretConfig.secretName'

    Outputnya terlihat mirip dengan yang berikut ini:

    web-tls

  3. Periksa penerbit dari secret:

    kubectl get secret web-tls -n istio-system -o jsonpath='{.data.tls\.crt}' |
base64 -d | openssl x509 -text -noout | grep Issuer

    Outputnya terlihat mirip dengan yang berikut ini:

    Issuer: CN = GDC Managed ORG TLS CA

    Sertifikat bawaan Anda (BYO-cert) dapat menggunakan sertifikat yang cocok untuk sementara saat menunggu tanda tangan CSR-nya sendiri. Sertifikat example-service dengan dnsName sebagai example-service.org-1.zone1.google.gdch.test cocok dengan default-wildcard-cert dengan DNSName *.org-1.zone1.google.gdch.test dari penerbit sertifikat yang sama. Sertifikat example-service dapat memiliki status berikut saat menunggu CSR-nya ditandatangani:

    {
  "lastTransitionTime": "2024-05-03T22:30:51Z",
  "message": "Using a matched issued Certificate: default-wildcard-cert/istio-system",
  "observedGeneration": 1,
  "reason": "UsingMatchedCert",
  "status": "True",
  "type": "Ready"
}

  4. Dapatkan CSR dari status sertifikat:

    kubectl -n istio-system get certificate.pki.security.gdc.goog/default-wildcard-cert -ojson | jq -r ' .status.byoCertStatus.csrStatus'

    Outputnya terlihat mirip dengan yang berikut ini:

    {
  "conditions": [
    {
      "lastTransitionTime": "2024-05-03T18:14:19Z",
      "message": "",
      "observedGeneration": 1,
      "reason": "WaitingForSigning",
      "status": "False",
      "type": "Ready"
    }
  ],
  "csr": "LS0tLS1CRUdJTiBDRVJUSUZJQ0FURSB..."
}

  5. Ada berbagai metode untuk menandatangani CSR berdasarkan konfigurasi CA eksternal. Saat menandatangani, gunakan SAN dari CSR. Contoh:

    function signCert() {
   certName=$1
   ns=$2

   # Download the CSR from the certificate
   kubectl get certificate.pki.security.gdc.goog $certName -n $ns -o jsonpath='{.status.byoCertStatus.csrStatus.csr}' | base64 -d > $certName.csr

   # Get SAN from the csr
   san=$(openssl req -in $certName.csr -noout -text | grep 'DNS:' | sed -s 's/^[ ]*//')

   # Save SAN to extension config
   cat <<EOF >$certName-csr.ext
 keyUsage=digitalSignature,keyEncipherment
 extendedKeyUsage=serverAuth,clientAuth
 subjectAltName=${san}
 EOF

   # Sign the CSR with an external CA. You need to prepare the external CA cert and key
   openssl x509 -req -in $certName.csr -days 365 -CA ext-ca.crt -CAkey ext-ca.key -CAcreateserial -extfile $certName-csr.ext -out $certName-signed.crt
   openssl x509 -in $certName-signed.crt -text -noout

   # Upload the externally signed certificate by patching.
   echo "spec:
     byoCertificate:
        certificate: $(base64 -w0 $certName-signed.crt)
        ca: $(base64 -w0 ext-ca.crt)" > patch.txt

   kubectl patch certificate.pki.security.gdc.goog $certName -n $ns --patch-file patch.txt --type='merge'
 }

 # Use the function to sign the default-wildcard-cert in the istio-system namespace
 signCert default-wildcard-cert istio-system

  6. Verifikasi detail berikut:

    • Status CSR sertifikat adalah Ready
    kubectl -n istio-system get certificate.pki.security.gdc.goog/default-wildcard-cert -ojson | jq -r ' .status.byoCertStatus.csrStatus.conditions'

    [
   {
      "lastTransitionTime": "2024-05-03T21:56:25Z",
      "message": "",
      "observedGeneration": 2,
      "reason": "Signed",
      "status": "True",
      "type": "Ready"
   }
]
    • Sertifikat Ready dengan alasan Issued
    kubectl get certificate.pki.security.gdc.goog/default-wildcard-cert -n istio-system -o json | jq -r ' .status.conditions[] | select( .type as $id | "Ready" | index($id))'

    Outputnya terlihat mirip dengan yang berikut ini:

    {
  "lastTransitionTime": "2024-05-03T08:42:10Z",
  "message": "Certificate is issued",
  "observedGeneration": 2,
  "reason": "Issued",
  "status": "True",
  "type": "Ready"
}
    • Secret diperbarui:
    kubectl get secret web-tls -n istio-system -o jsonpath='{.data.tls\.crt}' | base64 -d | openssl x509 -text -noout | grep Issuer

    Outputnya terlihat mirip dengan yang berikut ini:

            Issuer: CN = external-ca

Beralih ke Sertifikat BYO dengan mode ACME

Bagian ini memberikan serangkaian langkah untuk beralih ke BYO-cert dengan mode ACME.

Buat CertificateIssuer dengan konfigurasi ACME

  1. Buat resource CertificateIssuer dengan konfigurasi ACME dan simpan sebagai file YAML, seperti acme-issuer.yaml.

    apiVersion: pki.security.gdc.goog/v1
kind: CertificateIssuer
metadata:
  name: ACME_ISSUER_NAME
  namespace: pki-system
spec:
     acmeConfig:
       rootCACertificate: ROOT_CA_CERTIFICATE
       acme:
         server: ACME_SERVER_URL
         caBundle: CA_BUNDLE
         privateKeySecretRef:
           name: PRIVATE_KEY_SECRET_NAME

    Ganti variabel berikut:

    • ACME_ISSUER_NAME: nama penerbit ACME.
    • ROOT_CA_CERTIFICATE: data CA root sertifikat yang dikeluarkan oleh server ACME.
    • ACME_SERVER_URL: URL untuk mengakses endpoint direktori server ACME.
    • CA_BUNDLE: paket CA PEM berenkode Base64 yang memvalidasi rantai sertifikat yang ditampilkan oleh server ACME.
    • PRIVATE_KEY_SECRET_NAME: nama secret yang berisi kunci pribadi akun ACME.

    Untuk menggunakan kunci pribadi akun ACME yang ada, pastikan nama rahasia yang menyimpannya menggunakan nama PRIVATE_KEY_SECRET_NAME dalam namespace yang sama dengan penerbit ACME. Jika Anda tidak memberikan secret ini, secret baru dengan nama yang sama akan dibuat secara otomatis untuk menyimpan kunci pribadi akun ACME.

  2. Terapkan resource kustom ke zona Distributed Cloud Anda:

    kubectl apply -f acme-issuer.yaml --kubeconfig MANAGEMENT_API_SERVER

  3. Verifikasi kesiapan penerbit baru:

    kubectl --kubeconfig MANAGEMENT_API_SERVER -n pki-system get certificateissuer.pki.security.gdc.goog/ACME_ISSUER_NAME -ojson | jq -r ' .status.conditions[] | select( .type as $id | "Ready" | index($id))'

    Anda akan melihat output yang mirip dengan berikut ini:

    {
  "lastTransitionTime": "2024-05-01T18:32:17Z",
  "message": "",
  "observedGeneration": 1,
  "reason": "ACMEClientReady",
  "status": "True",
  "type": "Ready"
}

Penerbitan ulang sertifikat

Untuk mengganti penerbit default ke penerbit ACME baru, lihat Mengubah penerbit sertifikat default

Untuk segera menerbitkan ulang sertifikat dengan penerbit default baru, lihat Menerbitkan ulang sertifikat web PKI secara manual.