SSL을 이용한 암호화와 인증

SSL을 이용한 암호화와 인증 (Encryption and Authentication using SSL)

이 페이지는 Kafka에서 SSL/TLS로 클라이언트와 브로커 사이의 트래픽을 암호화하고 상호 인증(mTLS)을 수행하는 방법을 차근차근 설명해요. 브로커별 키·인증서 생성, 직접 CA 만들기, 서명, 브로커·클라이언트 설정까지 실제 keytool/openssl 명령을 그대로 따라가면 됩니다.

출처: 문서

본문

Apache Kafka는 클라이언트가 트래픽 암호화와 인증 모두에 SSL을 사용할 수 있게 해줍니다. 기본적으로 SSL은 비활성화되어 있지만 필요하면 켤 수 있습니다. 아래 문단들은 여러분만의 PKI 인프라를 구축하고, 이를 사용해 인증서를 만들고, Kafka가 이것들을 사용하도록 구성하는 방법을 자세히 설명합니다.

각 Kafka 브로커에 대한 SSL 키와 인증서 생성 (Generate SSL key and certificate for each Kafka broker)

SSL 지원으로 하나 이상의 브로커를 배포하는 첫 단계는 모든 서버에 대한 공개/개인 키 쌍을 생성하는 것입니다. Kafka는 모든 키와 인증서가 키스토어(keystore)에 저장되기를 기대하므로, 이 작업에는 Java의 keytool 명령을 사용할 것입니다. 이 도구는 두 가지 키스토어 형식을 지원합니다. Java 특유의, 지금은 폐기된 jks 형식과 PKCS12입니다. PKCS12는 Java 9부터 기본 형식이며, 사용 중인 Java 버전과 무관하게 이 형식이 사용되도록 모든 이후 명령은 명시적으로 PKCS12 형식을 지정합니다.

$ keytool -keystore {keystorefile} -alias localhost -validity {validity} -genkey -keyalg RSA -storetype pkcs12

위 명령에서 두 파라미터를 지정해야 합니다.

  • keystorefile: 이 브로커의 키(그리고 나중에는 인증서)를 저장하는 키스토어 파일. 키스토어 파일에는 이 브로커의 개인 키와 공개 키가 들어 있으므로 안전하게 보관해야 합니다. 이상적으로 이 단계는 키가 사용될 Kafka 브로커에서 실행해야 합니다. 이 키는 의도된 서버를 절대 떠나면 안 되기 때문입니다.
  • validity: 키의 유효 시간(일). 이는 "인증서 서명"에서 결정되는 인증서의 유효 기간과 다릅니다. 같은 키로 여러 인증서를 요청할 수 있습니다. 키 유효 기간이 10년이고 CA가 1년짜리 인증서만 서명한다면, 시간이 지나며 같은 키로 10개의 인증서를 사용할 수 있습니다.

방금 만든 개인 키와 함께 사용할 수 있는 인증서를 얻으려면 인증서 서명 요청(CSR)을 만들어야 합니다. 이 서명 요청은 신뢰할 수 있는 CA가 서명하면 실제 인증서가 되어 키스토어에 설치되고 인증 목적으로 사용됩니다. 지금까지 만든 모든 서버 키스토어에 대해 다음 명령으로 인증서 서명 요청을 생성하세요.

$ keytool -keystore server.keystore.jks -alias localhost -validity {validity} -genkey -keyalg RSA -destkeystoretype pkcs12 -ext SAN=DNS:{FQDN},IP:{IPADDRESS1}

이 명령은 인증서에 호스트 이름 정보를 추가하려는 경우를 가정합니다. 그렇지 않다면 확장 파라미터 -ext SAN=DNS:{FQDN},IP:{IPADDRESS1}를 생략할 수 있습니다.

호스트 이름 검증 (Host Name Verification)

호스트 이름 검증은 활성화되면, 연결하는 서버가 제시하는 인증서의 속성을 그 서버의 실제 호스트 이름이나 IP 주소와 비교해 정말 올바른 서버에 연결하고 있는지 확인하는 과정입니다. 이 검사의 주된 이유는 중간자 공격(man-in-the-middle)을 막기 위해서입니다. Kafka에서 이 검사는 오랫동안 기본적으로 비활성화되어 있었지만, Kafka 2.0.0부터 서버의 호스트 이름 검증이 클라이언트 연결과 브로커 간 연결 모두에서 기본적으로 활성화됩니다. 서버 호스트 이름 검증은 ssl.endpoint.identification.algorithm을 빈 문자열로 설정하면 비활성화할 수 있습니다. 동적으로 구성된 브로커 리스너의 경우 kafka-configs.sh로 호스트 이름 검증을 비활성화할 수 있습니다.

$ bin/kafka-configs.sh --bootstrap-server localhost:9093 --entity-type brokers --entity-name 0 --alter --add-config "listener.name.internal.ssl.endpoint.identification.algorithm="

참고: 보통 호스트 이름 검증을 끌 만한 합당한 이유는 없습니다. "일단 동작하게 하려고" 끄고 "나중에 시간 있을 때 고치겠다"는 약속을 남기는 것 외에는요! 호스트 이름 검증을 제대로 설정하는 것은 적절한 시기에 할 때 그리 어렵지 않지만, 클러스터가 가동된 후에는 훨씬 어려워집니다. 지금 하세요.

호스트 이름 검증이 활성화되면 클라이언트는 다음 두 필드 중 하나에 대해 서버의 정규화된 도메인 이름(FQDN) 또는 IP 주소를 검증합니다.

  • Common Name (CN)
  • Subject Alternative Name (SAN)

Kafka는 두 필드를 모두 확인하지만, 호스트 이름 검증에 CN 필드를 사용하는 것은 2000년부터 폐기되어 가능하면 피해야 합니다. 게다가 SAN 필드는 훨씬 유연해서 인증서에 여러 DNS·IP 항목을 선언할 수 있습니다. 또 다른 장점은 호스트 이름 검증에 SAN 필드를 사용하면 CN을 인가 목적에 더 의미 있는 값으로 설정할 수 있다는 것입니다. SAN 필드는 서명된 인증서에 포함되어야 하므로 서명 요청 생성 시 지정합니다. 키 쌍 생성 시에도 지정할 수 있지만, 서명 요청에 자동으로 복사되지는 않습니다. SAN 필드를 추가하려면 keytool 명령에 -ext SAN=DNS:{FQDN},IP:{IPADDRESS} 인자를 덧붙이세요.

$ keytool -keystore server.keystore.jks -alias localhost -validity {validity} -genkey -keyalg RSA -destkeystoretype pkcs12 -ext SAN=DNS:{FQDN},IP:{IPADDRESS1}

직접 CA 만들기 (Creating your own CA)

이 단계 후 클러스터의 각 머신은 이미 트래픽 암호화에 사용할 수 있는 공개/개인 키 쌍과, 인증서 생성의 기초인 인증서 서명 요청을 갖게 됩니다. 인증 기능을 추가하려면 이 서명 요청을 신뢰할 수 있는 기관이 서명해야 하며, 이 기관이 이 단계에서 만들어집니다.

인증 기관(CA)은 인증서를 서명하는 책임을 집니다. CA는 여권을 발급하는 정부처럼 작동합니다. 정부가 각 여권에 도장(서명)을 찍어 위조하기 어렵게 만들고, 다른 정부가 도장을 검증해 여권이 진짜인지 확인합니다. 마찬가지로 CA가 인증서를 서명하고, 암호화는 서명된 인증서가 계산적으로 위조하기 어렵다는 것을 보장합니다. 따라서 CA가 진짜이자 신뢰할 수 있는 기관인 한, 클라이언트는 진짜 머신에 연결하고 있다는 강력한 확신을 갖습니다.

이 가이드에서는 우리 자신이 인증 기관이 됩니다. 회사 환경에서 프로덕션 클러스터를 설정할 때는 보통 회사 전체가 신뢰하는 사내 CA가 이런 인증서들을 서명합니다. 이 경우 고려할 사항은 "프로덕션의 흔한 함정"을 참고하세요.

OpenSSL의 버그 때문에 x509 모듈은 요청된 확장 필드를 CSR에서 최종 인증서로 복사하지 않습니다. 호스트 이름 검증을 위해 인증서에 SAN 확장이 있기를 원하므로, 대신 ca 모듈을 사용하겠습니다. 이는 CA 키 쌍을 생성하기 전에 추가 구성이 마련되어야 함을 의미합니다. 다음 내용을 openssl-ca.cnf라는 파일로 저장하고 validity와 공통 속성 값을 필요에 따라 조정하세요.

     HOME            = .
     RANDFILE        = $ENV::HOME/.rnd

     ####################################################################
     [ ca ]
     default_ca    = CA_default      # The default ca section

     [ CA_default ]

     base_dir      = .
     certificate   = $base_dir/cacert.pem   # The CA certificate
     private_key   = $base_dir/cakey.pem    # The CA private key
     new_certs_dir = $base_dir              # Location for new certs after signing
     database      = $base_dir/index.txt    # Database index file
     serial        = $base_dir/serial.txt   # The current serial number

     default_days     = 1000         # How long to certify for
     default_crl_days = 30           # How long before next CRL
     default_md       = sha256       # Use public key default MD
     preserve         = no           # Keep passed DN ordering

     x509_extensions = ca_extensions # The extensions to add to the cert

     email_in_dn     = no            # Don't concat the email in the DN
     copy_extensions = copy          # Required to copy SANs from CSR to cert

     ####################################################################
     [ req ]
     default_bits       = 4096
     default_keyfile    = cakey.pem
     distinguished_name = ca_distinguished_name
     x509_extensions    = ca_extensions
     string_mask        = utf8only

     ####################################################################
     [ ca_distinguished_name ]
     countryName         = Country Name (2 letter code)
     countryName_default = DE

     stateOrProvinceName         = State or Province Name (full name)
     stateOrProvinceName_default = Test Province

     localityName                = Locality Name (eg, city)
     localityName_default        = Test Town

     organizationName            = Organization Name (eg, company)
     organizationName_default    = Test Company

     organizationalUnitName         = Organizational Unit (eg, division)
     organizationalUnitName_default = Test Unit

     commonName         = Common Name (e.g. server FQDN or YOUR name)
     commonName_default = Test Name

     emailAddress         = Email Address
     emailAddress_default = [email protected]

     ####################################################################
     [ ca_extensions ]

     subjectKeyIdentifier   = hash
     authorityKeyIdentifier = keyid:always, issuer
     basicConstraints       = critical, CA:true
     keyUsage               = keyCertSign, cRLSign

     ####################################################################
     [ signing_policy ]
     countryName            = optional
     stateOrProvinceName    = optional
     localityName           = optional
     organizationName       = optional
     organizationalUnitName = optional
     commonName             = supplied
     emailAddress           = optional

     ####################################################################
     [ signing_req ]
     subjectKeyIdentifier   = hash
     authorityKeyIdentifier = keyid,issuer
     basicConstraints       = CA:FALSE
     keyUsage               = digitalSignature, keyEncipherment

그 다음 이 CA로 어떤 인증서가 서명되었는지 추적하는 데 사용할 데이터베이스와 일련번호 파일을 만듭니다. 둘 다 CA 키와 같은 디렉터리에 있는 단순 텍스트 파일입니다.

     $ echo 01 > serial.txt
     $ touch index.txt

이 단계들을 마치면 나중에 인증서를 서명하는 데 사용할 CA를 생성할 준비가 된 것입니다.

     $ openssl req -x509 -config openssl-ca.cnf -newkey rsa:4096 -sha256 -nodes -out cacert.pem -outform PEM

CA는 단순히 자기 자신이 서명한 공개/개인 키 쌍과 인증서이며, 다른 인증서를 서명하기 위한 용도로만 사용됩니다. 이 키 쌍은 매우 안전하게 보관해야 합니다. 누군가 접근하면 여러분의 인프라가 신뢰하는 인증서를 만들고 서명할 수 있으므로, 이 CA를 신뢰하는 어떤 서비스에 연결할 때도 누구든 사칭할 수 있게 됩니다. 다음 단계는 생성된 CA를 클라이언트의 트러스트스토어에 추가해 클라이언트가 이 CA를 신뢰하게 하는 것입니다.

     $ keytool -keystore client.truststore.jks -alias CARoot -import -file ca-cert

참고: Kafka 브로커 구성에서 ssl.client.auth를 "requested" 또는 "required"로 설정해 클라이언트 인증을 요구하도록 구성한다면, Kafka 브로커에도 트러스트스토어를 제공해야 하며 클라이언트 키를 서명한 모든 CA 인증서가 있어야 합니다.

     $ keytool -keystore server.truststore.jks -alias CARoot -import -file ca-cert

1단계의 키스토어가 각 머신의 자신의 신원을 저장하는 것과 달리, 클라이언트의 트러스트스토어는 클라이언트가 신뢰해야 하는 모든 인증서를 저장합니다. 트러스트스토어에 인증서를 가져오는 것은 그 인증서가 서명한 모든 인증서도 신뢰한다는 뜻입니다. 위 비유처럼 정부(CA)를 신뢰하는 것은 그것이 발급한 모든 여권(인증서)도 신뢰한다는 의미입니다. 이 속성을 신뢰 체인(chain of trust)이라고 하며, 대규모 Kafka 클러스터에 SSL을 배포할 때 특히 유용합니다. 클러스터의 모든 인증서를 단일 CA로 서명하고, 모든 머신이 CA를 신뢰하는 같은 트러스트스토어를 공유할 수 있습니다. 그러면 모든 머신이 다른 모든 머신을 인증할 수 있습니다.

인증서 서명 (Signing the certificate)

그런 다음 CA로 서명합니다.

     $ openssl ca -config openssl-ca.cnf -policy signing_policy -extensions signing_req -out {server certificate} -infiles {certificate signing request}

마지막으로 CA의 인증서와 서명된 인증서를 모두 키스토어로 가져와야 합니다.

     $ keytool -keystore {keystore} -alias CARoot -import -file {CA certificate}
     $ keytool -keystore {keystore} -alias localhost -import -file cert-signed

파라미터의 정의는 다음과 같습니다.

  • keystore: 키스토어의 위치.
  • CA certificate: CA의 인증서.
  • certificate signing request: 서버 키로 만들어진 csr.
  • server certificate: 서버의 서명된 인증서를 쓸 파일.

이 과정을 마치면 truststore.jks라는 트러스트스토어 하나가 생깁니다. 이 트러스트스토어는 모든 클라이언트와 브로커에 동일할 수 있으며 민감한 정보를 담고 있지 않으므로 보안을 강화할 필요가 없습니다. 또한 노드마다 해당 노드의 키, 인증서, CA 인증서를 담은 server.keystore.jks 파일이 하나씩 생깁니다. 이 파일들을 사용하는 방법은 Kafka 브로커 구성과 Kafka 클라이언트 구성을 참고하세요. 이 주제에 대한 도구 지원은 extensive한 스크립트를 제공하는 easyRSA 프로젝트를 확인하세요.

PEM 형식의 SSL 키와 인증서 (SSL key and certificates in PEM format)

2.7.0부터 SSL 키·트러스트 스토어는 Kafka 브로커와 클라이언트에서 구성에 직접 PEM 형식으로 설정할 수 있습니다. 이는 파일시스템에 별도 파일을 저장할 필요를 없애고 Kafka 구성의 비밀번호 보호 기능을 활용합니다. PEM은 JKS와 PKCS12 외에도 파일 기반 키·트러스트 스토어의 스토어 타입으로도 사용할 수 있습니다. 브로커나 클라이언트 구성에 직접 PEM 키 스토어를 구성하려면 ssl.keystore.key에 PEM 형식의 개인 키를, ssl.keystore.certificate.chain에 PEM 형식의 인증서 체인을 제공해야 합니다. 트러스트 스토어를 구성하려면 ssl.truststore.certificates에 신뢰 인증서(예: CA의 공개 인증서)를 제공해야 합니다. PEM은 보통 여러 줄의 base-64 문자열로 저장되므로, 구성 값은 줄 연속을 위해 백슬래시로 끝나는 여러 줄 문자열로 Kafka 구성에 포함될 수 있습니다.

스토어 비밀번호 구성 ssl.keystore.password와 ssl.truststore.password는 PEM에는 사용되지 않습니다. 개인 키가 비밀번호로 암호화되어 있다면 ssl.key.password에 키 비밀번호를 제공해야 합니다. 개인 키는 비밀번호 없이 암호화되지 않은 형태로 제공될 수 있습니다. 프로덕션 배포에서는 이 경우 Kafka의 비밀번호 보호 기능으로 구성을 암호화하거나 외부화해야 합니다. 참고로 기본 SSL 엔진 팩토리는 OpenSSL 같은 외부 도구로 암호화된 개인 키의 복호화 능력이 제한적입니다. BouncyCastle 같은 타사 라이브러리를 커스텀 SslEngineFactory와 통합해 더 넓은 범위의 암호화된 개인 키를 지원할 수 있습니다.

프로덕션에서의 흔한 함정 (Common Pitfalls in Production)

위 문단들은 직접 CA를 만들고 그 CA로 클러스터의 인증서를 서명하는 과정을 보여줍니다. 샌드박스, 개발, 테스트 등에는 매우 유용하지만, 회사 환경의 프로덕션 클러스터에 인증서를 만들기에는 보통 올바른 과정이 아닙니다. 기업은 보통 자체 CA를 운영하며 사용자는 이 CA로 서명할 CSR을 보낼 수 있습니다. 이는 사용자가 CA를 안전하게 유지할 책임을 지지 않고, 모두가 신뢰하는 중앙 기관이 있다는 이점이 있습니다. 하지만 CA 서명 과정에 대한 사용자의 제어를 많이 빼앗기도 합니다. 사내 CA 운영자가 인증서에 엄격한 제한을 두어 Kafka에서 사용하려 할 때 문제가 되기도 합니다.

  • 확장 키 사용(Extended Key Usage): 인증서에는 인증서가 사용될 목적을 제어하는 확장 필드가 포함될 수 있습니다. 이 필드가 비어 있으면 사용 제한이 없지만, 어떤 용도라도 지정되면 유효한 SSL 구현이 이를 강제해야 합니다. Kafka에 관련된 용도는 다음과 같습니다.

    • 클라이언트 인증(Client authentication)
    • 서버 인증(Server authentication)

    Kafka 브로커는 이 두 용도가 모두 허용되어야 합니다. 클러스터 내 통신에서 각 브로커가 다른 브로커에게 클라이언트이자 서버로 동작하기 때문입니다. 사내 CA가 웹서버용 서명 프로필을 Kafka에도 사용하는 일이 흔한데, 이 프로필은 serverAuth 사용 값만 담고 있어 SSL 핸드셰이크가 실패합니다.

  • 중간 인증서(Intermediate Certificates): 사내 루트 CA는 보안상 이유로 자주 오프라인 상태로 유지됩니다. 일상적인 사용을 위해 소위 중간 CA가 만들어져 최종 인증서를 서명합니다. 중간 CA가 서명한 인증서를 키스토어로 가져올 때 루트 CA까지의 전체 신뢰 체인을 제공해야 합니다. 이는 간단히 인증서 파일들을 하나로 결합한 후 keytool로 가져오면 됩니다.

     $ openssl x509 -in certificate.crt -text -noout
  • 확장 필드 복사 실패: CA 운영자들은 종종 CSR의 요청된 확장 필드를 복사하기를 꺼리고, 악의적인 당사자가 잘못되거나 사기성 값을 가진 인증서를 얻기 어렵게 하기 위해 스스로 지정하는 것을 선호합니다. 서명된 인증서에 적절한 호스트 이름 검증을 위한 모든 요청된 SAN 필드가 포함되었는지 이중 확인하는 것이 좋습니다. 위 명령을 사용해 인증서 세부 정보를 콘솔에 출력해 원래 요청한 것과 비교할 수 있습니다.

Kafka 브로커 구성 (Configuring Kafka Brokers)

브로커 간 통신에 SSL이 활성화되지 않았다면(아래에서 활성화 방법 참고) PLAINTEXT와 SSL 포트가 모두 필요할 것입니다.

     listeners=PLAINTEXT://host.name:port,SSL://host.name:port

브로커 측에 필요한 SSL 구성은 다음과 같습니다.

     ssl.keystore.location=/var/private/ssl/server.keystore.jks
     ssl.keystore.password=test1234
     ssl.key.password=test1234
     ssl.truststore.location=/var/private/ssl/server.truststore.jks
     ssl.truststore.password=test1234

참고: ssl.truststore.password는 기술적으로 선택 사항이지만 매우 권장됩니다. 비밀번호를 설정하지 않아도 트러스트스토어에 접근할 수 있지만, 무결성 검사가 비활성화됩니다. 고려할 만한 선택 설정입니다.

  • ssl.client.auth=none ("required"=>클라이언트 인증 필수, "requested"=>클라이언트 인증이 요청되며 인증서가 없는 클라이언트도 연결 가능. "requested"는 잘못된 보안 감각을 주고 잘못 구성된 클라이언트도 여전히 연결에 성공하므로 권장되지 않음.)
  • ssl.cipher.suites(선택). 암호 스위트는 TLS 또는 SSL 네트워크 프로토콜을 사용하는 네트워크 연결의 보안 설정을 협상하는 데 사용되는 인증·암호화·MAC·키 교환 알고리즘의 명명된 조합. (기본값은 빈 목록)
  • ssl.enabled.protocols=TLSv1.2,TLSv1.1,TLSv1(클라이언트에서 받아들일 SSL 프로토콜 나열. SSL은 TLS를 선호해 폐기되었으며 프로덕션에 SSL을 쓰는 것은 권장되지 않음)
  • ssl.keystore.type=JKS
  • ssl.truststore.type=JKS
  • ssl.secure.random.implementation=SHA1PRNG

브로커 간 통신에 SSL을 활성화하려면 server.properties에 다음을 추가합니다(기본값은 PLAINTEXT). security.inter.broker.protocol=SSL

일부 국가의 수입 규정 때문에 Oracle 구현은 기본적으로 사용 가능한 암호화 알고리즘의 강도를 제한합니다. 더 강한 알고리즘(예: 256비트 키의 AES)이 필요하다면 JCE Unlimited Strength Jurisdiction Policy Files를 구해 JDK/JRE에 설치해야 합니다. 자세한 내용은 JCA Providers Documentation을 참고하세요.

JRE/JDK에는 암호화 연산에 사용되는 기본 의사 난수 생성기(PRNG)가 있으므로 ssl.secure.random.implementation과 함께 사용되는 구현을 구성할 필요는 없습니다. 하지만 일부 구현에는 성능 문제가 있습니다(특히 Linux 시스템의 기본값인 NativePRNG는 전역 잠금을 사용합니다). SSL 연결 성능이 문제가 되는 경우 사용할 구현을 명시적으로 설정하는 것을 고려하세요. SHA1PRNG 구현은 비차단이며, 과부하 상태에서 매우 좋은 성능 특성을 보였습니다(브로커당 생산 메시지 50 MB/초에 복제 트래픽 포함).

브로커를 시작하면 server.log에서 다음을 볼 수 있어야 합니다.

with addresses: PLAINTEXT -> EndPoint(192.168.64.1,9092,PLAINTEXT),SSL -> EndPoint(192.168.64.1,9093,SSL)

서버 키스토어와 트러스트스토어가 제대로 설정되었는지 빠르게 확인하려면 다음 명령을 실행할 수 있습니다.

$ openssl s_client -debug -connect localhost:9093 -tls1

(참고: TLSv1은 ssl.enabled.protocols 아래에 나열되어야 합니다.) 이 명령의 출력에서 서버의 인증서를 볼 수 있어야 합니다.

-----BEGIN CERTIFICATE-----
{variable sized random bytes}
-----END CERTIFICATE-----
subject=/C=US/ST=CA/L=Santa Clara/O=org/OU=org/CN=Sriharsha Chintalapani
issuer=/C=US/ST=CA/L=Santa Clara/O=org/OU=org/CN=kafka/[email protected]

인증서가 표시되지 않거나 다른 오류 메시지가 있다면 키스토어가 제대로 설정되지 않은 것입니다.

Kafka 클라이언트 구성 (Configuring Kafka Clients)

SSL은 새 Kafka Producer와 Consumer에서만 지원되며, 이전 API는 지원되지 않습니다. SSL 구성은 프로듀서와 컨슈머에 동일합니다. 브로커에서 클라이언트 인증이 요구되지 않는다면 다음이 최소 구성 예제입니다.

     security.protocol=SSL
     ssl.truststore.location=/var/private/ssl/client.truststore.jks
     ssl.truststore.password=test1234

참고: ssl.truststore.password는 기술적으로 선택 사항이지만 매우 권장됩니다. 비밀번호를 설정하지 않아도 트러스트스토어에 접근할 수 있지만, 무결성 검사가 비활성화됩니다. 클라이언트 인증이 요구된다면 키스토어를 만들고 다음도 구성해야 합니다.

     ssl.keystore.location=/var/private/ssl/client.keystore.jks
     ssl.keystore.password=test1234
     ssl.key.password=test1234

요구 사항과 브로커 구성에 따라 필요할 수 있는 다른 구성 설정입니다.

  • ssl.provider(선택). SSL 연결에 사용되는 보안 제공자의 이름. 기본값은 JVM의 기본 보안 제공자.
  • ssl.cipher.suites(선택). TLS 또는 SSL 네트워크 프로토콜을 사용하는 네트워크 연결의 보안 설정을 협상하는 데 사용되는 인증·암호화·MAC·키 교환 알고리즘의 명명된 조합.
  • ssl.enabled.protocols=TLSv1.2,TLSv1.1,TLSv1. 브로커 측에 구성된 프로토콜 중 적어도 하나를 나열해야 함.
  • ssl.truststore.type=JKS
  • ssl.keystore.type=JKS

console-producer와 console-consumer를 사용하는 예:

$ bin/kafka-console-producer.sh --bootstrap-server localhost:9093 --topic test --command-config client-ssl.properties
$ bin/kafka-console-consumer.sh --bootstrap-server localhost:9093 --topic test --command-config client-ssl.properties

더 알아보기 (Learn more)

  • 호스트 이름 검증은 기본 활성화이며, SAN 필드를 쓰는 것이 좋아요.
  • 프로덕션에서는 직접 만든 CA보다 사내 CA 서명 인증서가 일반적이에요.
  • 클라이언트 인증을 원하면 브로커와 클라이언트 모두 트러스트스토어가 필요해요.
  • SASL 기반 인증은 SASL을 이용한 인증 문서를 참고하세요.