Crea un'autorità di certificazione subordinata

Questo documento descrive i passaggi per creare un'autorità di certificazione subordinata (sub-CA).

Le CA secondarie sono responsabili dell'emissione dei certificati direttamente alle entità finali, come utenti, computer e dispositivi. Sono firmati in modo crittografico da una CA principale, spesso la CA radice. I sistemi che considerano attendibile la CA radice considerano automaticamente attendibili le CA secondarie e i certificati che emettono.

Il firmatario del certificato CA potrebbe essere un'altra CA creata in Certificate Authority Service, ad esempio una CA principale, o una CA esterna. Con le CA esterne, Certificate Authority Service genera una richiesta di firma del certificato (CSR) che deve essere firmata dalla CA esterna.

Questo documento è rivolto ai gruppi di operatori di applicazioni, come sviluppatori di applicazioni o data scientist, che gestiscono i cicli di vita dei certificati all'interno del loro progetto. Per saperne di più, consulta la documentazione sui segmenti di pubblico per GDC con air gap.

Prima di iniziare

Prima di poter creare una CA secondaria, devi richiedere le autorizzazioni necessarie e preparare l'ambiente.

Richiedi ruoli IAM

Per creare, aggiornare ed eliminare le risorse dell'autorità di certificazione, contatta l'amministratore dell'organizzazione IAM per richiedere il ruolo Certificate Authority Service Admin (certificate-authority-service-admin) nello spazio dei nomi del progetto dell'autorità di certificazione.

prepara l'ambiente

Crea una CA secondaria gestita

Per una CA secondaria gestita, l'entità firmataria del certificato CA è un'altra CA (CA principale) creata in Certificate Authority Service.

Per creare una CA secondaria gestita, applica una risorsa personalizzata alla tua istanza di Distributed Cloud Appliance.

  1. Crea una risorsa CertificateAuthority e salvala come file YAML denominato subca.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
    

    Sostituisci le seguenti variabili:

    Variabile Descrizione
    SUB_CA_NAME Il nome della CA secondaria.
    USER_PROJECT_NAMESPACE Il nome dello spazio dei nomi in cui si trova il progetto utente.
    COMMON_NAME Il nome comune del certificato CA.
    DURATION La durata richiesta del certificato CA. Specifica una durata in ore (ad esempio, 1000h). Unità come giorni (d) o anni (y) non sono supportate.
    ROOT_CA_NAME Il nome della CA principale.
    SECRET_NAME Il nome del secret di Kubernetes che contiene la chiave privata e il certificato CA firmato.

    Le seguenti variabili sono valori facoltativi:

    Variabile Descrizione
    RENEW_BEFORE Il tempo di rotazione prima della scadenza del certificato CA.
    ORGANIZATIONS Organizzazioni da utilizzare nel certificato.
    ORGANIZATIONAL_UNITS Unità organizzative da utilizzare nel certificato.
    COUNTRIES Paesi da utilizzare nel certificato.
    LOCALITIES Città da utilizzare nel certificato.
    PROVINCES Stato o provincia da utilizzare nel certificato.
    STREET_ADDRESSES Indirizzi da utilizzare nel certificato.
    POSTAL_CODES Codici postali da utilizzare nel certificato.
    EXTENDED_KEY_USAGE L'utilizzo esteso della chiave per il certificato. Se specificati, i valori consentiti sono serverAuth e clientAuth.
    KEY_ALGORITHYM L'algoritmo della chiave privata utilizzato per questo certificato. I valori consentiti sono RSA, Ed25519 o ECDSA. Se la dimensione non viene fornita, il valore predefinito è 256 per ECDSA e 2048 per RSA. La dimensione della chiave viene ignorata per Ed25519.
    KEY_SIZE La dimensione, in bit, della chiave privata per questo certificato dipende dall'algoritmo. RSA consente 2048, 3072, 4096 o 8192 (valore predefinito 2048). ECDSA consente 256, 384 o 521 (valore predefinito 256). Ed25519 ignora le dimensioni.
    ACME_ENABLED Se impostato su true, la CA viene eseguita in modalità ACME e restituisce l'URL del server ACME. Puoi quindi utilizzare il client e il protocollo ACME per gestire i certificati.
  2. Applica la risorsa personalizzata alla tua istanza Distributed Cloud:

    kubectl apply -f subca.yaml --kubeconfig MANAGEMENT_API_SERVER_KUBECONFIG
    

    Sostituisci MANAGEMENT_API_SERVER_KUBECONFIG con il percorso del file kubeconfig del server API di gestione.

  3. Verifica l'idoneità della CA secondaria. La CA diventa pronta dopo circa 40 minuti:

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

    L'output è simile al seguente:

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

Crea una CA secondaria da una CA esterna

Questa CA secondaria supporta la firma dei certificati foglia con CA esterne o gestite dall'utente. Genera una CSR che gli utenti devono firmare.

  1. Crea una risorsa CertificateAuthority e salvala come file YAML denominato subca-external.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
    

    Sostituisci le seguenti variabili:

    Variabile Descrizione
    SUB_CA_NAME Il nome della CA secondaria.
    USER_PROJECT_NAMESPACE L'ID progetto in cui vuoi importare l'immagine.
    COMMON_NAME Il nome comune del certificato CA.
    DURATION La durata richiesta del certificato CA. Specifica una durata in ore (ad esempio, 1000h). Unità come giorni (d) o anni (y) non sono supportate.
    SECRET_NAME Il nome del secret di Kubernetes che contiene la chiave privata e il certificato CA firmato.

    Le seguenti variabili sono valori facoltativi:

    Variabile Descrizione
    RENEW_BEFORE Il tempo di rotazione prima della scadenza del certificato CA.
    ORGANIZATION Organizzazione da utilizzare nel certificato.
    ORGANIZATIONAL_UNITS Unità organizzative da utilizzare nel certificato.
    COUNTRIES Paesi da utilizzare nel certificato.
    LOCALITIES Città da utilizzare nel certificato.
    PROVINCES Stato o provincia da utilizzare nel certificato.
    STREET_ADDRESSES Indirizzi da utilizzare nel certificato.
    POSTAL_CODES Codici postali da utilizzare nel certificato.
    EXTENDED_KEY_USAGE L'utilizzo esteso della chiave per il certificato. Se specificati, i valori consentiti sono serverAuth e clientAuth.
    KEY_ALGORITHYM L'algoritmo della chiave privata utilizzato per questo certificato. I valori consentiti sono RSA, Ed25519 o ECDSA. Se la dimensione non viene fornita, il valore predefinito è 256 per ECDSA e 2048 per RSA. La dimensione della chiave viene ignorata per Ed25519.
    KEY_SIZE La dimensione, in bit, della chiave privata per questo certificato dipende dall'algoritmo. RSA consente 2048, 3072, 4096 o 8192 (valore predefinito 2048). ECDSA consente 256, 384 o 521 (valore predefinito 256). Ed25519 ignora le dimensioni.
    ACME_ENABLED Se impostato su true, la CA viene eseguita in modalità ACME e restituisce l'URL del server ACME. Puoi quindi utilizzare il client e il protocollo ACME per gestire i certificati.
  2. Applica la risorsa personalizzata alla tua istanza Distributed Cloud:

    kubectl apply -f subca-external.yaml --kubeconfig MANAGEMENT_API_SERVER_KUBECONFIG
    
  3. Viene generata una CSR per la CA secondaria all'interno del server API di gestione di GDC. Devi scaricare la CSR e firmarla. Una volta firmato, puoi caricare il certificato firmato nel server dell'API di gestione di GDC.

  4. Raccogli le richieste di firma del certificato (CSR) dal tuo ambiente Distributed Cloud:

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

    Il comando genera un file CSR denominato sub_ca.csr nella directory corrente. Questo file contiene un CSR per un certificato CA X.509.

  5. Utilizza la CA radice del cliente per richiedere certificati CA firmati per il file sub_ca.csr.

  6. Per una richiesta di firma del certificato approvata, devi ottenere un certificato CA firmato dalla CA principale del cliente. Archivia il certificato nel file sub_ca.crt nella directory attuale.

  7. Se applicabile, ottieni il certificato CA radice del cliente e memorizzalo nel file ca.crt nella directory corrente.

  8. Verifica il nome comune (CN) del certificato CA:

    openssl x509 -noout -subject -in sub_ca.crt
    

    Se la tua configurazione richiede estensioni dei nomi alternativi del soggetto (SAN), verifica le estensioni SAN nel certificato:

    openssl x509 -text -noout -in sub_ca.crt | grep -A 1 "Subject Alternative Name"
    
  9. Genera il file spec per applicare la patch alla risorsa CertificateAuthority:

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

    I contenuti del file patch.txt sono simili ai seguenti:

    spec:
      caCertificate:
        externalCA:
          signedCertificate:
            certificate: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSURSekNDQ…
            ca: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSURRVENDQ…
    
  10. Modifica il campo spec della risorsa CertificateAuthority:

    kubectl patch certificateauthority SUB_CA_NAME -n USER_PROJECT_NAMESPACE--patch-file patch.txt --type='merge'
    
  11. Verifica l'idoneità della CA secondaria Bring Your Own (BYO). In genere, sono necessari circa 40 minuti affinché la CA sia pronta:

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

    L'output è simile al seguente:

    {
      "lastTransitionTime": "2024-04-30T22:10:50Z",
      "message": "Certificate authority is ready for use",
      "observedGeneration": 3,
      "reason": "Ready",
      "status": "True",
      "type": "Ready"
    }
    
  12. Verifica la data di scadenza dei certificati CA firmati:

    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
    

Elenca le CA

Per elencare tutte le risorse di Certificate Authority Service nella tua istanza Distributed Cloud con air gap, segui questi passaggi:

Utilizza il parametro certificateauthorities per elencare tutte le risorse CertificateAuthority:

   kubectl --kubeconfig MANAGEMENT_API_SERVER_KUBECONFIG -n USER_PROJECT_NAMESPACE get certificateauthorities

L'output è simile al seguente:

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