4.12. 클라이언트 연결을 위한 Operator 기반 브로커 배포 구성
4.12.1. 어셉터 구성 링크 복사링크가 클립보드에 복사되었습니다!
OpenShift 배포에서 브로커 Pod에 대한 클라이언트 연결을 활성화하려면 배포에 대한 허용자를 정의합니다. 승인자는 브로커 pod에서 연결을 허용하는 방법을 정의합니다. 브로커 배포에 사용되는 기본 CR(사용자 정의 리소스)에 허용자를 정의합니다. 어셉터를 생성할 때 수락자에서 활성화할 메시징 프로토콜과 이러한 프로토콜에 사용할 브로커 Pod의 포트와 같은 정보를 지정합니다.
프로세스
-
브로커 배포에 대한
ActiveMQArtemisCR(사용자 정의 리소스)을 편집합니다. acceptors특성에 이름이 지정된 어셉터를 추가합니다.프로토콜및포트속성을 추가합니다. 값을 설정하여 어셉터에서 사용할 메시징 프로토콜과 해당 프로토콜에 노출할 각 브로커 Pod의 포트를 지정합니다. 예를 들면 다음과 같습니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow 구성된 수락자는 포트 5672를 AMQP 클라이언트에 노출합니다.
protocols특성에 지정할 수 있는 전체 값 세트가 표에 표시됩니다.Expand 표 4.4. acceptor 프로토콜 프로토콜 현재의 코어 프로토콜
코어AMQP
amqpOpenWire
OpenWireMQTT
mqttSTOMP
stomp지원되는 모든 프로토콜
all참고- 배포의 각 브로커 Pod에 대해 Operator는 포트 61616을 사용하는 기본 수락자도 생성합니다. 이 기본 수락자는 브로커 클러스터링에 필요하며 코어 프로토콜이 활성화되어 있습니다.
- 기본적으로 AMQ Broker 관리 콘솔은 브로커 Pod에서 포트 8161을 사용합니다. 배포의 각 브로커 포드에는 콘솔에 대한 액세스를 제공하는 전용 서비스가 있습니다. 자세한 내용은 5장. Operator 기반 브로커 배포를 위한 AMQ 관리 콘솔에 연결의 내용을 참조하십시오.
동일한 수락자에서 다른 프로토콜을 사용하려면
protocols속성을 수정합니다. 쉼표로 구분된 프로토콜 목록을 지정합니다. 예를 들면 다음과 같습니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow 구성된 수락자는 이제 포트 5672를 AMQP 및 OpenWire 클라이언트에 노출합니다.
허용자가 허용하는 동시 클라이언트 연결 수를 지정하려면
connectionsAllowed속성을 추가하고 값을 설정합니다. 예를 들면 다음과 같습니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow 기본적으로 수락자는 브로커 배포와 동일한 OpenShift 클러스터의 클라이언트에만 노출됩니다. OpenShift 외부의 클라이언트에 어셉터도 노출하려면
expose속성과sslEnabled속성을 모두true로 설정합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow 수락자(또는 커넥터)에서 SSL(즉, Secure Sockets Layer) 보안을 활성화하면 다음과 같은 관련 구성을 추가할 수 있습니다.
- OpenShift 클러스터에 인증 자격 증명을 저장하는 데 사용되는 시크릿 이름입니다. 수락자에서 SSL을 활성화할 때 시크릿이 필요합니다.
-
보안 네트워크 통신에 사용할 TLS(Transport Layer Security) 프로토콜입니다. TLS는 더 안전한 SSL 버전입니다.
enabledProtocols속성에 TLS 프로토콜을 지정합니다. -
수락자가 브로커와 클라이언트 간의 상호 인증이라고도 하는 mTLS를 사용하는지 여부입니다.
needClientAuth속성 값을true로 설정하여 이 값을 지정합니다.
이러한 작업에 대한 자세한 내용은 4.12.2절. “broker-client 연결 보안” 을 참조하십시오.
OpenShift 외부의 클라이언트에 어셉터를 노출하면 Operator는 배포의 각 브로커 Pod에서 수락자를 위한 전용 서비스와 Openshift 경로를 자동으로 생성합니다.
각 pod에서 허용자가 Openshift 클러스터의 내부 라우팅 구성과 일치하도록 허용되는 경로의 호스트 이름을 사용자 지정하려면 다음 중 하나 또는 둘 다를 수행할 수 있습니다.
-
ingressHost특성을 사용하여 기본 호스트 이름을 특정 수락자의 사용자 지정 호스트 이름으로 바꿉니다. ingressDomain특성을 사용하여 호스트 이름에 사용자 지정 도메인을 추가합니다. 사용자 정의 도메인은 CR 구성에 의해 노출되는 다른 어셉터 및 콘솔과 같은 다른 모든 경로에도 적용됩니다.acceptor 경로에 사용자 정의 호스트 이름을 설정하려면
ingressHost속성을 추가하고 호스트 문자열을 지정합니다. 예를 들면 다음과 같습니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow 참고ingressHost값은 Openshift 클러스터에서 고유해야 합니다. 브로커 클러스터에 브로커 Pod가 여러 개 있는 경우 값에 $(BROKER_ORDINAL) 변수를 포함하여ingressHost값을 고유하게 만들 수 있습니다. Operator는 각 브로커 Pod의 이 변수를 Pod에 할당된 StatefulSet의 서수로 바꿉니다. 예를 들어,my-acceptor-$(BROKER_ORDINAL)-production.my-subdomain.com의ingressHost값을 첫 번째 Pod의my-acceptor-0-production.my-subdomain으로 설정합니다. my-acceptor-1-production.my-subdomain은 두 번째 Pod의my-acceptor-1-production.my-subdomain으로 설정합니다.허용자 경로에 대한 사용자 정의 호스트 이름 문자열에 다음 변수를 포함할 수 있습니다.
Expand 표 4.5. acceptor 경로에 대한 사용자 정의 호스트 이름 문자열의 변수 이름 설명 $(CR_NAME)
CR의
metadata.name속성 값입니다.$(CR_NAMESPACE)
사용자 정의 리소스의 네임스페이스입니다.
$(BROKER_ORDINAL)
StatefulSet에서 브로커 Pod에 할당한 서수입니다.
$(ITEM_NAME)
수락자의 이름입니다.
$(RES_TYPE)
리소스 유형입니다. 경로에는
rte의 리소스 유형이 있습니다. 수신에는 리소스 유형의ing이 있습니다.$(INGRESS_DOMAIN)
CR에 구성된 경우
spec.ingressDomain속성의 값입니다.경로의 호스트 이름에 사용자 정의 도메인을 추가하려면
spec.ingressDomain속성을 추가하고 사용자 정의 문자열을 지정합니다. 예를 들면 다음과 같습니다.spec: ... ingressDomain: my.domain.com
spec: ... ingressDomain: my.domain.comCopy to Clipboard Copied! Toggle word wrap Toggle overflow
-
조직의 네트워크 정책에서 경로 대신 Ingress를 사용하여 수락자를 노출해야 하는 경우 다음 단계를 완료합니다.
exposeMode속성을 추가하고 값을ingress로 설정합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow 허용자가 Openshift 클러스터의 내부 라우팅 구성과 일치하도록 노출된 Ingress의 호스트 이름을 사용자 지정하려면 다음 중 하나 또는 둘 다를 수행할 수 있습니다.
-
ingressHost특성을 사용하여 기본 호스트 이름을 사용자 지정 호스트 이름으로 교체합니다. ingressDomain특성을 사용하여 호스트 이름에 사용자 지정 도메인을 추가합니다. 사용자 정의 도메인은 CR 구성에 의해 노출되는 다른 어셉터 및 콘솔의 Ingress와 같은 기타 모든 수신에도 적용됩니다.acceptor의 Ingress에 대한 사용자 정의 호스트 이름을 설정하려면
ingressHost속성을 추가하고 호스트 문자열을 지정합니다. 예를 들면 다음과 같습니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow 동일한 변수를 포함하여 이 절차의 앞부분에서 설명하는 경로 호스트로 수신 호스트를 사용자 지정할 수 있습니다.
Ingress의 호스트 이름에 사용자 정의 도메인을 추가하려면
spec.ingressDomain속성을 추가하고 사용자 지정 문자열을 지정합니다. 예를 들면 다음과 같습니다.spec: ... ingressDomain: my-subdomain.domain.com
spec: ... ingressDomain: my-subdomain.domain.comCopy to Clipboard Copied! Toggle word wrap Toggle overflow 어셉터의 경우 수신의 기본 호스트 이름은 <
cr-name>-<acceptor name>-<ordinal>-svc-ing-<namespace> 형식으로 되어 있습니다. 예를 들어amqbroker네임 스페이스에production이라는 CR이 있는 경우mydomain.com의ingressDomain값은 Pod 0에서 생성된 수신에 대해production-wconsj-0-svc-svc-mynamespace.amqbroker.com의 호스트 값을 제공합니다.
-
추가 리소스
- 인증 인증 정보를 저장할 시크릿 생성을 포함하여 브로커-클라이언트 연결을 보호하도록 TLS를 구성하는 방법을 알아보려면 4.12.2절. “broker-client 연결 보안” 를 참조하십시오.
- 어셉터 및 커넥터 구성을 포함한 전체 사용자 정의 리소스 구성 참조는 8.1절. “사용자 정의 리소스 구성 참조” 에서 참조하십시오.
4.12.2. broker-client 연결 보안 링크 복사링크가 클립보드에 복사되었습니다!
수락자 또는 커넥터(즉, sslEnabled 를 true로 설정하여 보안)에서 보안을 활성화한 경우 브로커와 클라이언트 간의 인증서 기반 인증을 허용하도록 TLS(Transport Layer Security)를 구성해야 합니다. TLS는 더 안전한 SSL 버전입니다. 두 가지 기본 TLS 구성이 있습니다.
- TLS
- 브로커만 인증서를 제공합니다. 인증서는 클라이언트가 브로커를 인증하는 데 사용됩니다. 가장 일반적인 구성입니다.
- mTLS
- 브로커와 클라이언트 모두 인증서를 제공합니다. 이를 상호 인증 이라고 합니다.
다양한 방법을 사용하여 TLS 인증서를 생성할 수 있습니다.
브로커와 클라이언트가 동일한 Openshift 클러스터에서 실행되는 경우 Openshift를 사용하여 브로커의 서비스 제공 인증서를 생성할 수 있습니다.
브로커 및 클라이언트가 동일한 Openshift 클러스터에서 실행되지 않는 경우 인증서를 사용자 지정할 수 있는 방법을 사용하여 인증서를 생성해야 합니다. 이 섹션에서는 사용자 정의 인증서를 생성하는 데 사용할 수 있는 두 가지 방법에 대해 설명합니다.
- cert-manager Operator for Openshift
- Java Keytool 유틸리티.
4.12.2.1. Openshift 서비스 제공 인증서 사용 링크 복사링크가 클립보드에 복사되었습니다!
동일한 Openshift 클러스터에서 브로커와 클라이언트 간에 내부 연결을 보호하려면 acceptor 서비스에 주석을 추가하여 Openshift에서 서비스 제공 인증서를 생성하도록 요청할 수 있습니다. 생성된 인증서 및 키는 PEM 형식이며, 생성된 보안의 tls.crt 및 tls.key에 각각 저장됩니다.
서비스 인증서를 발급하는 서비스 CA 인증서는 26개월 동안 유효하며 유효 기간이 13개월 미만으로 남아 있으면 자동으로 순환됩니다. 교체 후에도 이전 서비스 CA 구성은 만료될 때까지 계속 신뢰 상태가 유지됩니다. 그러면 만료되기 전에 유예 기간 동안 영향을 받는 모든 서비스의 주요 자료를 새로 고칠 수 있습니다. 서비스를 다시 시작하고 키 자료를 새로 고치는 이 유예 기간 동안 클러스터를 업그레이드하지 않으면 이전 서비스 CA가 만료된 후 실패하지 않도록 서비스를 직접 다시 시작해야 할 수도 있습니다.
프로세스
-
브로커 배포에 사용할
ActiveMQArtemisCR(사용자 정의 리소스)을 편집합니다. resourceTemplates속성을 사용하여 수락자에 대해 생성된 서비스에 주석을 답니다. 예를 들면 다음과 같습니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow - resourceTemplates.selector.kind
-
사용자 지정이 적용되는 리소스 유형을
Service로 지정합니다. - resourceTemplates.selector.name
주석을 적용할 서비스의 이름을 지정합니다. 수락 서비스의 이름 형식은 <
CR name><acceptor name><ordinal>-svc, 여기서:-
<CR name> name은 CR의
metadata.name속성 값입니다. -
<acceptor name>은 어셉터의 이름입니다. 이 예제에서는 어셉터 이름이
myacceptor라고 가정합니다. - <ordinal>은 StatefulSet에서 브로커 Pod에 할당된 서수입니다.
-
<CR name> name은 CR의
- resourceTemplates.annotations
service.beta.openshift.io/serving-cert-secret-name: < secret>의 주석을 지정합니다. 여기서 <secret>은 Openshift가 서비스에 생성하는 시크릿의 이름입니다.참고시크릿 이름은 acceptor 이름과 일치해야 하며
-ptls접미사가 있어야 합니다. Operator에서 시크릿을 생성하기 전에 CR을 배포할 수 있도록 하려면 특정 접미사가 필요합니다.
CR의 sslSecret' 속성에서 브로커 인증서가 포함된 보안을 지정합니다. 예를 들면 다음과 같습니다.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow brokerProperties속성에서 인증서가 Openshift에서 갱신될 때마다 새 인증서를 자동으로 로드하도록 브로커를 구성합니다. 예를 들면 다음과 같습니다.spec: ... brokerProperties - "acceptorConfigurations.myacceptor.params.sslAutoReload=true" ...
spec: ... brokerProperties - "acceptorConfigurations.myacceptor.params.sslAutoReload=true" ...Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 서비스 제공 인증서의 공개 키를 각 클라이언트의 신뢰 저장소에 추가합니다.
브로커와 클라이언트 간에 mTLS 인증을 구성하려면 다음 단계를 완료합니다.
-
브로커가 신뢰할 각 클라이언트의 인증서가 포함된 신뢰 번들을 생성하고 시크릿(예:
trusted-clients-bundle)에 신뢰 번들을 추가합니다. 브로커 CR에 구성된 승인자에서
needClientAuth속성을 추가하고 클라이언트 인증을 요구하도록true로 설정합니다. 예를 들면 다음과 같습니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow 각 수락자의
trustSecret속성에서 클라이언트 인증서의 신뢰 번들이 포함된 보안을 지정합니다. 예를 들면 다음과 같습니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow
-
브로커가 신뢰할 각 클라이언트의 인증서가 포함된 신뢰 번들을 생성하고 시크릿(예:
- CR을 저장합니다.
추가 리소스
4.12.2.2. Openshift에 cert-manager Operator 사용 링크 복사링크가 클립보드에 복사되었습니다!
cert-manager Operator for OpenShift는 애플리케이션 인증서 라이프사이클 관리를 제공하는 클러스터 전체 서비스입니다. cert-manager는 다양한 인증 기관의 TLS 인증서 관리를 자동화합니다.
다음 예제 절차에서는 자체 서명된 인증서를 사용하여 TLS(Transport Layer Security)를 구성하는 방법을 설명합니다. 정책에 인식된 인증서 관리자가 서명한 인증서가 필요한 경우 OpenShift 용 cert-manager Operator를 사용하여 인증서를 요청할 수 있습니다.
사전 요구 사항
cert-manager Operator for Red Hat OpenShift가 설치되어 있습니다.
자세한 내용은 OpenShift Container Platform 설명서에서 cert-manager Operator for Red Hat OpenShift 설치를 참조하십시오.
브로커와 클라이언트 간에 mTLS를 구성하려면 Kubernetes에 대한 신뢰 관리자가 설치됩니다.
자세한 내용은 trust-manager 설치를 참조하십시오.
프로세스
자체 서명된 발행자를 정의하는 YAML 파일(예:
self-signed-issuer.yaml)을 생성합니다. 발행자는 인증서 서명 요청을 준수하여 서명된 인증서를 생성할 수 있는 CA(인증 기관)를 나타내는 Openshift 리소스입니다.다음 예제 yaml은 자체 서명된 발급자를 생성하여 이를 사용하여 인증 기관(CA) 인증서를 생성할 수 있습니다. CA 인증서는 cert-manager Operator에서 관리할 수 있습니다.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 루트 CA 인증서를 정의하는 YAML 파일(예:
root-ca.yaml)을 생성합니다.issuerRef.name필드에서 사용자가 생성한 자체 서명된 발급자인root-issuer의 이름을 지정합니다. 예를 들면 다음과 같습니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow 인증서는
root-ca-secret이라는 시크릿의 Privacy Enhanced mail (PEM) 형식으로 생성됩니다.루트 CA에서 서명한 인증서 발행을 위한 CA 발행자를 정의하는 YAML 파일(예:
root-ca-issuer.yaml)을 생성합니다. 예를 들면 다음과 같습니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow 브로커 인증서를 정의하는 YAML 파일(예:
broker-cert.yaml)을 생성합니다.issuerRef.Name필드에서 루트 CA에서 서명한 인증서를 발행하기 위해 생성한 발급자인root-ca-issuer의 이름을 지정합니다. 예를 들면 다음과 같습니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow YAML 파일에서 발행자 및 인증서에 대해 정의한 사용자 정의 리소스를 배포하여 해당 OpenShift 오브젝트를 생성합니다. 예를 들면 다음과 같습니다.
oc create -f self-signed-issuer.yaml oc create -f root-ca.yaml oc create -f root-ca-issuer.yaml oc create -f broker-cert.yaml
$ oc create -f self-signed-issuer.yaml $ oc create -f root-ca.yaml $ oc create -f root-ca-issuer.yaml $ oc create -f broker-cert.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow -
브로커 배포를 위해
ActiveMQArtemisCR을 편집합니다. 보안하려는 각 수락자의
sslSecret속성에 브로커 인증서가 포함된 보안을 지정합니다. 예를 들면 다음과 같습니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow brokerProperties속성에서 cert-manager Operator가 Openshift용 cert-manager Operator에 의해 갱신될 때마다 수락자에 대한 새 브로커 인증서를 자동으로 로드하도록 브로커를 구성합니다. 예를 들면 다음과 같습니다.spec: ... brokerProperties - "acceptorConfigurations.new-acceptor.params.sslAutoReload=true" ...
spec: ... brokerProperties - "acceptorConfigurations.new-acceptor.params.sslAutoReload=true" ...Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
클라이언트가 브로커를 신뢰할 수 있도록 이 예제 프로세스의
root-ca-secret시크릿에 생성된 브로커 인증서에 서명한 루트 CA 인증서를 각 클라이언트의 신뢰 저장소에 추가합니다. 브로커와 클라이언트 간에 mTLS 인증을 구성하려면 다음 단계를 완료합니다.
-
Kubernetes용 Trust Manager를 사용하여 브로커가 신뢰하려는 각 클라이언트의 인증서가 포함된 신뢰 번들을 생성하고 시크릿(예:
trusted-clients-bundle)에 신뢰 번들을 추가합니다. 신뢰 번들을 생성하는 방법에 대한 자세한 내용은 trust-manager 설명서 를 참조하십시오. 브로커 CR에 구성된 승인자에서
needClientAuth속성을 추가하고 클라이언트 인증을 요구하도록true로 설정합니다. 예를 들면 다음과 같습니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow 각 수락자의
trustSecret속성에서 클라이언트 인증서의 신뢰 번들이 포함된 보안을 지정합니다. 예를 들면 다음과 같습니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow
-
Kubernetes용 Trust Manager를 사용하여 브로커가 신뢰하려는 각 클라이언트의 인증서가 포함된 신뢰 번들을 생성하고 시크릿(예:
- CR을 저장합니다.
4.12.2.3. Java keytool 유틸리티 사용 링크 복사링크가 클립보드에 복사되었습니다!
keytool은 Java에 포함된 인증서 관리 유틸리티입니다.
4.12.2.3.1. 단방향 TLS 구성 링크 복사링크가 클립보드에 복사되었습니다!
이 섹션의 절차에서는 브로커-클라이언트 연결을 보호하도록 단방향 TLS(Transport Layer Security)를 구성하는 방법을 보여줍니다.
단방향 TLS에서는 브로커만 인증서를 제공합니다. 이 인증서는 클라이언트가 브로커를 인증하는 데 사용됩니다.
사전 요구 사항
- 클라이언트가 호스트 이름 확인을 사용하는 경우 브로커 인증서 생성의 요구 사항을 이해해야합니다. 자세한 내용은 4.12.2.4절. “호스트 이름 확인을 위해 브로커 인증서 구성”의 내용을 참조하십시오.
프로세스
브로커 키 저장소에 대한 자체 서명 인증서를 생성합니다.
keytool -genkey -alias broker -keyalg RSA -keystore ~/broker.ks
$ keytool -genkey -alias broker -keyalg RSA -keystore ~/broker.ksCopy to Clipboard Copied! Toggle word wrap Toggle overflow 클라이언트와 공유할 수 있도록 브로커 키 저장소에서 인증서를 내보냅니다. Base64로 인코딩된
.pem형식으로 인증서를 내보냅니다. 예를 들면 다음과 같습니다.keytool -export -alias broker -keystore ~/broker.ks -file ~/broker_cert.pem
$ keytool -export -alias broker -keystore ~/broker.ks -file ~/broker_cert.pemCopy to Clipboard Copied! Toggle word wrap Toggle overflow 클라이언트에서 브로커 인증서를 가져오는 클라이언트 신뢰 저장소를 생성합니다.
keytool -import -alias broker -keystore ~/client.ts -file ~/broker_cert.pem
$ keytool -import -alias broker -keystore ~/client.ts -file ~/broker_cert.pemCopy to Clipboard Copied! Toggle word wrap Toggle overflow 관리자로 OpenShift Container Platform에 로그인합니다. 예를 들면 다음과 같습니다.
oc login -u system:admin
$ oc login -u system:adminCopy to Clipboard Copied! Toggle word wrap Toggle overflow 브로커 배포가 포함된 프로젝트로 전환합니다. 예를 들면 다음과 같습니다.
oc project <my_openshift_project>
$ oc project <my_openshift_project>Copy to Clipboard Copied! Toggle word wrap Toggle overflow TLS 인증 정보를 저장할 시크릿을 생성합니다. 예를 들면 다음과 같습니다.
oc create secret generic my-tls-secret \ --from-file=broker.ks=~/broker.ks \ --from-file=client.ts=~/client.ks \ --from-literal=keyStorePassword=<password> \ --from-literal=trustStorePassword=<password>
$ oc create secret generic my-tls-secret \ --from-file=broker.ks=~/broker.ks \ --from-file=client.ts=~/client.ks \ --from-literal=keyStorePassword=<password> \ --from-literal=trustStorePassword=<password>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 참고시크릿을 생성할 때 OpenShift에서 키 저장소와 신뢰 저장소를 모두 지정해야 합니다. 신뢰 저장소 키는 일반적으로
client.ts로 이름이 지정됩니다. 브로커와 클라이언트 간의 단방향 TLS의 경우 실제로 신뢰 저장소가 필요하지 않습니다. 그러나 보안을 성공적으로 생성하려면 일부 유효한 저장소 파일을client.ts의 값으로 지정해야 합니다. 이전 단계에서는 이전에 생성한 브로커 키 저장소 파일을 재사용하여client.ts의 "더미" 값을 제공합니다. 이는 단방향 TLS에 필요한 모든 인증 정보를 사용하여 보안을 생성하는 데 충분합니다.Operator를 설치할 때 생성한 서비스 계정에 보안을 연결합니다. 예를 들면 다음과 같습니다.
oc secrets link sa/amq-broker-operator secret/my-tls-secret
$ oc secrets link sa/amq-broker-operator secret/my-tls-secretCopy to Clipboard Copied! Toggle word wrap Toggle overflow 보안 수락자 또는 커넥터의
sslSecret매개변수에 시크릿 이름을 지정합니다. 예를 들면 다음과 같습니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow
4.12.2.3.2. 양방향 TLS 구성 링크 복사링크가 클립보드에 복사되었습니다!
이 섹션의 절차에서는 브로커-클라이언트 연결을 보호하도록 양방향 TLS(Transport Layer Security)를 구성하는 방법을 보여줍니다.
양방향 TLS에서 브로커와 클라이언트 모두 인증서를 제공합니다. 브로커 및 클라이언트는 이러한 인증서를 사용하여 때때로 상호 인증 이라는 프로세스에서 서로 인증합니다.
사전 요구 사항
- 클라이언트가 호스트 이름 확인을 사용하는 경우 브로커 인증서 생성의 요구 사항을 이해해야합니다. 자세한 내용은 4.12.2.4절. “호스트 이름 확인을 위해 브로커 인증서 구성”의 내용을 참조하십시오.
프로세스
브로커 키 저장소에 대한 자체 서명 인증서를 생성합니다.
keytool -genkey -alias broker -keyalg RSA -keystore ~/broker.ks
$ keytool -genkey -alias broker -keyalg RSA -keystore ~/broker.ksCopy to Clipboard Copied! Toggle word wrap Toggle overflow 클라이언트와 공유할 수 있도록 브로커 키 저장소에서 인증서를 내보냅니다. Base64로 인코딩된
.pem형식으로 인증서를 내보냅니다. 예를 들면 다음과 같습니다.keytool -export -alias broker -keystore ~/broker.ks -file ~/broker_cert.pem
$ keytool -export -alias broker -keystore ~/broker.ks -file ~/broker_cert.pemCopy to Clipboard Copied! Toggle word wrap Toggle overflow 클라이언트에서 브로커 인증서를 가져오는 클라이언트 신뢰 저장소를 생성합니다.
keytool -import -alias broker -keystore ~/client.ts -file ~/broker_cert.pem
$ keytool -import -alias broker -keystore ~/client.ts -file ~/broker_cert.pemCopy to Clipboard Copied! Toggle word wrap Toggle overflow 클라이언트에서 클라이언트 키 저장소에 대한 자체 서명된 인증서를 생성합니다.
keytool -genkey -alias broker -keyalg RSA -keystore ~/client.ks
$ keytool -genkey -alias broker -keyalg RSA -keystore ~/client.ksCopy to Clipboard Copied! Toggle word wrap Toggle overflow 클라이언트에서 브로커와 공유할 수 있도록 클라이언트 키 저장소에서 인증서를 내보냅니다. Base64로 인코딩된
.pem형식으로 인증서를 내보냅니다. 예를 들면 다음과 같습니다.keytool -export -alias broker -keystore ~/client.ks -file ~/client_cert.pem
$ keytool -export -alias broker -keystore ~/client.ks -file ~/client_cert.pemCopy to Clipboard Copied! Toggle word wrap Toggle overflow 클라이언트 인증서를 가져오는 브로커 신뢰 저장소를 생성합니다.
keytool -import -alias broker -keystore ~/broker.ts -file ~/client_cert.pem
$ keytool -import -alias broker -keystore ~/broker.ts -file ~/client_cert.pemCopy to Clipboard Copied! Toggle word wrap Toggle overflow 관리자로 OpenShift Container Platform에 로그인합니다. 예를 들면 다음과 같습니다.
oc login -u system:admin
$ oc login -u system:adminCopy to Clipboard Copied! Toggle word wrap Toggle overflow 브로커 배포가 포함된 프로젝트로 전환합니다. 예를 들면 다음과 같습니다.
oc project <my_openshift_project>
$ oc project <my_openshift_project>Copy to Clipboard Copied! Toggle word wrap Toggle overflow TLS 인증 정보를 저장할 시크릿을 생성합니다. 예를 들면 다음과 같습니다.
oc create secret generic my-tls-secret \ --from-file=broker.ks=~/broker.ks \ --from-file=client.ts=~/broker.ts \ --from-literal=keyStorePassword=<password> \ --from-literal=trustStorePassword=<password>
$ oc create secret generic my-tls-secret \ --from-file=broker.ks=~/broker.ks \ --from-file=client.ts=~/broker.ts \ --from-literal=keyStorePassword=<password> \ --from-literal=trustStorePassword=<password>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 참고시크릿을 생성할 때 OpenShift에서 키 저장소와 신뢰 저장소를 모두 지정해야 합니다. 신뢰 저장소 키는 일반적으로
client.ts로 이름이 지정됩니다. 브로커와 클라이언트 간의 양방향 TLS의 경우 클라이언트 인증서가 있으므로 브로커 신뢰 저장소를 포함하는 시크릿을 생성해야 합니다. 따라서 이전 단계에서client.ts키에 대해 지정하는 값은 실제로 브로커 신뢰 저장소 파일입니다.Operator를 설치할 때 생성한 서비스 계정에 보안을 연결합니다. 예를 들면 다음과 같습니다.
oc secrets link sa/amq-broker-operator secret/my-tls-secret
$ oc secrets link sa/amq-broker-operator secret/my-tls-secretCopy to Clipboard Copied! Toggle word wrap Toggle overflow 보안 수락자 또는 커넥터의
sslSecret매개변수에 시크릿 이름을 지정합니다. 예를 들면 다음과 같습니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow
4.12.2.4. 호스트 이름 확인을 위해 브로커 인증서 구성 링크 복사링크가 클립보드에 복사되었습니다!
이 섹션에서는 단방향 또는 양방향 TLS를 구성할 때 생성해야 하는 브로커 인증서에 대한 몇 가지 요구 사항에 대해 설명합니다.
클라이언트가 배포의 브로커 Pod에 연결하려고 하면 클라이언트 연결 URL의 verifyHost 옵션은 클라이언트가 브로커 인증서의 CN(일반 이름)을 호스트 이름과 비교하여 일치하는지 확인합니다. 클라이언트 연결 URL에서 verifyHost=true 또는 이와 유사한 경우 클라이언트가 이 확인을 수행합니다.
예를 들어 브로커가 격리된 네트워크의 OpenShift 클러스터에 배포된 경우와 같이 연결 보안에 대한 우려가 없는 드문 경우 이 확인을 생략할 수 있습니다. 그렇지 않으면 보안 연결을 위해 클라이언트가 이 확인을 수행하는 것이 좋습니다. 이 경우 클라이언트 연결을 성공적으로 수행하려면 브로커 키 저장소 인증서를 올바르게 구성해야 합니다.
일반적으로 클라이언트가 호스트 확인을 사용하는 경우 브로커 인증서를 생성할 때 지정하는 CN은 클라이언트가 연결하는 브로커 Pod의 경로 전체 호스트 이름과 일치해야 합니다. 예를 들어 단일 브로커 Pod가 있는 배포가 있는 경우 CN은 다음과 같을 수 있습니다.
CN=my-broker-deployment-0-svc-rte-my-openshift-project.my-openshift-domain
CN=my-broker-deployment-0-svc-rte-my-openshift-project.my-openshift-domain
CN이 여러 브로커가 있는 배포에서 브로커 Pod를 확인할 수 있도록 브로커 Pod 대신 별표(*) 와일드카드 문자를 지정할 수 있습니다. 예를 들면 다음과 같습니다.
CN=my-broker-deployment-*-svc-rte-my-openshift-project.my-openshift-domain
CN=my-broker-deployment-*-svc-rte-my-openshift-project.my-openshift-domain
이전 예에 표시된 CN은 my-broker-deployment 배포의 브로커 Pod로 성공적으로 확인되었습니다.
또한 브로커 인증서를 생성할 때 지정하는 SAN(주체 대체 이름)은 배포의 모든 브로커 Pod를 쉼표로 구분된 목록으로 나열해야 합니다. 예를 들면 다음과 같습니다.
"SAN=DNS:my-broker-deployment-0-svc-rte-my-openshift-project.my-openshift-domain,DNS:my-broker-deployment-1-svc-rte-my-openshift-project.my-openshift-domain,..."
"SAN=DNS:my-broker-deployment-0-svc-rte-my-openshift-project.my-openshift-domain,DNS:my-broker-deployment-1-svc-rte-my-openshift-project.my-openshift-domain,..."
4.12.3. 브로커 배포의 네트워킹 서비스 링크 복사링크가 클립보드에 복사되었습니다!
브로커 배포를 위한 OpenShift Container Platform 웹 콘솔의 네트워킹 창에는 헤드리스 서비스와 ping 서비스라는 두 가지 서비스가 실행되고 있습니다. 헤드리스 서비스의 기본 이름은 < custom_resource_name> -hdls-svc 형식을 사용합니다(예: my-broker-deployment-hdls-svc ). ping 서비스의 기본 이름은 < custom_resource_name> -ping-svc 형식을 사용합니다(예: 'my-broker-deployment-ping-svc ).
헤드리스 서비스는 내부 브로커 클러스터링에 사용되는 포트 61616에 대한 액세스를 제공합니다.
ping 서비스는 브로커가 검색하는 데 사용되며 브로커가 OpenShift 환경 내에서 클러스터를 형성할 수 있습니다. 내부적으로 이 서비스는 포트 8888을 노출합니다.
4.12.4. 내부 및 외부 클라이언트에서 브로커에 연결 링크 복사링크가 클립보드에 복사되었습니다!
이 섹션의 예제에서는 내부 클라이언트(즉, 브로커 배포와 동일한 OpenShift 클러스터에 있는 클라이언트) 및 외부 클라이언트(OpenShift 클러스터 외부의 클라이언트)에서 브로커에 연결하는 방법을 보여줍니다.
4.12.4.1. 내부 클라이언트에서 브로커에 연결 링크 복사링크가 클립보드에 복사되었습니다!
내부 클라이언트를 브로커에 연결하려면 클라이언트 연결 세부 사항에서 브로커 Pod의 DNS 확인 가능 이름을 지정합니다. 예를 들면 다음과 같습니다.
tcp://ex–aao-ss-0:<port>
$ tcp://ex–aao-ss-0:<port>
내부 클라이언트가 Core 프로토콜을 사용하고 useTopologyForLoadBalancing=false 키가 연결 URL에 설정되지 않은 경우 클라이언트가 브로커에 처음 연결되면 브로커는 클러스터에 있는 모든 브로커의 주소를 클라이언트에 알릴 수 있습니다. 그러면 클라이언트는 모든 브로커에서 연결을 로드 밸런싱할 수 있습니다.
브로커에 서브스크립션 대기열 또는 요청/응답 대기열이 있는 경우 클라이언트 연결이 부하 분산될 때 이러한 대기열을 사용하는 것과 관련된 경고에 유의하십시오. 자세한 내용은 4.12.4.4절. “ScanSetting 서브스크립션 대기열 또는 응답/요청 대기열이 있을 때 클라이언트 연결을 로드 밸런싱해야 합니다.”의 내용을 참조하십시오.
4.12.4.2. 외부 클라이언트에서 브로커에 연결 링크 복사링크가 클립보드에 복사되었습니다!
허용자를 외부 클라이언트(즉, expose 매개변수 값을 true로 설정하여)에 어셉터를 노출하면 Operator는 배포의 각 브로커 Pod에 대한 전용 서비스 및 경로를 자동으로 생성합니다.
외부 클라이언트는 브로커 pod에 대해 생성된 경로의 전체 호스트 이름을 지정하여 브로커에 연결할 수 있습니다. 기본 curl 명령을 사용하여 이 전체 호스트 이름에 대한 외부 액세스를 테스트할 수 있습니다. 예를 들면 다음과 같습니다.
curl https://my-broker-deployment-0-svc-rte-my-openshift-project.my-openshift-domain
$ curl https://my-broker-deployment-0-svc-rte-my-openshift-project.my-openshift-domain
브로커 포드의 전체 호스트 이름은 OpenShift 라우터를 호스팅하는 노드로 확인되어야 합니다. OpenShift 라우터는 호스트 이름을 사용하여 OpenShift 내부 네트워크 내에서 트래픽을 보낼 위치를 결정합니다. 기본적으로 OpenShift 라우터는 비보안(즉, SSL이 아닌) 트래픽과 보안(즉, SSL 암호화) 트래픽을 위해 포트 80을 수신 대기합니다. HTTP 연결의 경우 보안 연결 URL(즉, https) 또는 비보안 연결 URL(즉, http)을 지정하면 라우터에서 포트 443으로 자동으로 트래픽을 보냅니다.
외부 클라이언트가 클러스터의 브로커에 걸쳐 연결을 로드 밸런싱하도록 하려면 다음을 수행합니다.
-
각 브로커 포드에 대해 OpenShift 경로에서
haproxy.router.openshift.io/balanceroundrobin 옵션을 구성하여 로드 밸런싱을 활성화합니다. 외부 클라이언트가 Core 프로토콜을 사용하는 경우 클라이언트의 연결 URL에서
useTopologyForLoadBalancing=false키를 설정합니다.useTopologyForLoadBalancing=false키를 설정하면 클라이언트가 브로커에서 제공하는 클러스터 토폴로지 정보에 있는 AMQ Broker Pod DNS 이름을 사용할 수 없습니다. Pod DNS 이름은 외부 클라이언트가 액세스할 수 없는 내부 IP 주소로 확인됩니다.
브로커에 서브스크립션 대기열 또는 요청/응답 대기열이 있는 경우 로드 밸런싱 클라이언트 연결 시 이러한 대기열을 사용하는 것과 관련된 경고에 유의하십시오. 자세한 내용은 4.12.4.4절. “ScanSetting 서브스크립션 대기열 또는 응답/요청 대기열이 있을 때 클라이언트 연결을 로드 밸런싱해야 합니다.”의 내용을 참조하십시오.
외부 클라이언트가 클러스터의 브로커 간에 연결을 로드 밸런싱하지 않도록 하려면 다음을 수행합니다.
- 각 클라이언트의 연결 URL에서 각 브로커 Pod에 대한 경로의 전체 호스트 이름을 지정합니다. 클라이언트는 연결 URL의 첫 번째 호스트 이름에 연결을 시도합니다. 그러나 첫 번째 호스트 이름을 사용할 수 없는 경우 클라이언트는 연결 URL의 다음 호스트 이름에 자동으로 연결됩니다.
-
외부 클라이언트가 Core 프로토콜을 사용하는 경우 클라이언트 연결 URL에서
useTopologyForLoadBalancing=false키를 설정하여 클라이언트가 브로커에서 제공하는 클러스터 토폴로지 정보를 사용하지 않도록 합니다.
HTTP가 아닌 연결의 경우:
- 클라이언트는 연결 URL의 일부로 포트 번호(예: 포트 443)를 명시적으로 지정해야 합니다.
- 양방향 TLS의 경우 클라이언트는 연결 URL의 일부로 신뢰 저장소의 경로와 해당 암호를 지정해야 합니다.
- 양방향 TLS의 경우 클라이언트는 키 저장소의 경로와 해당 암호를 연결 URL의 일부로 지정해야 합니다.
지원되는 메시징 프로토콜에 대한 일부 클라이언트 연결 URL 예는 다음과 같습니다.
단방향 TLS 사용 외부 코어 클라이언트
tcp://my-broker-deployment-0-svc-rte-my-openshift-project.my-openshift-domain:443?useTopologyForLoadBalancing=false&sslEnabled=true \ &trustStorePath=~/client.ts&trustStorePassword=<password>
tcp://my-broker-deployment-0-svc-rte-my-openshift-project.my-openshift-domain:443?useTopologyForLoadBalancing=false&sslEnabled=true \
&trustStorePath=~/client.ts&trustStorePassword=<password>
외부 Core 클라이언트는 브로커가 반환된 토폴로지 정보를 사용할 수 없기 때문에 연결 URL에서 useTopologyForLoadBalancing 키가 명시적으로 false 로 설정됩니다. 이 키가 true 로 설정되어 있거나 값을 지정하지 않으면 DEBUG 로그 메시지가 생성됩니다.
양방향 TLS 사용 외부 코어 클라이언트
tcp://my-broker-deployment-0-svc-rte-my-openshift-project.my-openshift-domain:443?useTopologyForLoadBalancing=false&sslEnabled=true \ &keyStorePath=~/client.ks&keyStorePassword=<password> \ &trustStorePath=~/client.ts&trustStorePassword=<password>
tcp://my-broker-deployment-0-svc-rte-my-openshift-project.my-openshift-domain:443?useTopologyForLoadBalancing=false&sslEnabled=true \
&keyStorePath=~/client.ks&keyStorePassword=<password> \
&trustStorePath=~/client.ts&trustStorePassword=<password>
외부 OpenWire 클라이언트, 단방향 TLS 사용
ssl://my-broker-deployment-0-svc-rte-my-openshift-project.my-openshift-domain:443" # Also, specify the following JVM flags -Djavax.net.ssl.trustStore=~/client.ts -Djavax.net.ssl.trustStorePassword=<password>
ssl://my-broker-deployment-0-svc-rte-my-openshift-project.my-openshift-domain:443"
# Also, specify the following JVM flags
-Djavax.net.ssl.trustStore=~/client.ts -Djavax.net.ssl.trustStorePassword=<password>
양방향 TLS 사용 외부 OpenWire 클라이언트
ssl://my-broker-deployment-0-svc-rte-my-openshift-project.my-openshift-domain:443" # Also, specify the following JVM flags -Djavax.net.ssl.keyStore=~/client.ks -Djavax.net.ssl.keyStorePassword=<password> \ -Djavax.net.ssl.trustStore=~/client.ts -Djavax.net.ssl.trustStorePassword=<password>
ssl://my-broker-deployment-0-svc-rte-my-openshift-project.my-openshift-domain:443"
# Also, specify the following JVM flags
-Djavax.net.ssl.keyStore=~/client.ks -Djavax.net.ssl.keyStorePassword=<password> \
-Djavax.net.ssl.trustStore=~/client.ts -Djavax.net.ssl.trustStorePassword=<password>
단방향 TLS 사용 외부 AMQP 클라이언트
amqps://my-broker-deployment-0-svc-rte-my-openshift-project.my-openshift-domain:443?transport.verifyHost=true \ &transport.trustStoreLocation=~/client.ts&transport.trustStorePassword=<password>
amqps://my-broker-deployment-0-svc-rte-my-openshift-project.my-openshift-domain:443?transport.verifyHost=true \
&transport.trustStoreLocation=~/client.ts&transport.trustStorePassword=<password>
양방향 TLS 사용 외부 AMQP 클라이언트
amqps://my-broker-deployment-0-svc-rte-my-openshift-project.my-openshift-domain:443?transport.verifyHost=true \ &transport.keyStoreLocation=~/client.ks&transport.keyStorePassword=<password> \ &transport.trustStoreLocation=~/client.ts&transport.trustStorePassword=<password>
amqps://my-broker-deployment-0-svc-rte-my-openshift-project.my-openshift-domain:443?transport.verifyHost=true \
&transport.keyStoreLocation=~/client.ks&transport.keyStorePassword=<password> \
&transport.trustStoreLocation=~/client.ts&transport.trustStorePassword=<password>
4.12.4.3. NodePort를 사용하여 브로커에 연결 링크 복사링크가 클립보드에 복사되었습니다!
OpenShift 관리자는 경로를 사용하는 대신 OpenShift 외부 클라이언트에서 브로커 포드에 연결하도록 NodePort를 구성할 수 있습니다. NodePort는 브로커에 대해 구성된 수락자가 지정한 프로토콜별 포트 중 하나에 매핑해야 합니다.
기본적으로 NodePort는 30000~32767 범위에 있습니다. 즉, NodePort가 일반적으로 브로커 Pod의 의도된 포트와 일치하지 않습니다.
NodePort를 통해 OpenShift 외부의 클라이언트에서 브로커에 연결하려면 < protocol > :// <ocp_node_ip> : <node_ port_number > 형식으로 URL을 지정합니다.
4.12.4.4. ScanSetting 서브스크립션 대기열 또는 응답/요청 대기열이 있을 때 클라이언트 연결을 로드 밸런싱해야 합니다. 링크 복사링크가 클립보드에 복사되었습니다!
Cryostat 서브스크립션
Cryostat 서브스크립션은 브로커의 큐로 표시되며, 지속성 구독자가 브로커에 처음 연결할 때 생성됩니다. 이 큐가 존재하며 클라이언트가 구독을 취소할 때까지 메시지를 수신합니다. 클라이언트가 다른 브로커에 다시 연결되면 해당 브로커에 또 다른 Cryostat 서브스크립션 큐가 생성됩니다. 이로 인해 다음 문제가 발생할 수 있습니다.
| 문제 |
| 완화 방법 |
| 원본 서브스크립션 큐에서 메시지가 중단될 수 있습니다. |
|
주소 또는 주소 집합에 대한
이 예에서 브로커는 메시지를 다른 브로커에 재배포하기 전에 대기열의 최종 소비자가 닫히는 후 5000 밀리초를 기다립니다. 메시지 재배포에 대한 자세한 내용은 메시지 재배포 활성화를 참조하십시오. |
| 다른 메시지가 계속 라우팅될 때 메시지 재배포 중 창이 있기 때문에 잘못된 순서로 메시지가 수신될 수 있습니다. |
| 없음. |
| 클라이언트가 구독을 취소하면 마지막으로 연결된 브로커에서만 큐가 삭제됩니다. 즉, 다른 큐가 계속 존재하고 메시지를 수신할 수 있습니다. |
|
구독 취소한 클라이언트에 대해 존재할 수 있는 다른 빈 큐를 삭제하려면 주소 또는 주소 집합에 대해 다음 속성을 모두 구성합니다.
자세한 내용은 주소 및 큐의 자동 생성 및 삭제 구성을 참조하십시오. |
요청/수정 대기열
JMS Producer에서 임시 응답 대기열을 생성하면 브로커에 큐가 생성됩니다. 작업 대기열에서 사용하는 클라이언트가 임시 큐에 응답하는 경우 다른 브로커에 연결하는 경우 다음과 같은 문제가 발생할 수 있습니다.
| 문제 | 완화 방법 |
|---|---|
| 클라이언트가 연결된 브로커에 응답 큐가 존재하지 않으므로 클라이언트가 오류를 생성할 수 있습니다. |
클라이언트가 존재하지 않는 큐에 연결하도록 요청할 때 큐를 자동으로 생성하도록 브로커를 구성합니다. 자동 큐 생성을 구성하려면
|
| 작업 큐로 전송된 메시지는 배포되지 않을 수 있습니다. |
또한 주소 또는 주소 집합에 대한
자세한 내용은 메시지 재배포 활성화를 참조하십시오. |
추가 리소스
클러스터에서 실행 중인 서비스와 OpenShift 클러스터 외부에서 통신하기 위해 경로 및 NodePort와 같은 방법을 사용하는 방법에 대한 자세한 내용은 다음을 참조하십시오.
- OpenShift Container Platform 설명서의 수신 클러스터 트래픽 구성 개요.