Usa autorità di certificazione cluster personalizzate

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

Per utilizzare CA personalizzate, devi fornire le CA radice, costituite da un file di certificato CA e il file della chiave privata corrispondente. Devi fornire una coppia di file di certificati CA/chiave per ognuna delle seguenti CA del cluster obbligatorie:

etcd CA: il certificato per il certificato CA etcd protegge la comunicazione dal server API Kubernetes alle repliche etcd, nonché la comunicazione tra le repliche etcd.
CA del cluster: il certificato della CA del cluster protegge le comunicazioni tra il server API Kubernetes e tutti i client API Kubernetes interni. I client includono kubelet, il gestore del controller e lo scheduler.
front-proxy CA: il certificato per la CA front-proxy protegge la comunicazione con le API aggregate.

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

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

Prerequisiti

Sei responsabile della preparazione delle tue CA principali 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.
Le CA intermedie e subordinate non sono supportate.
Per il certificato, ti consigliamo di utilizzare il formato DER (Distinguived Encoding Rules) (consulta il consiglio 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 PKCS (Public-Key Cryptography Standards) #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 le potenziali interruzioni dei cluster, le CA personalizzate non devono scadere prima di cinque anni. 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 nella workstation di amministrazione in cui esegui l'interfaccia a riga di comando bmctl.
L'utente che esegue i comandi bmctl deve avere accesso alla directory in cui sono archiviati i file. Ti consigliamo di posizionare 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 dell'account di servizio.
L'utente che esegue i comandi bmctl deve avere 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 personalizzato 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 di chiave privata

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 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 sono specificati nella sezione delle credenziali del file di configurazione, come mostrato negli esempi seguenti.

Esempio 1: specifica i percorsi del certificato e delle chiavi

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

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: specificare solo i percorsi delle chiavi private

Il seguente estratto di un file di configurazione del cluster mostra come specificare solo i percorsi dei file delle chiavi. In questo esempio, i file della chiave privata della CA si trovano nella stessa directory dei file di 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 un'estensione .crt. Pertanto, il file del certificato CA etcd ha il nome etcd_ca.crt.

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 e chiavi CA

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

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 i file del certificato CA e della chiave privata del cluster personalizzato. Le opzioni disponibili sono simili alle opzioni per specificare 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 di chiavi private CA personalizzate. 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 certificati/chiavi CA specificando lo stesso certificato e gli stessi percorsi delle chiavi per più CA del cluster.
Ometti gli argomenti per i percorsi CA personalizzati. Se non specifichi percorsi delle CA personalizzati quando ruoti le CA, GKE su Bare Metal 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 il quale vuoi ruotare le CA.
ADMIN_KUBECONFIG: il percorso del file kubeconfig del cluster di amministrazione. Per i cluster gestiti autonomamente, 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 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 front-proxy.
FRONT_PROXY_CA_KEY_PATH: il percorso del file della chiave privata front-proxy.

Esempio 2: specificare 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 gestiti autonomamente, questo file è 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 front-proxy.