Certyfikaty TLS
Skonfiguruj zewnętrzne certyfikaty TLS dla IBM Bob on-premises, aby klienci bob-ide i bob-shell mogli bezpiecznie się łączyć.
Bob udostępnia swoje API przez HTTPS. Zanim użytkownicy będą mogli się połączyć przy użyciu bob-ide lub bob-shell, certyfikat punktu końcowego musi być zaufany przez stacje robocze klientów.
Używaj certyfikatu wydanego przez urząd certyfikacji przedsiębiorstwa lub publicznie zaufany, gdy tylko jest to możliwe. Eliminuje to konieczność dystrybucji certyfikatów CA specyficznych dla Bob do stacji roboczych programistów.
Aby w dowolnym momencie przywrócić domyślny certyfikat z podpisem własnym, uruchom bobctl reset-route. Usuwa to spec.externalCertificate z repozytorium certyfikatów Bob, a operator zwraca zewnętrzny punkt końcowy do cert-manager.
Użyj tego podejścia, gdy certyfikat jest dostępny od firmowego PKI lub publicznie zaufanego urzędu certyfikacji.
Przed zamówieniem lub wygenerowaniem certyfikatu zidentyfikuj każdą nazwę hosta udostępnianą przez Bob. Wszystkie nazwy hostów muszą być zawarte jako Subject Alternative Names (SAN) w certyfikacie.
Pobieranie nazw hostów ingress
Uruchom następujące polecenie, aby wyświetlić listę wszystkich nazw hostów ingress Bob:
oc get ingress -n <instance-namespace> \
-o jsonpath='{range .items[*]}{range .spec.rules[*]}{.host}{"\n"}{end}{end}'Zapisz zwrócone nazwy hostów — są one wymagane przy zamawianiu lub generowaniu certyfikatów.
Weryfikacja wymagań certyfikatu
Upewnij się, że certyfikat spełnia następujące wymagania przed zastosowaniem go w Bob:
- Klucz prywatny jest niezaszyfrowany.
- Certyfikat zawiera pełny łańcuch certyfikatów.
- Wszystkie nazwy hostów ingress Bob są zawarte jako wpisy SAN.
- Certyfikat i klucz są dostarczone w formacie PEM.
Tworzenie sekretu certyfikatu
Utwórz sekret Kubernetes zawierający certyfikat i klucz prywatny:
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>Aby zaktualizować istniejący sekret:
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 -Stosowanie certyfikatu
Skonfiguruj Bob tak, aby używał certyfikatu:
./bobctl setup-route --tls-secret my-tls-secret| Parametr | Opis |
|---|---|
--tls-secret | Określa sekret zawierający certyfikat i klucz prywatny. |
--no-wait | Zwraca wynik natychmiast bez oczekiwania na uzgadnianie. |
--dry-run | Weryfikuje konfigurację bez stosowania zmian. |
Weryfikacja certyfikatu
Sprawdź, czy oczekiwany certyfikat jest obsługiwany:
echo | openssl s_client \
-connect <hostname>:443 \
-servername <hostname> 2>/dev/null \
| openssl x509 -noout -issuer -subject -datesSprawdź, czy:
- Wystawca jest prawidłowy.
- Nazwa hosta jest obecna na liście SAN.
- Daty ważności certyfikatu są prawidłowe.
Użyj tej procedury, aby wygenerować certyfikat podpisany przez prywatny lub wewnętrzny urząd certyfikacji i skonfigurować Bob do używania go dla zewnętrznego ruchu HTTPS.
Generowanie certyfikatu CA
Wygeneruj klucz prywatny i certyfikat z podpisem własnym dla urzędu certyfikacji:
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"Tworzy to ca.key i ca.crt.
Bob oczekuje, że certyfikat CA będzie nazwany ca.crt, gdy jest zawarty w sekrecie Kubernetes. Jeśli używasz istniejącego certyfikatu CA, zmień jego nazwę na ca.crt przed utworzeniem sekretu.
Generowanie klucza prywatnego serwera
Wygeneruj niezaszyfrowany klucz prywatny dla certyfikatu punktu końcowego Bob:
openssl genrsa -out tls.key 4096Jeśli klucz prywatny jest zaszyfrowany hasłem, usuń hasło przed kontynuowaniem:
openssl rsa -in encrypted.key -out tls.keyTworzenie pliku konfiguracyjnego SAN
Utwórz plik o nazwie san.cnf i zastąp symbole zastępcze nazw hostów nazwami hostów ingress pobranymi wcześniej:
[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>Dodaj lub usuń wpisy DNS.* zgodnie z wymaganiami, aby wszystkie nazwy hostów ingress Bob były zawarte.
Generowanie żądania podpisania certyfikatu
openssl req \
-new \
-key tls.key \
-out tls.csr \
-config san.cnfPodpisanie certyfikatu
openssl x509 \
-req \
-in tls.csr \
-CA ca.crt \
-CAkey ca.key \
-CAcreateserial \
-out tls.crt \
-days 365 \
-extensions v3_req \
-extfile san.cnfTworzenie sekretu TLS
Dla certyfikatów wydanych przez prywatny lub firmowy urząd certyfikacji:
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>Dla publicznie zaufanych certyfikatów:
oc create secret tls my-tls-secret \
--cert=/path/to/tls.crt \
--key=/path/to/tls.key \
-n <instance-namespace>Stosowanie certyfikatu
Skonfiguruj Bob tak, aby używał sekretu TLS:
./bobctl setup-route --tls-secret my-tls-secretbobctl weryfikuje sekret, aktualizuje konfigurację Bob i czeka na zakończenie uzgadniania.
| Parametr | Opis |
|---|---|
--tls-secret <secret> | Określa sekret zawierający certyfikat TLS i klucz prywatny. |
--no-wait | Zwraca wynik natychmiast bez oczekiwania na zakończenie uzgadniania. |
--dry-run | Weryfikuje konfigurację bez stosowania zmian. |
Jeśli ca.crt nie jest zawarty w sekrecie, bobctl wyświetla ostrzeżenie. Jest to oczekiwane, gdy certyfikat jest wydany przez urząd certyfikacji, który jest już zaufany przez stacje robocze klientów.
Weryfikacja certyfikatu
Sprawdź, czy Bob obsługuje oczekiwany certyfikat:
echo | openssl s_client \
-connect <BOB_HOSTNAME_1>:443 \
-servername <BOB_HOSTNAME_1> 2>/dev/null \
| openssl x509 -noout -issuer -subject -datesSprawdź, czy:
- Wystawca odpowiada oczekiwanemu urzędowi certyfikacji.
- Certyfikat zawiera oczekiwane wpisy nazw hostów.
- Daty ważności certyfikatu są prawidłowe.
Jeśli wystawiający urząd certyfikacji nie jest zaufany przez stacje robocze programistów, przed połączeniem się z Bob przez bob-ide lub bob-shell rozdystrybuuj certyfikat CA do użytkowników.
Jeśli żaden zewnętrzny certyfikat nie jest skonfigurowany, Bob używa certyfikatu z podpisem własnym zarządzanego przez cert-manager. W tej konfiguracji użytkownicy muszą zaufać certyfikatowi CA Bob przed nawiązaniem połączenia.
Określenie konfiguracji certyfikatu
Sprawdź, czy zewnętrzny punkt końcowy Bob używa certyfikatu z podpisem własnym:
oc get secret bob-external-tls -n <instance-namespace> \
-o jsonpath='{.data.tls\.crt}' \
| base64 -d \
| openssl x509 -noout -issuer- Jeśli wystawca to
CN=Bob Internal CA, klaster używa domyślnego certyfikatu z podpisem własnym. Przejdź do następnego kroku. - Jeśli wystawca to urząd certyfikacji przedsiębiorstwa lub publicznie zaufany, konfiguracja certyfikatu po stronie klienta nie jest wymagana. Zobacz Zarządzanie użytkownikami.
Eksportowanie certyfikatu CA
./bobctl get-ca-cert --output bob-ca.crtDystrybucja certyfikatu CA
Udostępnij wyeksportowany bob-ca.crt użytkownikom i poinstruuj ich, aby dodali go do magazynu zaufania systemu operacyjnego. Po zaimportowaniu certyfikatu CA Bob użytkownicy mogą nawiązywać zaufane połączenia HTTPS.