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.

Wskazówka:

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
ParametrOpis
--tls-secretOkreśla sekret zawierający certyfikat i klucz prywatny.
--no-waitZwraca wynik natychmiast bez oczekiwania na uzgadnianie.
--dry-runWeryfikuje 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 -dates

Sprawdź, 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.

Uwaga:

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 4096

Jeśli klucz prywatny jest zaszyfrowany hasłem, usuń hasło przed kontynuowaniem:

openssl rsa -in encrypted.key -out tls.key

Tworzenie 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.cnf

Podpisanie certyfikatu

openssl x509 \
  -req \
  -in tls.csr \
  -CA ca.crt \
  -CAkey ca.key \
  -CAcreateserial \
  -out tls.crt \
  -days 365 \
  -extensions v3_req \
  -extfile san.cnf

Tworzenie 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-secret

bobctl weryfikuje sekret, aktualizuje konfigurację Bob i czeka na zakończenie uzgadniania.

ParametrOpis
--tls-secret <secret>Określa sekret zawierający certyfikat TLS i klucz prywatny.
--no-waitZwraca wynik natychmiast bez oczekiwania na zakończenie uzgadniania.
--dry-runWeryfikuje konfigurację bez stosowania zmian.
Uwaga:

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 -dates

Sprawdź, 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.crt

Dystrybucja 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.

Jak oceniasz ten temat?