Certificati TLS
Configura i certificati TLS esterni per IBM Bob on-premises in modo che i client bob-ide e bob-shell possano connettersi in modo sicuro.
Bob espone le sue API tramite HTTPS. Prima che gli utenti possano connettersi usando bob-ide o bob-shell, il certificato dell'endpoint deve essere considerato attendibile dalle workstation client.
Usa un certificato emesso da un'autorità di certificazione enterprise o pubblicamente attendibile quando possibile. Questo elimina la necessità di distribuire certificati CA specifici di Bob alle workstation degli sviluppatori.
Per ripristinare il certificato self-signed predefinito in qualsiasi momento, esegui bobctl reset-route. Questo rimuove spec.externalCertificate dal repository dei certificati Bob e l'operator restituisce l'endpoint esterno a cert-manager.
Usa questo approccio quando è disponibile un certificato da una PKI aziendale o da un'autorità di certificazione pubblicamente attendibile.
Prima di richiedere o generare un certificato, identifica ogni hostname esposto da Bob. Tutti gli hostname devono essere inclusi come Subject Alternative Name (SAN) nel certificato.
Recuperare gli hostname ingress
Esegui il seguente comando per elencare tutti gli hostname ingress di Bob:
oc get ingress -n <instance-namespace> \
-o jsonpath='{range .items[*]}{range .spec.rules[*]}{.host}{"\n"}{end}{end}'Registra gli hostname restituiti — sono richiesti quando si ordinano o generano certificati.
Verificare i requisiti del certificato
Assicurati che il certificato soddisfi i seguenti requisiti prima di applicarlo a Bob:
- La chiave privata non è crittografata.
- Il certificato contiene la catena di certificati completa.
- Tutti gli hostname ingress di Bob sono inclusi come voci SAN.
- Il certificato e la chiave sono forniti in formato PEM.
Creare il secret del certificato
Crea un secret Kubernetes contenente il certificato e la chiave privata:
oc create secret generic my-tls-secret \
--from-file=tls.crt=tls.crt \
--from-file=tls.key=tls.key \
--from-file=ca.crt=ca.crt \
-n <instance-namespace>Per aggiornare un secret esistente:
oc create secret generic my-tls-secret \
--from-file=tls.crt=tls.crt \
--from-file=tls.key=tls.key \
--from-file=ca.crt=ca.crt \
-n <instance-namespace> \
--dry-run=client -o yaml | oc apply -f -Applicare il certificato
Configura Bob per utilizzare il certificato:
./bobctl setup-route --tls-secret my-tls-secret| Parametro | Descrizione |
|---|---|
--tls-secret | Specifica il secret che contiene il certificato e la chiave privata. |
--no-wait | Restituisce immediatamente senza attendere la riconciliazione. |
--dry-run | Valida la configurazione senza applicare le modifiche. |
Verificare il certificato
Verifica che il certificato atteso venga servito:
echo | openssl s_client \
-connect <hostname>:443 \
-servername <hostname> 2>/dev/null \
| openssl x509 -noout -issuer -subject -datesVerifica che:
- L'emittente sia corretto.
- L'hostname sia presente nell'elenco SAN.
- Le date di validità del certificato siano corrette.
Usa questa procedura per generare un certificato firmato da un'autorità di certificazione privata o interna e configurare Bob per usarlo per il traffico HTTPS esterno.
Generare un certificato CA
Genera una chiave privata e un certificato self-signed per l'autorità di certificazione:
openssl genrsa -out ca.key 4096
openssl req -x509 -new -nodes \
-key ca.key \
-sha256 \
-days 365 \
-out ca.crt \
-subj "/CN=<BOB_HOSTNAME> CA"Questo crea ca.key e ca.crt.
Bob si aspetta che il certificato CA sia denominato ca.crt quando è incluso nel secret Kubernetes. Se stai usando un certificato CA esistente, rinominalo in ca.crt prima di creare il secret.
Generare una chiave privata del server
Genera una chiave privata non crittografata per il certificato dell'endpoint Bob:
openssl genrsa -out tls.key 4096Se la chiave privata è crittografata con una passphrase, rimuovi la passphrase prima di continuare:
openssl rsa -in encrypted.key -out tls.keyCreare un file di configurazione SAN
Crea un file denominato san.cnf e sostituisci gli hostname segnaposto con gli hostname ingress recuperati in precedenza:
[req]
distinguished_name = req_distinguished_name
req_extensions = v3_req
prompt = no
[req_distinguished_name]
CN = <BOB_HOSTNAME_1>
[v3_req]
subjectAltName = @alt_names
[alt_names]
DNS.1 = <BOB_HOSTNAME_1>
DNS.2 = <BOB_HOSTNAME_2>
DNS.3 = <BOB_HOSTNAME_3>Aggiungi o rimuovi le voci DNS.* secondo necessità in modo che tutti gli hostname ingress di Bob siano inclusi.
Generare una richiesta di firma del certificato
openssl req \
-new \
-key tls.key \
-out tls.csr \
-config san.cnfFirmare il certificato
openssl x509 \
-req \
-in tls.csr \
-CA ca.crt \
-CAkey ca.key \
-CAcreateserial \
-out tls.crt \
-days 365 \
-extensions v3_req \
-extfile san.cnfCreare il secret TLS
Per i certificati emessi da un'autorità di certificazione privata o aziendale:
oc create secret generic my-tls-secret \
--from-file=tls.crt=/path/to/tls.crt \
--from-file=tls.key=/path/to/tls.key \
--from-file=ca.crt=/path/to/ca.crt \
-n <instance-namespace>Per i certificati pubblicamente attendibili:
oc create secret tls my-tls-secret \
--cert=/path/to/tls.crt \
--key=/path/to/tls.key \
-n <instance-namespace>Applicare il certificato
Configura Bob per utilizzare il secret TLS:
./bobctl setup-route --tls-secret my-tls-secretbobctl valida il secret, aggiorna la configurazione di Bob e attende il completamento della riconciliazione.
| Parametro | Descrizione |
|---|---|
--tls-secret <secret> | Specifica il secret che contiene il certificato TLS e la chiave privata. |
--no-wait | Restituisce immediatamente senza attendere il completamento della riconciliazione. |
--dry-run | Valida la configurazione senza applicare le modifiche. |
Se ca.crt non è incluso nel secret, bobctl visualizza un avviso. Questo è previsto quando il certificato è emesso da un'autorità di certificazione già considerata attendibile dalle workstation client.
Verificare il certificato
Verifica che Bob stia servendo il certificato atteso:
echo | openssl s_client \
-connect <BOB_HOSTNAME_1>:443 \
-servername <BOB_HOSTNAME_1> 2>/dev/null \
| openssl x509 -noout -issuer -subject -datesVerifica che:
- L'emittente corrisponda all'autorità di certificazione prevista.
- Il certificato contenga le voci hostname attese.
- Le date di validità del certificato siano corrette.
Se l'autorità di certificazione emittente non è considerata attendibile dalle workstation degli sviluppatori, distribuisci il certificato CA agli utenti prima che si connettano a Bob usando bob-ide o bob-shell.
Se non è configurato alcun certificato esterno, Bob usa un certificato self-signed gestito da cert-manager. In questa configurazione, gli utenti devono considerare attendibile il certificato CA di Bob prima di connettersi.
Determinare la configurazione del certificato
Verifica se l'endpoint esterno Bob sta usando un certificato self-signed:
oc get secret bob-external-tls -n <instance-namespace> \
-o jsonpath='{.data.tls\.crt}' \
| base64 -d \
| openssl x509 -noout -issuer- Se l'emittente è
CN=Bob Internal CA, il cluster sta usando il certificato self-signed predefinito. Continua con il passaggio successivo. - Se l'emittente è un'autorità di certificazione enterprise o pubblicamente attendibile, non è richiesta alcuna configurazione del certificato lato client. Vedere Gestione utenti.
Esportare il certificato CA
./bobctl get-ca-cert --output bob-ca.crtDistribuire il certificato CA
Fornisci il file bob-ca.crt esportato agli utenti e istruiscili ad aggiungerlo al trust store del sistema operativo. Gli utenti possono stabilire connessioni HTTPS attendibili dopo aver importato il certificato CA di Bob.