Utilizzare autorità di certificazione dei cluster personalizzate

Le autorità di certificazione (CA) del cluster emettono e firmano i certificati per abilitare la crittografia e l'autenticazione 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 il tuo certificato autorità con Google Distributed Cloud. L'utilizzo di CA dei cluster personalizzati offre controllo sull'emissione e la gestione dei certificati dei cluster. Puoi anche controllare la attendibilità, i parametri dell'algoritmo di crittografia, la profondità dei certificati subordinati e la loro finalità.

Per utilizzare CA personalizzate, fornisci CA radice, costituite da un file del certificato CA e dal corrispondente file della chiave privata. Devi fornire un certificato CA e un file della chiave per ciascuna delle seguenti CA del cluster richieste:

• etcd CA: il certificato per 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 dell'API Kubernetes e tutti i client dell'API Kubernetes interni. I client includono kubelet, gestore del controller e scheduler.

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

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

Applica le coppie di chiavi del certificato durante la creazione del cluster (solo metodo bmctl) e la rotazione della CA. CA del 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 personalizzate quando crei un cluster utente, specifica solo i percorsi del certificato della CA del cluster personalizzato e della chiave privata nella sezione delle credenziali.

Prerequisiti

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

• Le CA personalizzate sono CA radice, ciascuna costituita da un file del certificato autofirmato e da un file della chiave privata.

• Per il certificato, ti consigliamo di utilizzare Formato DER (Distinguiled Encoding Rules) (consulta il suggerimento 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 seguito 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 siano sulla workstation di amministrazione in cui esegui i comandi bmctl.

• L'utente che esegue i comandi bmctl deve disporre dell'accesso alla directory in cui memorizzi 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 e gestire le chiavi account di servizioo.

• 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 cluster personalizzato durante del cluster, hai due opzioni per specificare le CA del cluster personalizzate il file di configurazione del cluster:

• Specifica i percorsi per i file del certificato CA e per i file della chiave privata
• Specifica solo i percorsi per i file di chiavi private

Quando specifichi solo le chiavi private, bmctl cerca la CA corrispondente di certificati nella stessa directory. I file dei certificati devono avere lo stesso del file corrispondente ai file della chiave privata corrispondenti e all'estensione del file .crt. Per Ad esempio, se il percorso della chiave privata è /custom-ca/cluster_ca.key, allora 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 di configurazione del deployment, come mostrato nei seguenti esempi.

Esempio 1: specifica i percorsi del certificato e della chiave

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

Nota: per un cluster utente, rimuovi l'account di servizio e i percorsi delle chiavi SSH da alla 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 CA si trovano nella stessa directory dei file chiave JSON dell'account di servizio. Anche i file dei certificati CA corrispondenti devono trovarsi nella directory /.sa-keys. File di certificati hanno lo stesso nome file dei file chiave, ma con estensione .crt. Quindi, Il file del certificato CA etcd ha il nome etcd_ca.crt.

Nota: per un cluster utente, rimuovi l'account di servizio e i percorsi delle chiavi SSH da alla 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 del cluster mostra come specificare solo i percorsi dei file della 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 Directory /custom-ca. Seguendo la convenzione di denominazione, il certificato CA il nome file è custom_ca.crt.

Nota: per un cluster di utenti, rimuovi i percorsi dell'account di servizio e 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 percorsi per il certificato CA del cluster personalizzato e i file di chiave privata. Le opzioni disponibili sono simili a quelle per specificare le CA di cluster personalizzate durante la creazione del cluster. Quando esegui il comando bmctl update credentials certificate-authorities rotate, hai le seguenti opzioni:

• Specifica i percorsi sia per i file dei certificati CA personalizzati che per quelli privati e i file chiave.
• Specifica solo i percorsi per i 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 un'estensione .crt.
• Riutilizza una coppia di certificato e chiave CA specificando lo stesso certificato e la stessa chiave per più di una CA del cluster.
• Ometti gli argomenti per i percorsi 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: 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 girare le CA.
• ADMIN_KUBECONFIG: il percorso del file kubeconfig del cluster di amministrazione. Per i cluster autogestiti, questo file è il file kubeconfig del cluster.
• CLUSTER_CA_CERT_PATH: il percorso della CA del cluster del certificato.
• CLUSTER_CA_KEY_PATH: il percorso della CA del cluster privata chiave.
• ETCD_CA_CERT_PATH: il percorso del file del certificato CA etcd.
• ETCD_CA_KEY_PATH: il percorso della chiave privata CA etcd .
• FRONT_PROXY_CA_CERT_PATH: il percorso del file del certificato del proxy anteriore.
• FRONT_PROXY_CA_KEY_PATH: il percorso del file della chiave privata del proxy anteriore.

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 girare le CA.
• ADMIN_KUBECONFIG: il percorso del file kubeconfig del cluster di amministrazione. Per i cluster a gestione autonoma, questo file è l'agente del cluster kubeconfig.
• 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 proxy front-proxy chiave privata.

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'utilizzo di CA intermedie come funzionalità di anteprima. Questa funzionalità non è nella stessa fase di lancio per tutte le versioni del prodotto 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 devi preparare tre insiemi di CA. Ogni CA è costituita da un file del certificato CA e dal corrispondente file della chiave privata. Devi fornire un certificato CA e un 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 di certificato unica per ogni CA puoi riutilizzare una coppia di chiavi certificato per più di una delle CA specificando gli stessi percorsi di file nella configurazione della CA.

Quando utilizzi CA intermedie, il file del certificato CA deve contenere l'intera che include certificati provenienti dalle CA intermedie fino la CA radice. I certificati sono elencati nell'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 della CA intermedia A
• La CA intermedia A ha firmato il certificato della CA intermedia B
• La catena continua fino al certificato CA intermedio-Y finale, che è stato 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 intermedio Y deve essere passata insieme alle catene di certificati CA nello stesso modo in cui avviene 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, ispeziona il certificato conteggio 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