bob-ide 및 bob-shell 클라이언트가 안전하게 연결할 수 있도록 IBM Bob 온프레미스의 외부 TLS 인증서를 구성합니다.

Bob은 HTTPS를 통해 API를 노출합니다. 사용자가 bob-ide 또는 bob-shell을 사용하여 연결하기 전에 엔드포인트 인증서가 클라이언트 워크스테이션에서 신뢰되어야 합니다.

팁:

가능하면 엔터프라이즈 또는 공개적으로 신뢰할 수 있는 인증 기관에서 발급한 인증서를 사용하세요. 이렇게 하면 개발자 워크스테이션에 Bob 전용 CA 인증서를 배포할 필요가 없어집니다.

언제든지 기본 자체 서명 인증서로 되돌리려면 bobctl reset-route를 실행합니다. 그러면 Bob 인증서 저장소에서 spec.externalCertificate가 제거되고 오퍼레이터가 외부 엔드포인트를 cert-manager로 반환합니다.

기업 PKI 또는 공개적으로 신뢰할 수 있는 인증 기관에서 인증서를 사용할 수 있을 때 이 접근 방식을 사용합니다.

인증서를 요청하거나 생성하기 전에 Bob이 노출하는 모든 호스트명을 식별합니다. 모든 호스트명은 인증서의 SAN(Subject Alternative Name)으로 포함되어야 합니다.

인그레스 호스트명 검색

다음 명령을 실행하여 모든 Bob 인그레스 호스트명을 나열합니다:

oc get ingress -n <instance-namespace> \
  -o jsonpath='{range .items[*]}{range .spec.rules[*]}{.host}{"\n"}{end}{end}'

반환된 호스트명을 기록합니다 — 인증서를 주문하거나 생성할 때 필요합니다.

인증서 요구 사항 확인

Bob에 적용하기 전에 인증서가 다음 요구 사항을 충족하는지 확인합니다:

개인 키가 암호화되지 않았습니다.
인증서에 전체 인증서 체인이 포함되어 있습니다.
모든 Bob 인그레스 호스트명이 SAN 항목으로 포함되어 있습니다.
인증서와 키가 PEM 형식으로 제공됩니다.

인증서 시크릿 생성

인증서와 개인 키를 포함하는 Kubernetes 시크릿을 생성합니다:

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>

기존 시크릿을 업데이트하려면:

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 -

인증서 적용

인증서를 사용하도록 Bob을 구성합니다:

./bobctl setup-route --tls-secret my-tls-secret

매개변수	설명
`--tls-secret`	인증서와 개인 키를 포함하는 시크릿을 지정합니다.
`--no-wait`	조정이 완료될 때까지 기다리지 않고 즉시 반환합니다.
`--dry-run`	변경 사항을 적용하지 않고 구성을 검증합니다.

인증서 확인

예상 인증서가 제공되고 있는지 확인합니다:

echo | openssl s_client \
  -connect <hostname>:443 \
  -servername <hostname> 2>/dev/null \
  | openssl x509 -noout -issuer -subject -dates

다음을 확인합니다:

발급자가 올바릅니다.
호스트명이 SAN 목록에 있습니다.
인증서 유효 기간이 올바릅니다.

이 절차를 사용하여 프라이빗 또는 내부 인증 기관이 서명한 인증서를 생성하고 Bob이 외부 HTTPS 트래픽에 이를 사용하도록 구성합니다.

CA 인증서 생성

인증 기관을 위한 개인 키와 자체 서명 인증서를 생성합니다:

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"

이렇게 하면 ca.key와 ca.crt가 생성됩니다.

참고:

Bob은 Kubernetes 시크릿에 포함될 때 CA 인증서 이름이 ca.crt여야 합니다. 기존 CA 인증서를 사용하는 경우 시크릿을 생성하기 전에 ca.crt로 이름을 변경하세요.

서버 개인 키 생성

Bob 엔드포인트 인증서를 위한 암호화되지 않은 개인 키를 생성합니다:

openssl genrsa -out tls.key 4096

개인 키가 패스프레이즈로 암호화된 경우 계속하기 전에 패스프레이즈를 제거합니다:

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

SAN 구성 파일 생성

san.cnf라는 파일을 생성하고 플레이스홀더 호스트명을 앞서 검색한 인그레스 호스트명으로 교체합니다:

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

모든 Bob 인그레스 호스트명이 포함되도록 DNS.* 항목을 추가하거나 제거합니다.

인증서 서명 요청 생성

openssl req \
  -new \
  -key tls.key \
  -out tls.csr \
  -config san.cnf

인증서 서명

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

TLS 시크릿 생성

프라이빗 또는 기업 인증 기관이 발급한 인증서의 경우:

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>

공개적으로 신뢰할 수 있는 인증서의 경우:

oc create secret tls my-tls-secret \
  --cert=/path/to/tls.crt \
  --key=/path/to/tls.key \
  -n <instance-namespace>

인증서 적용

TLS 시크릿을 사용하도록 Bob을 구성합니다:

./bobctl setup-route --tls-secret my-tls-secret

bobctl은 시크릿을 검증하고, Bob 구성을 업데이트하며, 조정이 완료될 때까지 기다립니다.

매개변수	설명
`--tls-secret <secret>`	TLS 인증서와 개인 키를 포함하는 시크릿을 지정합니다.
`--no-wait`	조정이 완료될 때까지 기다리지 않고 즉시 반환합니다.
`--dry-run`	변경 사항을 적용하지 않고 구성을 검증합니다.

참고:

시크릿에 ca.crt가 포함되어 있지 않으면 bobctl이 경고를 표시합니다. 이는 인증서가 클라이언트 워크스테이션에서 이미 신뢰하는 인증 기관에서 발급된 경우 예상되는 동작입니다.

인증서 확인

Bob이 예상 인증서를 제공하고 있는지 확인합니다:

echo | openssl s_client \
  -connect <BOB_HOSTNAME_1>:443 \
  -servername <BOB_HOSTNAME_1> 2>/dev/null \
  | openssl x509 -noout -issuer -subject -dates

다음을 확인합니다:

발급자가 예상 인증 기관과 일치합니다.
인증서에 예상 호스트명 항목이 포함되어 있습니다.
인증서 유효 기간이 올바릅니다.

발급 인증 기관이 개발자 워크스테이션에서 신뢰되지 않는 경우 사용자가 bob-ide 또는 bob-shell을 사용하여 Bob에 연결하기 전에 CA 인증서를 배포하세요.

외부 인증서가 구성되지 않은 경우 Bob은 cert-manager가 관리하는 자체 서명 인증서를 사용합니다. 이 구성에서는 사용자가 연결하기 전에 Bob CA 인증서를 신뢰해야 합니다.

인증서 구성 확인

Bob 외부 엔드포인트가 자체 서명 인증서를 사용하고 있는지 확인합니다:

oc get secret bob-external-tls -n <instance-namespace> \
  -o jsonpath='{.data.tls\.crt}' \
  | base64 -d \
  | openssl x509 -noout -issuer

발급자가 CN=Bob Internal CA인 경우 클러스터가 기본 자체 서명 인증서를 사용하고 있습니다. 다음 단계를 계속 진행합니다.
발급자가 엔터프라이즈 또는 공개적으로 신뢰할 수 있는 인증 기관인 경우 클라이언트 측 인증서 구성이 필요하지 않습니다. 사용자 관리를 참조하세요.

CA 인증서 내보내기

./bobctl get-ca-cert --output bob-ca.crt

CA 인증서 배포

내보낸 bob-ca.crt를 사용자에게 제공하고 운영 체제 신뢰 저장소에 추가하도록 안내합니다. 사용자는 Bob CA 인증서를 가져온 후 신뢰할 수 있는 HTTPS 연결을 설정할 수 있습니다.

TLS 인증서

이 페이지에서