Usa autorità di certificazione cluster personalizzate

Le autorità di certificazione (CA) del cluster emettono e firmano i certificati per abilitare autenticazione e crittografia sicure tra i componenti del cluster. Per impostazione predefinita, in Google Distributed Cloud, l'API Cluster crea le CA del cluster quando crei un nuovo cluster. Questo documento descrive come puoi utilizzare le tue autorità di certificazione con Google Distributed Cloud. L'uso di CA dei cluster personalizzate offre un maggiore controllo sull'emissione e la gestione dei certificati cluster. Puoi anche controllare l'attendibilità, i parametri dell'algoritmo di crittografia, il livello di profondità dei certificati subordinati e il loro scopo.

Per utilizzare CA personalizzate, devi fornire le CA radice, composte da un file di certificato CA e dal file di chiave privata corrispondente. Fornisci un certificato CA e una coppia di file della chiave per ciascuna delle seguenti CA del cluster richieste:

• Ca etcd: il certificato per il certificato CA etcd protegge le comunicazioni tra il server API Kubernetes e le repliche etcd, oltre a proteggere le comunicazioni tra le repliche etcd.

• CA cluster: il certificato per la CA del cluster protegge le comunicazioni tra il server API di Kubernetes e tutti i client API interni di Kubernetes. Tra i client ci sono kubelet, gestore del controller e scheduler.

• front-proxy CA: il certificato per la CA front-proxy protegge la comunicazione con le API aggregate.

Puoi fornire una coppia di chiave-certificato univoca per ogni CA oppure puoi riutilizzare una coppia di chiavi di certificato per più di una delle CA.

Puoi applicare le coppie di chiavi di certificato durante la creazione del cluster (solo metodo bmctl) e la rotazione CA. La funzionalità CA cluster personalizzato è compatibile con tutti i tipi di cluster: amministratore, utente, ibrido e autonomo.

Nota: quando crei un cluster utente con bmctl, in genere rimuovi la sezione delle credenziali del file di configurazione del cluster. Per specificare le CA del cluster personalizzato quando crei un cluster utente, specifica solo il certificato CA del cluster personalizzato e i percorsi delle chiavi private nella sezione delle credenziali.

Prerequisiti

Sei responsabile della preparazione delle tue CA radice in base alle seguenti regole:

• Le CA personalizzate sono CA radice, ognuna composta da un file di certificato autofirmato e un file di chiave privata.

• Per il certificato, ti consigliamo di utilizzare il formato DER (Distinguiled Encoding Rules) (consulta il consiglio X.690 per le regole di codifica ASN.1). Il file del certificato deve contenere dati con codifica Base64, preceduti da ‑‑‑‑‑BEGIN CERTIFICATE‑‑‑‑‑ e seguiti da ‑‑‑‑END CERTIFICATE‑‑‑‑‑.

• Per la chiave privata, ti consigliamo di utilizzare il formato Public-Key Cryptography Standards (PKCS) #1. Il file della chiave deve contenere dati con codifica Base64, preceduti da ‑‑‑‑BEGIN RSA PRIVATE KEY‑‑‑‑ e seguiti da ‑‑‑‑END RSA PRIVATE KEY‑‑‑‑.

• Per ridurre al minimo le potenziali interruzioni del cluster, le CA personalizzate non dovrebbero scadere prima di cinque anni. Ti consigliamo un periodo di scadenza più lungo, ad esempio 10-30 anni.

• Assicurati che i file del certificato e della chiave si trovino sulla workstation di amministrazione in cui esegui i comandi bmctl.

• L'utente che esegue i comandi bmctl deve avere accesso alla directory in cui sono archiviati i file. Ti consigliamo di inserire i file in una directory esistente utilizzata per i certificati e le chiavi. Ad esempio, puoi archiviare i file in ~/baremetal/bmctl-workspace/.sa-keys insieme alle chiavi dell'account di servizio.

• L'utente che esegue i comandi bmctl deve avere accesso in lettura ai file.

Usa una CA personalizzata durante la creazione del cluster

Quando crei un cluster con bmctl, devi prima aggiornare il file di configurazione del cluster per descrivere le funzionalità e le impostazioni del cluster. Per utilizzare la funzionalità CA del cluster personalizzato durante la creazione del cluster, hai due opzioni per specificare le CA del cluster personalizzato nel file di configurazione del cluster:

• Specifica i percorsi sia dei file dei certificati CA sia dei file delle chiavi private
• Specifica solo i percorsi per i file di chiavi private

Se specifichi solo le chiavi private, bmctl cerca i file dei certificati CA corrispondenti nella stessa directory. I file dei certificati devono avere lo stesso nome dei file di chiave privata corrispondenti e l'estensione del file .crt. Ad esempio, se il percorso della chiave privata è /custom-ca/cluster_ca.key, bmctl prevede che il percorso del certificato sia /custom-ca/cluster_ca.crt.

In entrambi i casi, i percorsi vengono specificati nella sezione delle credenziali del file di configurazione, come mostrato negli esempi seguenti.

Esempio 1: specificare i percorsi dei certificati e delle chiavi

Il seguente estratto di un file di configurazione di cluster mostra come specificare i percorsi dei file del certificato e della chiave per ogni CA del cluster. In questo esempio, il certificato CA e i file delle chiavi si trovano nella stessa directory dei file delle chiavi JSON dell'account di servizio.

Nota: per un cluster utente, devi rimuovere l'account di servizio e i percorsi delle chiavi SSH dalla sezione delle credenziali.

gcrKeyPath: bmctl-workspace/.sa-keys/myproject-anthos-baremetal-gcr.json
...
cloudOperationsServiceAccountKeyPath: bmctl-workspace/.sa-keys/myproject-anthos-baremetal-cloud-ops.json
clusterCACertPath: bmctl-workspace/.sa-keys/cluster_ca_cert.pem
clusterCAPrivateKeyPath: bmctl-workspace/.sa-keys/cluster_ca_key.pem
etcdCACertPath: bmctl-workspace/.sa-keys/etcd_ca_cert.pem
etcdCAPrivateKeyPath: bmctl-workspace/.sa-keys/etcd_ca_key.pem
frontProxyCACertPath: bmctl-workspace/.sa-keys/front_proxy_ca_cert.pem
frontProxyCAPrivateKeyPath: bmctl-workspace/.sa-keys/front_proxy_ca_key.pem
---
apiVersion: v1
kind: Namespace
metadata:
  name: cluster-admin-test
---
apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
...

Esempio 2: specifica solo i percorsi delle chiavi private

Il seguente estratto di un file di configurazione di cluster mostra come specificare solo i percorsi dei file chiave. In questo esempio, i file delle chiavi private CA si trovano nella stessa directory dei file delle chiavi JSON dell'account di servizio. Anche i file dei certificati CA corrispondenti devono trovarsi nella directory /.sa-keys. I file dei certificati hanno lo stesso nome dei file della chiave, ma con estensione .crt. Quindi, il file del certificato CA etcd ha il nome etcd_ca.crt.

Nota: per un cluster utente, devi rimuovere l'account di servizio e i percorsi delle chiavi SSH dalla sezione delle credenziali.

gcrKeyPath: bmctl-workspace/.sa-keys/myproject-anthos-baremetal-gcr.json
...
cloudOperationsServiceAccountKeyPath: bmctl-workspace/.sa-keys/myproject-anthos-baremetal-cloud-ops.json
clusterCAPrivateKeyPath: bmctl-workspace/.sa-keys/cluster_ca_key.pem
etcdCAPrivateKeyPath: bmctl-workspace/.sa-keys/etcd_ca_key.pem
frontProxyCAPrivateKeyPath: bmctl-workspace/.sa-keys/front_proxy_ca_key.pem
---
apiVersion: v1
kind: Namespace
metadata:
  name: cluster-admin-test
---
apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
...

Esempio 3: riutilizzare una singola coppia di file di certificati CA e di chiave

Il seguente estratto di un file di configurazione di cluster mostra come specificare solo i percorsi dei file chiave. In questo esempio, viene utilizzata una singola coppia chiave-certificato per tutte le CA del cluster. Il certificato CA e i file della chiave privata si trovano entrambi nella directory /custom-ca. Seguendo la convenzione di denominazione, il nome file del certificato CA è custom_ca.crt.

Nota: per un cluster utente, devi rimuovere l'account di servizio e i percorsi delle chiavi SSH dalla sezione delle credenziali.

gcrKeyPath: bmctl-workspace/.sa-keys/myproject-anthos-baremetal-gcr.json
...
cloudOperationsServiceAccountKeyPath: bmctl-workspace/.sa-keys/myproject-anthos-baremetal-cloud-ops.json
clusterCAPrivateKeyPath: /custom-ca/custom_ca.key
etcdCAPrivateKeyPath: /custom-ca/custom_ca.key
frontProxyCAPrivateKeyPath: /custom-ca/custom_ca.key
---
apiVersion: v1
kind: Namespace
metadata:
  name: cluster-admin-test
---
apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
...

Utilizza una CA personalizzata durante la rotazione della CA

Quando ruoti le CA, puoi specificare i percorsi per il certificato CA del cluster personalizzato e i file della chiave privata. Le opzioni disponibili sono simili a quelle per specificare CA del cluster personalizzate durante la creazione del cluster. Quando esegui il comando bmctl update credentials certificate-authorities rotate, sono disponibili le seguenti opzioni:

• Specifica i percorsi sia per i file dei certificati CA personalizzati sia per i file delle chiavi private.
• Specifica solo i percorsi per i file di chiavi private CA personalizzate. Il file del certificato CA corrispondente deve trovarsi nella stessa directory, avere lo stesso nome del file di chiave e avere un'estensione del file .crt.
• Riutilizza una coppia di certificato e chiave CA specificando lo stesso percorso di certificato e chiave per più CA del cluster.
• Ometti gli argomenti per i percorsi delle CA personalizzati. Se non specifichi percorsi CA personalizzati quando ruoti le CA, Google Distributed Cloud crea e utilizza la CA del cluster standard.

Esempio 1: specificare i percorsi del certificato CA e della chiave privata

bmctl update credentials certificate-authorities rotate \
    --cluster CLUSTER_NAME \
    --kubeconfig ADMIN_KUBECONFIG \
    --cluster-ca-cert-path=CLUSTER_CA_CERT_PATH \
    --cluster-ca-private-key-path=CLUSTER_CA_KEY_PATH \
    --etcd-ca-cert-path=ETCD_CA_CERT_PATH \
    --etcd-ca-private-key-path=ETCD_CA_KEY_PATH \
    --front-proxy-ca-cert-path=FRONT_PROXY_CA_CERT_PATH \
    --front-proxy-ca-private-key-path=FRONT_PROXY_CA_KEY_PATH

Sostituisci quanto segue:

• CLUSTER_NAME: il nome del cluster per il quale vuoi ruotare le CA.
• ADMIN_KUBECONFIG: il percorso del file kubeconfig del cluster di amministrazione. Per i cluster a gestione autonoma, questo è il file kubeconfig del cluster.
• CLUSTER_CA_CERT_PATH: il percorso del file del certificato CA del cluster.
• CLUSTER_CA_KEY_PATH: il percorso del file della chiave privata CA del cluster.
• ETCD_CA_CERT_PATH: il percorso del file del certificato CA etcd.
• ETCD_CA_KEY_PATH: il percorso del file della chiave privata CA etcd.
• FRONT_PROXY_CA_CERT_PATH: il percorso del file del certificato proxy-front.
• FRONT_PROXY_CA_KEY_PATH: il percorso del file della chiave privata proxy front-proxy.

Esempio 2: specifica solo i percorsi delle chiavi private

bmctl update credentials certificate-authorities rotate \
    --cluster CLUSTER_NAME \
    --kubeconfig ADMIN_KUBECONFIG \
    --cluster-ca-private-key-path=CLUSTER_CA_KEY_PATH \
    --etcd-ca-private-key-path=ETCD_CA_KEY_PATH \
    --front-proxy-ca-private-key-path=FRONT_PROXY_CA_KEY_PATH

Sostituisci quanto segue:

• CLUSTER_NAME: il nome del cluster per il quale vuoi ruotare le CA.
• ADMIN_KUBECONFIG: il percorso del file kubeconfig del cluster di amministrazione. Per i cluster a gestione autonoma, questo è il file kubeconfig del cluster.
• CLUSTER_CA_KEY_PATH: il percorso del file della chiave privata CA del cluster.
• ETCD_CA_KEY_PATH: il percorso del file della chiave privata CA etcd.
• FRONT_PROXY_CA_KEY_PATH: il percorso del file della chiave privata proxy front-proxy.

CA intermedie

Anteprima

Questo prodotto o funzionalità è soggetto ai "Termini delle Offerte pre-GA" nella sezione Termini generali del servizio dei Termini specifici del servizio. I prodotti e le funzionalità pre-GA sono disponibili "così come sono" e potrebbero avere un supporto limitato. Per saperne di più, consulta le descrizioni della fase di lancio.

I cluster della versione 1.29 supportano l'uso di CA intermedie come funzionalità di anteprima. Questa funzionalità non si trova nella stessa fase di lancio per tutte le versioni dei prodotti supportate:

• 1.29: Anteprima
• 1.28: Non disponibile
• 1.16: Non disponibile

Analogamente al requisito della CA radice per le CA personalizzate, per utilizzare le CA intermedie è necessario preparare tre set di CA. Ogni CA è composta da un file di certificato CA e dal file di chiave privata corrispondente. Fornisci un certificato CA e una coppia di file della chiave per ciascuna delle seguenti CA del cluster richieste:

• CA etcd
• CA del cluster
• CA front-proxy

Come per le CA radice, puoi fornire una coppia di chiavi certificato-certificato univoca per ogni CA oppure riutilizzare una coppia di chiavi certificato per più di una CA specificando gli stessi percorsi file nella configurazione della CA.

Se utilizzi CA intermedie, il file del certificato CA deve contenere l'intera catena di certificati, che include i certificati dalle CA intermedie fino alla CA radice. I certificati sono elencati in ordine inverso rispetto a come sono stati firmati, con l'ultimo certificato CA intermedio in alto e il certificato CA radice in basso.

Nell'esempio seguente (a partire dalla CA radice in basso), l'ordine indica quanto segue:

• La CA radice ha firmato il certificato CA intermedio-A
• La CA Intermedia-A ha firmato il certificato CA Intermedia-B
• La catena prosegue fino al certificato CA Intermediate-Y finale, che è stato firmato dalla CA Intermediate-X.

-----BEGIN CERTIFICATE-----
<Intermediate-Y CA CERT CONTENT>
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
<Intermediate-X CA CERT CONTENT>
-----END CERTIFICATE-----
...
-----BEGIN CERTIFICATE-----
<Intermediate-B CA CERT CONTENT>
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
<Intermediate-A CA CERT CONTENT>
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
<ROOT CA CERT CONTENT>
-----END CERTIFICATE----- 

Per continuare con questo esempio, la chiave privata associata al certificato CA intermedio Y deve essere trasmessa insieme alle catene di certificati CA come in una CA personalizzata.

-----BEGIN RSA PRIVATE KEY-----
<Intermediate-Y PRIVATE KEY CONTENT>
-----END RSA PRIVATE KEY-----

Per verificare se il cluster utilizza la CA intermedia, controlla il numero di certificati nel secret CA del cluster:

kubectl get secret CLUSTER_NAME-ca \
    --kubeconfig ADMIN_KUBECONFIG
    -n cluster-CLUSTER_NAME \
    -o jsonpath='{.data.tls\.crt}' | base64 --decode | grep "BEGIN CERTIFICATE" | wc -l