4.12. 클라이언트 연결을 위한 Operator 기반 브로커 배포 구성


4.12.1. 어셉터 구성

OpenShift 배포에서 브로커 Pod에 대한 클라이언트 연결을 활성화하려면 배포에 대한 허용자를 정의합니다. 승인자는 브로커 pod에서 연결을 허용하는 방법을 정의합니다. 브로커 배포에 사용되는 기본 CR(사용자 정의 리소스)에 허용자를 정의합니다. 어셉터를 생성할 때 수락자에서 활성화할 메시징 프로토콜과 이러한 프로토콜에 사용할 브로커 Pod의 포트와 같은 정보를 지정합니다.

프로세스

  1. 브로커 배포에 대한 ActiveMQArtemis CR(사용자 정의 리소스)을 편집합니다.
  2. acceptors 특성에 이름이 지정된 어셉터를 추가합니다. 프로토콜포트 속성을 추가합니다. 값을 설정하여 어셉터에서 사용할 메시징 프로토콜과 해당 프로토콜에 노출할 각 브로커 Pod의 포트를 지정합니다. 예를 들면 다음과 같습니다.

    spec:
      ..
      acceptors:
      - name: my-acceptor
        protocols: amqp
        port: 5672
      ..
    Copy to Clipboard Toggle word wrap

    구성된 수락자는 포트 5672를 AMQP 클라이언트에 노출합니다. protocols 특성에 지정할 수 있는 전체 값 세트가 표에 표시됩니다.

    Expand
    표 4.4. acceptor 프로토콜
    프로토콜현재의

    코어 프로토콜

    코어

    AMQP

    amqp

    OpenWire

    OpenWire

    MQTT

    mqtt

    STOMP

    stomp

    지원되는 모든 프로토콜

    all

    참고
    • 배포의 각 브로커 Pod에 대해 Operator는 포트 61616을 사용하는 기본 수락자도 생성합니다. 이 기본 수락자는 브로커 클러스터링에 필요하며 코어 프로토콜이 활성화되어 있습니다.
    • 기본적으로 AMQ Broker 관리 콘솔은 브로커 Pod에서 포트 8161을 사용합니다. 배포의 각 브로커 포드에는 콘솔에 대한 액세스를 제공하는 전용 서비스가 있습니다. 자세한 내용은 5장. Operator 기반 브로커 배포를 위한 AMQ 관리 콘솔에 연결의 내용을 참조하십시오.
  3. 동일한 수락자에서 다른 프로토콜을 사용하려면 protocols 속성을 수정합니다. 쉼표로 구분된 프로토콜 목록을 지정합니다. 예를 들면 다음과 같습니다.

    spec:
     ..
      acceptors:
      - name: my-acceptor
        protocols: amqp,openwire
        port: 5672
    ...
    Copy to Clipboard Toggle word wrap

    구성된 수락자는 이제 포트 5672를 AMQP 및 OpenWire 클라이언트에 노출합니다.

  4. 허용자가 허용하는 동시 클라이언트 연결 수를 지정하려면 connectionsAllowed 속성을 추가하고 값을 설정합니다. 예를 들면 다음과 같습니다.

    spec:
      ...
      acceptors:
      - name: my-acceptor
        protocols: amqp,openwire
        port: 5672
        connectionsAllowed: 5
      ...
    Copy to Clipboard Toggle word wrap
  5. 기본적으로 수락자는 브로커 배포와 동일한 OpenShift 클러스터의 클라이언트에만 노출됩니다. OpenShift 외부의 클라이언트에 어셉터도 노출하려면 expose 속성과 sslEnabled 속성을 모두 true 로 설정합니다.

    spec:
      ...
      acceptors:
      - name: my-acceptor
        protocols: amqp,openwire
        port: 5672
        connectionsAllowed: 5
        expose: true
        sslEnabled: true
      ...
    Copy to Clipboard Toggle word wrap

    수락자(또는 커넥터)에서 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 경로를 자동으로 생성합니다.

  6. 각 pod에서 허용자가 Openshift 클러스터의 내부 라우팅 구성과 일치하도록 허용되는 경로의 호스트 이름을 사용자 지정하려면 다음 중 하나 또는 둘 다를 수행할 수 있습니다.

    • ingressHost 특성을 사용하여 기본 호스트 이름을 특정 수락자의 사용자 지정 호스트 이름으로 바꿉니다.
    • ingressDomain 특성을 사용하여 호스트 이름에 사용자 지정 도메인을 추가합니다. 사용자 정의 도메인은 CR 구성에 의해 노출되는 다른 어셉터 및 콘솔과 같은 다른 모든 경로에도 적용됩니다.

      1. acceptor 경로에 사용자 정의 호스트 이름을 설정하려면 ingressHost 속성을 추가하고 호스트 문자열을 지정합니다. 예를 들면 다음과 같습니다.

        spec:
          ...
          acceptors:
          - name: my-acceptor
            protocols: amqp,openwire
            port: 5672
            connectionsAllowed: 5
            expose: true
            ingressHost: my-acceptor-production.my-subdomain.com
          ...
        Copy to Clipboard Toggle word wrap
        참고

        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 속성의 값입니다.

      2. 경로의 호스트 이름에 사용자 정의 도메인을 추가하려면 spec.ingressDomain 속성을 추가하고 사용자 정의 문자열을 지정합니다. 예를 들면 다음과 같습니다.

        spec:
          ...
          ingressDomain: my.domain.com
        Copy to Clipboard Toggle word wrap
  7. 조직의 네트워크 정책에서 경로 대신 Ingress를 사용하여 수락자를 노출해야 하는 경우 다음 단계를 완료합니다.

    1. exposeMode 속성을 추가하고 값을 ingress 로 설정합니다.

      spec:
        ...
        acceptors:
        - name: my-acceptor
          protocols: amqp,openwire
          port: 5672
          connectionsAllowed: 5
          expose: true
          exposeMode: ingress
        ...
      Copy to Clipboard Toggle word wrap
    2. 허용자가 Openshift 클러스터의 내부 라우팅 구성과 일치하도록 노출된 Ingress의 호스트 이름을 사용자 지정하려면 다음 중 하나 또는 둘 다를 수행할 수 있습니다.

      • ingressHost 특성을 사용하여 기본 호스트 이름을 사용자 지정 호스트 이름으로 교체합니다.
      • ingressDomain 특성을 사용하여 호스트 이름에 사용자 지정 도메인을 추가합니다. 사용자 정의 도메인은 CR 구성에 의해 노출되는 다른 어셉터 및 콘솔의 Ingress와 같은 기타 모든 수신에도 적용됩니다.

        1. acceptor의 Ingress에 대한 사용자 정의 호스트 이름을 설정하려면 ingressHost 속성을 추가하고 호스트 문자열을 지정합니다. 예를 들면 다음과 같습니다.

          spec:
            ...
            acceptors:
            - name: my-acceptor
              protocols: amqp,openwire
              port: 5672
              connectionsAllowed: 5
              expose: true
              exposeMode: ingress
              ingressHost: my-acceptor-production.my-subdomain.com
            ...
          Copy to Clipboard Toggle word wrap

          동일한 변수를 포함하여 이 절차의 앞부분에서 설명하는 경로 호스트로 수신 호스트를 사용자 지정할 수 있습니다.

        2. Ingress의 호스트 이름에 사용자 정의 도메인을 추가하려면 spec.ingressDomain 속성을 추가하고 사용자 지정 문자열을 지정합니다. 예를 들면 다음과 같습니다.

          spec:
            ...
            ingressDomain: my-subdomain.domain.com
          Copy to Clipboard Toggle word wrap

          어셉터의 경우 수신의 기본 호스트 이름은 < cr-name>-<acceptor name>-<ordinal>-svc-ing-<namespace > 형식으로 되어 있습니다. 예를 들어 amqbroker 네임 스페이스에 production 이라는 CR이 있는 경우 mydomain.comingressDomain 값은 Pod 0에서 생성된 수신에 대해 production-wconsj-0-svc-svc-mynamespace.amqbroker.com 의 호스트 값을 제공합니다.

추가 리소스

4.12.2. broker-client 연결 보안

수락자 또는 커넥터(즉, sslEnabledtrue로 설정하여 보안)에서 보안을 활성화한 경우 브로커와 클라이언트 간의 인증서 기반 인증을 허용하도록 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.crttls.key에 각각 저장됩니다.

참고

서비스 인증서를 발급하는 서비스 CA 인증서는 26개월 동안 유효하며 유효 기간이 13개월 미만으로 남아 있으면 자동으로 순환됩니다. 교체 후에도 이전 서비스 CA 구성은 만료될 때까지 계속 신뢰 상태가 유지됩니다. 그러면 만료되기 전에 유예 기간 동안 영향을 받는 모든 서비스의 주요 자료를 새로 고칠 수 있습니다. 서비스를 다시 시작하고 키 자료를 새로 고치는 이 유예 기간 동안 클러스터를 업그레이드하지 않으면 이전 서비스 CA가 만료된 후 실패하지 않도록 서비스를 직접 다시 시작해야 할 수도 있습니다.

프로세스

  1. 브로커 배포에 사용할 ActiveMQArtemis CR(사용자 정의 리소스)을 편집합니다.
  2. resourceTemplates 속성을 사용하여 수락자에 대해 생성된 서비스에 주석을 답니다. 예를 들면 다음과 같습니다.

    spec:
      ...
      resourceTemplates:
        - selector:
            kind: Service
            name: amq-broker-myacceptor-0-svc
          annotations:
            service.beta.openshift.io/serving-cert-secret-name: myacceptor-ptls
      ...
    Copy to Clipboard Toggle word wrap
    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에 할당된 서수입니다.
    resourceTemplates.annotations

    service.beta.openshift.io/serving-cert-secret-name: < secret >의 주석을 지정합니다. 여기서 <secret>은 Openshift가 서비스에 생성하는 시크릿의 이름입니다.

    참고

    시크릿 이름은 acceptor 이름과 일치해야 하며 -ptls 접미사가 있어야 합니다. Operator에서 시크릿을 생성하기 전에 CR을 배포할 수 있도록 하려면 특정 접미사가 필요합니다.

  3. CR의 sslSecret' 속성에서 브로커 인증서가 포함된 보안을 지정합니다. 예를 들면 다음과 같습니다.

    spec:
      acceptors:
        - name: myacceptor
          protocols: CORE
          port: 61626
          sslEnabled: true
          sslSecret: myacceptor-ptls
    Copy to Clipboard Toggle word wrap
  4. brokerProperties 속성에서 인증서가 Openshift에서 갱신될 때마다 새 인증서를 자동으로 로드하도록 브로커를 구성합니다. 예를 들면 다음과 같습니다.

    spec:
      ...
      brokerProperties
      - "acceptorConfigurations.myacceptor.params.sslAutoReload=true"
       ...
    Copy to Clipboard Toggle word wrap
  5. 서비스 제공 인증서의 공개 키를 각 클라이언트의 신뢰 저장소에 추가합니다.
  6. 브로커와 클라이언트 간에 mTLS 인증을 구성하려면 다음 단계를 완료합니다.

    1. 브로커가 신뢰할 각 클라이언트의 인증서가 포함된 신뢰 번들을 생성하고 시크릿(예:trusted-clients-bundle )에 신뢰 번들을 추가합니다.
    2. 브로커 CR에 구성된 승인자에서 needClientAuth 속성을 추가하고 클라이언트 인증을 요구하도록 true 로 설정합니다. 예를 들면 다음과 같습니다.

      spec:
        ..
        acceptors:
          - name: myacceptor
            protocols: all
            port: 62666
            sslEnabled: true
            sslSecret: myacceptor-ptls
            needClientAuth: true
        ..
      Copy to Clipboard Toggle word wrap
    3. 각 수락자의 trustSecret 속성에서 클라이언트 인증서의 신뢰 번들이 포함된 보안을 지정합니다. 예를 들면 다음과 같습니다.

      spec:
        ..
        acceptors:
          - name: new-acceptor
            protocols: all
            port: 62666
            sslEnabled: true
            sslSecret: myacceptor-ptls
            needClientAuth: true
            trustSecret: trusted-clients-bundle
        ..
      Copy to Clipboard Toggle word wrap
  7. 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를 사용하여 인증서를 요청할 수 있습니다.

사전 요구 사항

프로세스

  1. 자체 서명된 발행자를 정의하는 YAML 파일(예: self-signed-issuer.yaml )을 생성합니다. 발행자는 인증서 서명 요청을 준수하여 서명된 인증서를 생성할 수 있는 CA(인증 기관)를 나타내는 Openshift 리소스입니다.

    다음 예제 yaml은 자체 서명된 발급자를 생성하여 이를 사용하여 인증 기관(CA) 인증서를 생성할 수 있습니다. CA 인증서는 cert-manager Operator에서 관리할 수 있습니다.

    apiVersion: cert-manager.io/v1
    kind: ClusterIssuer
    metadata:
      name: root-issuer
    spec:
      selfSigned: {}
    Copy to Clipboard Toggle word wrap
  2. 루트 CA 인증서를 정의하는 YAML 파일(예: root-ca.yaml )을 생성합니다.

    issuerRef.name 필드에서 사용자가 생성한 자체 서명된 발급자인 root-issuer 의 이름을 지정합니다. 예를 들면 다음과 같습니다.

    apiVersion: cert-manager.io/v1
    kind: Certificate
    metadata:
      name: root-ca
      namespace: cert-manager
    spec:
      isCA: true
      commonName: "amq.io.root"
      secretName: root-ca-secret
      subject:
        organizations:
        - "www.amq.io"
      issuerRef:
        name: root-issuer
        kind: ClusterIssuer
    Copy to Clipboard Toggle word wrap

    인증서는 root-ca-secret 이라는 시크릿의 Privacy Enhanced mail (PEM) 형식으로 생성됩니다.

  3. 루트 CA에서 서명한 인증서 발행을 위한 CA 발행자를 정의하는 YAML 파일(예: root-ca-issuer.yaml )을 생성합니다. 예를 들면 다음과 같습니다.

    apiVersion: cert-manager.io/v1
    kind: ClusterIssuer
    metadata:
      name: root-ca-issuer
    spec:
      ca:
        secretName: root-ca-secret
    Copy to Clipboard Toggle word wrap
  4. 브로커 인증서를 정의하는 YAML 파일(예: broker-cert.yaml )을 생성합니다.

    issuerRef.Name 필드에서 루트 CA에서 서명한 인증서를 발행하기 위해 생성한 발급자인 root-ca-issuer 의 이름을 지정합니다. 예를 들면 다음과 같습니다.

    apiVersion: cert-manager.io/v1
    kind: Certificate
    Metadata:
     name: broker-cert
    spec:
     isCA: false
     commonName: “amq.io”
     dnsNames:
       - “amq-broker-ss-0.amq-broker-svc-rte-default.cluster.local
       - “amq-broker-ss-1.amq-broker-svc-rte-default.cluster.local
     secretName: broker-cert-secret
     subject:
       organizations:
       - “www.amq.io”
     issuerRef:
       name: root-ca-issuer
       kind: ClusterIssuer
    Copy to Clipboard Toggle word wrap
  5. 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
    Copy to Clipboard Toggle word wrap
  6. 브로커 배포를 위해 ActiveMQArtemis CR을 편집합니다.
  7. 보안하려는 각 수락자의 sslSecret 속성에 브로커 인증서가 포함된 보안을 지정합니다. 예를 들면 다음과 같습니다.

    spec:
      ..
      acceptors:
        - name: new-acceptor
          protocols: all
          port: 62666
          sslEnabled: true
          needClientAuth: false
          sslSecret: broker-cert-secret
      ..
    Copy to Clipboard Toggle word wrap
  8. brokerProperties 속성에서 cert-manager Operator가 Openshift용 cert-manager Operator에 의해 갱신될 때마다 수락자에 대한 새 브로커 인증서를 자동으로 로드하도록 브로커를 구성합니다. 예를 들면 다음과 같습니다.

    spec:
      ...
      brokerProperties
      - "acceptorConfigurations.new-acceptor.params.sslAutoReload=true"
       ...
    Copy to Clipboard Toggle word wrap
  9. 클라이언트가 브로커를 신뢰할 수 있도록 이 예제 프로세스의 root-ca-secret 시크릿에 생성된 브로커 인증서에 서명한 루트 CA 인증서를 각 클라이언트의 신뢰 저장소에 추가합니다.
  10. 브로커와 클라이언트 간에 mTLS 인증을 구성하려면 다음 단계를 완료합니다.

    1. Kubernetes용 Trust Manager를 사용하여 브로커가 신뢰하려는 각 클라이언트의 인증서가 포함된 신뢰 번들을 생성하고 시크릿(예:trusted-clients-bundle )에 신뢰 번들을 추가합니다. 신뢰 번들을 생성하는 방법에 대한 자세한 내용은 trust-manager 설명서 를 참조하십시오.
    2. 브로커 CR에 구성된 승인자에서 needClientAuth 속성을 추가하고 클라이언트 인증을 요구하도록 true 로 설정합니다. 예를 들면 다음과 같습니다.

      spec:
        ..
        acceptors:
          - name: new-acceptor
            protocols: all
            port: 62666
            sslEnabled: true
            sslSecret: broker-cert-secret
            needClientAuth: true
        ..
      Copy to Clipboard Toggle word wrap
    3. 각 수락자의 trustSecret 속성에서 클라이언트 인증서의 신뢰 번들이 포함된 보안을 지정합니다. 예를 들면 다음과 같습니다.

      spec:
        ..
        acceptors:
          - name: new-acceptor
            protocols: all
            port: 62666
            sslEnabled: true
            sslSecret: broker-cert-secret
            needClientAuth: true
            trustSecret: trusted-clients-bundle
        ..
      Copy to Clipboard Toggle word wrap
  11. CR을 저장합니다.

4.12.2.3. Java keytool 유틸리티 사용

keytool은 Java에 포함된 인증서 관리 유틸리티입니다.

4.12.2.3.1. 단방향 TLS 구성

이 섹션의 절차에서는 브로커-클라이언트 연결을 보호하도록 단방향 TLS(Transport Layer Security)를 구성하는 방법을 보여줍니다.

단방향 TLS에서는 브로커만 인증서를 제공합니다. 이 인증서는 클라이언트가 브로커를 인증하는 데 사용됩니다.

사전 요구 사항

프로세스

  1. 브로커 키 저장소에 대한 자체 서명 인증서를 생성합니다.

    $ keytool -genkey -alias broker -keyalg RSA -keystore ~/broker.ks
    Copy to Clipboard Toggle word wrap
  2. 클라이언트와 공유할 수 있도록 브로커 키 저장소에서 인증서를 내보냅니다. Base64로 인코딩된 .pem 형식으로 인증서를 내보냅니다. 예를 들면 다음과 같습니다.

    $ keytool -export -alias broker -keystore ~/broker.ks -file ~/broker_cert.pem
    Copy to Clipboard Toggle word wrap
  3. 클라이언트에서 브로커 인증서를 가져오는 클라이언트 신뢰 저장소를 생성합니다.

    $ keytool -import -alias broker -keystore ~/client.ts -file ~/broker_cert.pem
    Copy to Clipboard Toggle word wrap
  4. 관리자로 OpenShift Container Platform에 로그인합니다. 예를 들면 다음과 같습니다.

    $ oc login -u system:admin
    Copy to Clipboard Toggle word wrap
  5. 브로커 배포가 포함된 프로젝트로 전환합니다. 예를 들면 다음과 같습니다.

    $ oc project <my_openshift_project>
    Copy to Clipboard Toggle word wrap
  6. 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>
    Copy to Clipboard Toggle word wrap
    참고

    시크릿을 생성할 때 OpenShift에서 키 저장소와 신뢰 저장소를 모두 지정해야 합니다. 신뢰 저장소 키는 일반적으로 client.ts 로 이름이 지정됩니다. 브로커와 클라이언트 간의 단방향 TLS의 경우 실제로 신뢰 저장소가 필요하지 않습니다. 그러나 보안을 성공적으로 생성하려면 일부 유효한 저장소 파일을 client.ts 의 값으로 지정해야 합니다. 이전 단계에서는 이전에 생성한 브로커 키 저장소 파일을 재사용하여 client.ts 의 "더미" 값을 제공합니다. 이는 단방향 TLS에 필요한 모든 인증 정보를 사용하여 보안을 생성하는 데 충분합니다.

  7. Operator를 설치할 때 생성한 서비스 계정에 보안을 연결합니다. 예를 들면 다음과 같습니다.

    $ oc secrets link sa/amq-broker-operator secret/my-tls-secret
    Copy to Clipboard Toggle word wrap
  8. 보안 수락자 또는 커넥터의 sslSecret 매개변수에 시크릿 이름을 지정합니다. 예를 들면 다음과 같습니다.

    spec:
    ...
      acceptors:
      - name: my-acceptor
        protocols: amqp,openwire
        port: 5672
        sslEnabled: true
        sslSecret: my-tls-secret
        expose: true
        connectionsAllowed: 5
    ...
    Copy to Clipboard Toggle word wrap
4.12.2.3.2. 양방향 TLS 구성

이 섹션의 절차에서는 브로커-클라이언트 연결을 보호하도록 양방향 TLS(Transport Layer Security)를 구성하는 방법을 보여줍니다.

양방향 TLS에서 브로커와 클라이언트 모두 인증서를 제공합니다. 브로커 및 클라이언트는 이러한 인증서를 사용하여 때때로 상호 인증 이라는 프로세스에서 서로 인증합니다.

사전 요구 사항

프로세스

  1. 브로커 키 저장소에 대한 자체 서명 인증서를 생성합니다.

    $ keytool -genkey -alias broker -keyalg RSA -keystore ~/broker.ks
    Copy to Clipboard Toggle word wrap
  2. 클라이언트와 공유할 수 있도록 브로커 키 저장소에서 인증서를 내보냅니다. Base64로 인코딩된 .pem 형식으로 인증서를 내보냅니다. 예를 들면 다음과 같습니다.

    $ keytool -export -alias broker -keystore ~/broker.ks -file ~/broker_cert.pem
    Copy to Clipboard Toggle word wrap
  3. 클라이언트에서 브로커 인증서를 가져오는 클라이언트 신뢰 저장소를 생성합니다.

    $ keytool -import -alias broker -keystore ~/client.ts -file ~/broker_cert.pem
    Copy to Clipboard Toggle word wrap
  4. 클라이언트에서 클라이언트 키 저장소에 대한 자체 서명된 인증서를 생성합니다.

    $ keytool -genkey -alias broker -keyalg RSA -keystore ~/client.ks
    Copy to Clipboard Toggle word wrap
  5. 클라이언트에서 브로커와 공유할 수 있도록 클라이언트 키 저장소에서 인증서를 내보냅니다. Base64로 인코딩된 .pem 형식으로 인증서를 내보냅니다. 예를 들면 다음과 같습니다.

    $ keytool -export -alias broker -keystore ~/client.ks -file ~/client_cert.pem
    Copy to Clipboard Toggle word wrap
  6. 클라이언트 인증서를 가져오는 브로커 신뢰 저장소를 생성합니다.

    $ keytool -import -alias broker -keystore ~/broker.ts -file ~/client_cert.pem
    Copy to Clipboard Toggle word wrap
  7. 관리자로 OpenShift Container Platform에 로그인합니다. 예를 들면 다음과 같습니다.

    $ oc login -u system:admin
    Copy to Clipboard Toggle word wrap
  8. 브로커 배포가 포함된 프로젝트로 전환합니다. 예를 들면 다음과 같습니다.

    $ oc project <my_openshift_project>
    Copy to Clipboard Toggle word wrap
  9. 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>
    Copy to Clipboard Toggle word wrap
    참고

    시크릿을 생성할 때 OpenShift에서 키 저장소와 신뢰 저장소를 모두 지정해야 합니다. 신뢰 저장소 키는 일반적으로 client.ts 로 이름이 지정됩니다. 브로커와 클라이언트 간의 양방향 TLS의 경우 클라이언트 인증서가 있으므로 브로커 신뢰 저장소를 포함하는 시크릿을 생성해야 합니다. 따라서 이전 단계에서 client.ts 키에 대해 지정하는 값은 실제로 브로커 신뢰 저장소 파일입니다.

  10. Operator를 설치할 때 생성한 서비스 계정에 보안을 연결합니다. 예를 들면 다음과 같습니다.

    $ oc secrets link sa/amq-broker-operator secret/my-tls-secret
    Copy to Clipboard Toggle word wrap
  11. 보안 수락자 또는 커넥터의 sslSecret 매개변수에 시크릿 이름을 지정합니다. 예를 들면 다음과 같습니다.

    spec:
    ...
      acceptors:
      - name: my-acceptor
        protocols: amqp,openwire
        port: 5672
        sslEnabled: true
        sslSecret: my-tls-secret
        expose: true
        connectionsAllowed: 5
    ...
    Copy to Clipboard Toggle word wrap

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
Copy to Clipboard Toggle word wrap

CN이 여러 브로커가 있는 배포에서 브로커 Pod를 확인할 수 있도록 브로커 Pod 대신 별표(*) 와일드카드 문자를 지정할 수 있습니다. 예를 들면 다음과 같습니다.

CN=my-broker-deployment-*-svc-rte-my-openshift-project.my-openshift-domain
Copy to Clipboard Toggle word wrap

이전 예에 표시된 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,..."
Copy to Clipboard Toggle word wrap

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>
Copy to Clipboard Toggle word wrap

내부 클라이언트가 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
Copy to Clipboard Toggle word wrap

브로커 포드의 전체 호스트 이름은 OpenShift 라우터를 호스팅하는 노드로 확인되어야 합니다. OpenShift 라우터는 호스트 이름을 사용하여 OpenShift 내부 네트워크 내에서 트래픽을 보낼 위치를 결정합니다. 기본적으로 OpenShift 라우터는 비보안(즉, SSL이 아닌) 트래픽과 보안(즉, SSL 암호화) 트래픽을 위해 포트 80을 수신 대기합니다. HTTP 연결의 경우 보안 연결 URL(즉, https) 또는 비보안 연결 URL(즉, http)을 지정하면 라우터에서 포트 443으로 자동으로 트래픽을 보냅니다.

외부 클라이언트가 클러스터의 브로커에 걸쳐 연결을 로드 밸런싱하도록 하려면 다음을 수행합니다.

  • 각 브로커 포드에 대해 OpenShift 경로에서 haproxy.router.openshift.io/balance roundrobin 옵션을 구성하여 로드 밸런싱을 활성화합니다.
  • 외부 클라이언트가 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>
Copy to Clipboard Toggle word wrap

참고

외부 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>
Copy to Clipboard Toggle word wrap

외부 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>
Copy to Clipboard Toggle word wrap

양방향 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>
Copy to Clipboard Toggle word wrap

단방향 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>
Copy to Clipboard Toggle word wrap

양방향 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>
Copy to Clipboard Toggle word wrap

4.12.4.3. NodePort를 사용하여 브로커에 연결

OpenShift 관리자는 경로를 사용하는 대신 OpenShift 외부 클라이언트에서 브로커 포드에 연결하도록 NodePort를 구성할 수 있습니다. NodePort는 브로커에 대해 구성된 수락자가 지정한 프로토콜별 포트 중 하나에 매핑해야 합니다.

기본적으로 NodePort는 30000~32767 범위에 있습니다. 즉, NodePort가 일반적으로 브로커 Pod의 의도된 포트와 일치하지 않습니다.

NodePort를 통해 OpenShift 외부의 클라이언트에서 브로커에 연결하려면 < protocol > :// <ocp_node_ip> : <node_ port_number > 형식으로 URL을 지정합니다.

Cryostat 서브스크립션

Cryostat 서브스크립션은 브로커의 큐로 표시되며, 지속성 구독자가 브로커에 처음 연결할 때 생성됩니다. 이 큐가 존재하며 클라이언트가 구독을 취소할 때까지 메시지를 수신합니다. 클라이언트가 다른 브로커에 다시 연결되면 해당 브로커에 또 다른 Cryostat 서브스크립션 큐가 생성됩니다. 이로 인해 다음 문제가 발생할 수 있습니다.

Expand
표 4.6. Cryostat 서브스크립션 관련 문제

문제

완화 방법

원본 서브스크립션 큐에서 메시지가 중단될 수 있습니다.

주소 또는 주소 집합에 대한 redistributionDelay 속성을 설정하여 메시지 배포를 활성화합니다. ActiveMQArtemis CR의 brokerProperties 속성 아래에 이 속성을 설정할 수 있습니다. 예를 들면 다음과 같습니다.

addressSettings.<address>.redistributionDelay=5000.

이 예에서 브로커는 메시지를 다른 브로커에 재배포하기 전에 대기열의 최종 소비자가 닫히는 후 5000 밀리초를 기다립니다.

메시지 재배포에 대한 자세한 내용은 메시지 재배포 활성화를 참조하십시오.

다른 메시지가 계속 라우팅될 때 메시지 재배포 중 창이 있기 때문에 잘못된 순서로 메시지가 수신될 수 있습니다.

없음.

클라이언트가 구독을 취소하면 마지막으로 연결된 브로커에서만 큐가 삭제됩니다. 즉, 다른 큐가 계속 존재하고 메시지를 수신할 수 있습니다.

구독 취소한 클라이언트에 대해 존재할 수 있는 다른 빈 큐를 삭제하려면 주소 또는 주소 집합에 대해 다음 속성을 모두 구성합니다. ActiveMQArtemis CR의 brokerProperties 속성 아래에 이러한 속성을 설정할 수 있습니다.

addressSettings.<address>.autoDeleteQueuesMessageCount=0

addressSettings.<address>.autoDeleteQueuesDelay=5000

autoDeleteQueuesMessageCount 속성을 0 으로 설정하면 큐에 메시지가 없는 경우에만 큐가 삭제됩니다. autoDeleteQueuesDelay 속성 값은 메시지가 없는 큐가 삭제되지 않은 큐의 수입니다.

자세한 내용은 주소 및 큐의 자동 생성 및 삭제 구성을 참조하십시오.

요청/수정 대기열

JMS Producer에서 임시 응답 대기열을 생성하면 브로커에 큐가 생성됩니다. 작업 대기열에서 사용하는 클라이언트가 임시 큐에 응답하는 경우 다른 브로커에 연결하는 경우 다음과 같은 문제가 발생할 수 있습니다.

Expand
표 4.7. 요청/거절 대기열 문제
문제완화 방법

클라이언트가 연결된 브로커에 응답 큐가 존재하지 않으므로 클라이언트가 오류를 생성할 수 있습니다.

클라이언트가 존재하지 않는 큐에 연결하도록 요청할 때 큐를 자동으로 생성하도록 브로커를 구성합니다. 자동 큐 생성을 구성하려면 ActiveMQArtemis CR의 brokerProperties 속성 아래에 다음 속성을 추가합니다.

addressSettings.<address>.autoCreateQueues=true

작업 큐로 전송된 메시지는 배포되지 않을 수 있습니다.

ActiveMQArtemis CR의 brokerProperties 속성에 다음 속성을 추가하여 필요에 따라 로드 밸런싱을 활성화합니다.

clusterConfigurations.<cluster>.messageLoadBalancingType=ON-DEMAND.

또한 주소 또는 주소 집합에 대한 redistributionDelay 속성을 설정하여 메시지 배포를 활성화합니다. ActiveMQArtemis CR의 brokerProperties 속성 아래에 이 속성을 설정할 수 있습니다. 예를 들면 다음과 같습니다.

addressSettings<address>.redistributionDelay=5000

자세한 내용은 메시지 재배포 활성화를 참조하십시오.

추가 리소스

  • 클러스터에서 실행 중인 서비스와 OpenShift 클러스터 외부에서 통신하기 위해 경로 및 NodePort와 같은 방법을 사용하는 방법에 대한 자세한 내용은 다음을 참조하십시오.

Red Hat logoGithubredditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

Red Hat을 사용하는 고객은 신뢰할 수 있는 콘텐츠가 포함된 제품과 서비스를 통해 혁신하고 목표를 달성할 수 있습니다. 최신 업데이트를 확인하세요.

보다 포괄적 수용을 위한 오픈 소스 용어 교체

Red Hat은 코드, 문서, 웹 속성에서 문제가 있는 언어를 교체하기 위해 최선을 다하고 있습니다. 자세한 내용은 다음을 참조하세요.Red Hat 블로그.

Red Hat 소개

Red Hat은 기업이 핵심 데이터 센터에서 네트워크 에지에 이르기까지 플랫폼과 환경 전반에서 더 쉽게 작업할 수 있도록 강화된 솔루션을 제공합니다.

Theme

© 2026 Red Hat
맨 위로 이동