Utilizzare autorità di certificazione del cluster personalizzate

Google Distributed Cloud ti consente di utilizzare le tue autorità di certificazione (CA) per emettere e firmare certificati che autenticano e criptano la comunicazione tra i componenti del cluster. L'utilizzo di CA personalizzate ti consente di controllare direttamente il trust radice, i parametri dell'algoritmo crittografico, nonché la profondità e lo scopo dei certificati subordinati.

Puoi applicare CA personalizzate durante la creazione del cluster (solo metodo bmctl) o la rotazione delle CA nei cluster di amministrazione, utente, ibridi e autonomi.

Prerequisiti

Devi fornire una coppia di file di certificato e chiave CA per ciascuna delle seguenti CA del cluster richieste:

• CA etcd: il certificato CA etcd protegge la comunicazione dal server API Kubernetes alle repliche etcd e anche la comunicazione tra le repliche etcd.

• CA del cluster: il certificato per la CA del cluster protegge la comunicazione tra il server API Kubernetes e tutti i client API Kubernetes interni. I client includono kubelet, il gestore dei controller e lo scheduler.

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

È tua responsabilità preparare le tue CA radice in base alle seguenti regole:

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

• Per il certificato, ti consigliamo di utilizzare il formato Distinguished Encoding Rules (DER) (consulta la raccomandazione X.690 per le regole di codifica ASN.1). Il file del certificato deve contenere dati codificati in 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 codificati in base64 preceduti da ‑‑‑‑BEGIN RSA PRIVATE KEY‑‑‑‑ e seguiti da ‑‑‑‑END RSA PRIVATE KEY‑‑‑‑.

• Per ridurre al minimo la potenziale interruzione del cluster, le CA personalizzate non devono scadere prima di cinque anni. Ti consigliamo un periodo di scadenza più lungo, ad esempio da 10 a 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 archivi i file. Ti consigliamo di inserire i file in una directory esistente utilizzata per certificati e chiavi. Ad esempio, puoi archiviare i file in ~/baremetal/bmctl-workspace/.sa-keys insieme alle chiavi del account di servizio.

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

Utilizza 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 personalizzata durante la creazione del cluster, hai due opzioni per specificare le CA del cluster personalizzate nel file di configurazione del cluster:

• Specifica i percorsi dei file dei certificati CA e dei file delle chiavi private
• Specifica solo i percorsi dei file delle chiavi private

Quando 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 delle chiavi private corrispondenti e l'estensione del file .crt. Ad esempio, se il percorso della chiave privata è /custom-ca/cluster_ca.key, bmctl si aspetta che il percorso del certificato sia /custom-ca/cluster_ca.crt.

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

Nota: quando crei un cluster utente con bmctl, in genere rimuovi la sezione delle credenziali del file di configurazione del cluster. Per specificare CA del cluster personalizzate quando crei un cluster utente, specifica solo i percorsi del certificato e della chiave privata della CA del cluster personalizzata nella sezione delle credenziali.

Esempio 1: specifica i percorsi del certificato e della chiave

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

Nota: per un cluster utente, rimuovi i percorsi del account di servizio e della chiave 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 del cluster mostra come specificare solo i percorsi dei file della chiave. In questo esempio, i file delle chiavi private della CA si trovano nella stessa directory dei file delle chiavi JSON dei account di servizio. Anche i file dei certificati CA corrispondenti devono trovarsi nella directory /.sa-keys. I file dei certificati hanno lo stesso nome file dei file delle chiavi, ma con l'estensione .crt. Pertanto, il file del certificato CA etcd ha il nome etcd_ca.crt.

Nota: per un cluster utente, rimuovi i percorsi del account di servizio e della chiave 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: riutilizza una singola coppia di file di certificato e chiave CA

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

Nota: per un cluster utente, rimuovi i percorsi del account di servizio e della chiave 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 delle CA

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

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

Esempio 1: specifica 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 cui vuoi ruotare le CA.
• ADMIN_KUBECONFIG: il percorso del file kubeconfig del cluster di amministrazione. Per i cluster con gestione autonoma, questo file è 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 della 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 della CA etcd.
• FRONT_PROXY_CA_CERT_PATH: il percorso del file del certificato del proxy front-end.
• FRONT_PROXY_CA_KEY_PATH: il percorso del file della chiave privata del proxy front-end.

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 cui vuoi ruotare le CA.
• ADMIN_KUBECONFIG: il percorso del file kubeconfig del cluster di amministrazione. Per i cluster con gestione autonoma, questo file è il file kubeconfig del cluster.
• CLUSTER_CA_KEY_PATH: il percorso del file della chiave privata della CA del cluster.
• ETCD_CA_KEY_PATH: il percorso del file della chiave privata della CA etcd.
• FRONT_PROXY_CA_KEY_PATH: il percorso del file della chiave privata del proxy front-end.

CA intermedie

Anteprima

Questo prodotto o funzionalità sono soggetti ai "Termini dell'offerta pre-GA" nella sezione dei Termini di servizio generali dei Termini specifici dei servizi. I prodotti e le funzionalità pre-GA sono disponibili "così come sono" e potrebbero avere un supporto limitato. Per ulteriori informazioni, consulta le descrizioni della fase di lancio.

I cluster della versione 1.29 supportano l'utilizzo di CA intermedie come funzionalità in anteprima. Questa funzionalità non è 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 principale per le CA personalizzate, per utilizzare le CA intermedie devi preparare tre set di CA. Ogni CA è costituita da un file di certificato CA e dal file della chiave privata corrispondente. Devi fornire una coppia di file di certificato CA e chiave per ciascuna delle seguenti CA del cluster richieste:

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

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

Quando utilizzi CA intermedie, il file del certificato CA deve contenere l'intera catena di certificati, che include i certificati delle 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 principale in basso), l'ordine indica quanto segue:

• La CA radice ha firmato il certificato CA della CA intermedia A
• La CA intermedia A ha firmato il certificato CA della CA intermedia B
• La catena continua fino al certificato CA intermedio Y finale, firmato dalla CA intermedia 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 Intermediate-Y deve essere trasmessa insieme alle catene di certificati CA nello stesso modo di 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 conteggio dei certificati nel secret della 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