이 페이지에서는 Google Cloud Managed Service for Apache Kafka 브로커에 연결하는 클라이언트 애플리케이션에 지원되는 인증 방법을 설명합니다.
Google Kubernetes Engine, Compute Engine, Cloud Run 또는 Cloud Run 함수와 같은 Google Cloud 서비스에서 실행되는 Apache Kafka용 Google Cloud 관리형 서비스 클라이언트 애플리케이션의 경우 다음 인증 옵션이 있습니다.
SASL/OAUTHBEARER (권장): Google Cloud내 클라이언트에 가장 원활하고 안전한 방법입니다. 애플리케이션 기본 사용자 인증 정보 (ADC)를 사용하여 환경과 연결된 서비스 계정 ID를 자동으로 찾습니다. 이렇게 하면 서비스 계정 키와 같은 정적 사용자 인증 정보 파일을 관리하고 배포할 필요가 없습니다.
SASL/PLAIN: 초기 개발에 유용한 방법입니다. 클라이언트는 장기 서비스 계정 키를 사용하여 인증합니다.
mTLS: 조직의 표준이 인증서 기반 인증인 경우 이 옵션을 선택합니다. Google Cloud의 애플리케이션이 클라이언트 인증서와 키로 구성되어 있습니다.
온프레미스 데이터 센터나 다른 클라우드 제공업체와 같이 Google Cloud외부에서 실행되는 클라이언트 애플리케이션의 경우 다음 인증 방법을 고려하세요. 조직의 보안 상황 및 기존 ID 인프라에 따라 최적의 방법을 선택하세요.
SASL/OAUTHBEARER를 사용한 워크로드 아이덴티티 제휴 (권장): 외부 클라이언트에 가장 안전한 방법입니다. 이를 통해 AWS, Microsoft Azure 또는 ADFS와 같은 온프레미스 ID 공급업체와 같은 외부 시스템의 ID에Google Cloud 서비스 계정을 가장할 수 있는 기능을 부여할 수 있습니다. 클라이언트는 장기 서비스 계정 키를 관리하는 대신 원하는 사용자 인증 정보를 사용하여 단기 Google Cloud 액세스 토큰을 획득합니다. 그런 다음 클라이언트는 이 토큰을 인증에 사용하므로 정적 사용자 인증 정보 파일과 관련된 보안 위험이 크게 줄어듭니다.
mTLS: 이 방법은 공급자에 구애받지 않으며 조직에서 이미 공개 키 인프라 (PKI)를 사용하여 서비스 ID의 TLS 인증서를 관리하는 경우 적합합니다. 클라이언트가 Google Cloud관련 ID 없이 인증할 수 있습니다. 하지만 서비스 계정 키를 사용하는 것과 마찬가지로 이 접근 방식에서는 클라이언트 인증서와 같은 장기 사용자 인증 정보의 수명 주기와 배포를 관리해야 합니다.
서비스 계정 키가 있는 SASL/PLAIN: 이 방법을 사용하면 외부 클라이언트가 Google Cloud ID로 인증하는 직접적인 방법을 제공합니다. 서비스 계정 키 JSON 파일을 다운로드하여 클라이언트의 SASL/PLAIN 구성에서 사용합니다. 이 방법은 클라이언트 측에서 수명이 긴 정적 사용자 인증 정보를 관리하고 보호해야 하므로 일반적으로 프로덕션 워크로드에는 권장되지 않습니다.
SASL과 mTLS 간 기능 비교
Managed Service for Apache Kafka의 기본 인증 메커니즘은Google Cloud의 ID 서비스와 직접 통합되는 SASL(Simple Authentication and Security Layer)입니다. 기준으로 SASL은 서비스 계정과 같은 Google Cloud IAM 주 구성원을 사용하여 클라이언트를 인증합니다. 승인의 경우 SASL은 유연성을 제공합니다. 세분화된 IAM 역할과 Kafka의 액세스 제어 목록 (ACL)을 사용하여 클러스터에 대한 액세스 권한을 관리할 수 있습니다.
반면 mTLS는 Google Cloud IAM을 사용하지 않는 제공업체에 구애받지 않는 인증 방법을 제공합니다. 대신 mTLS는 TLS 인증서를 기반으로 클라이언트를 인증하며, 여기서 ID는 인증서의 주체 이름에서 파생됩니다.
이러한 차이로 인해 승인이 처리되는 방식에 중요한 차이가 발생합니다. SASL 주 구성원과 달리 mTLS 주 구성원은 Kafka ACL을 사용해서만 승인해야 합니다. Google Cloud IAM 역할로 관리할 수 없습니다.
클러스터에 Kafka ACL을 구성하는 것이 좋습니다. ACL이 설정되지 않은 경우 기본 Kafka 동작은 SASL 또는 mTLS를 사용하는지 여부에 관계없이 인증된 모든 주체에게 클러스터에 대한 전체 액세스 권한을 부여합니다. Kafka ACL을 구성하는 방법에 대한 자세한 내용은 Apache Kafka용 관리형 서비스 ACL 만들기를 참고하세요.
Managed Service for Apache Kafka는 CA 서비스에 있는 인증 기관에서 발급한 클라이언트 인증서를 사용한 mTLS 인증을 지원합니다. 조직에서 외부 신뢰 루트를 사용하는 경우 외부 CA에 연결되는 CA 서비스 내에 하위 CA를 만들어 통합할 수 있습니다.
다음 표에서는 인증 방법의 기능을 비교합니다.
| 기능 | SASL/OAUTHBEARER | SASL/PLAIN | mTLS |
|---|---|---|---|
| 기본 ID | Google Cloud IAM 주 구성원 | Google Cloud IAM 주 구성원 | 인증서 주체 이름 |
| 사용자 인증 정보 유형 | 애플리케이션 기본 사용자 인증 정보 (ADC) 또는 OAuth 2.0 토큰 | Base64로 인코딩된 서비스 계정 키 | 클라이언트 인증서 및 비공개 키 |
| 승인 방법 | Google Cloud IAM 역할 또는 Kafka ACL | Google Cloud IAM 역할 또는 Kafka ACL | Kafka ACL만 |
| 사용 사례 | Google Cloud의 클라이언트, 워크로드 아이덴티티 제휴를 사용하는 외부 클라이언트 | 서비스 계정 키 사용이 필요한 간단한 클라이언트, 테스트 시나리오 또는 기존 시스템 | 공급업체에 구애받지 않으며 온프레미스, 멀티 클라우드 또는 기존 PKI 애플리케이션에 적합합니다. |
| 클라이언트 구성 | 특화된 로그인 핸들러 클래스 (Java) 또는 로컬 인증 서버 (비 Java)가 있는 JAAS 구성 | 표준 PlainLoginModule을 사용하는 JAAS 구성 (Java) | 키 저장소 및 트러스트 저장소 속성 (예: security.protocol=SSL) |
| 클러스터 가용성 | 모든 클러스터 | 모든 클러스터 | 2025년 6월 24일 이후에 생성된 클러스터 |
SASL과 mTLS 중 선택
인증 방법은 조직의 보안 정책과 기존 인프라에 따라 선택합니다. 대부분의 사용 사례에서는 Google Cloud IAM과 함께 SASL을 사용하는 것이 좋습니다.
Google Cloud IAM 또는 워크로드 아이덴티티 제휴를 사용하는 SASL은 인증 및 승인을 위한 가장 유연하고 통합된 환경을 제공합니다. 권한 관리를 위한 단일 정보 소스로 Google Cloud의 ID 시스템을 사용합니다. 다음과 같은 경우 이 경로를 선택하세요.
익숙한Google Cloud IAM 역할을 사용하여 Kafka 클라이언트의 권한을 중앙에서 관리합니다.
클라이언트에서 정적 사용자 인증 정보를 관리하지 마세요.
AWS, Azure와 같은 다른 클라우드 또는 Okta, ADFS와 같은 온프레미스 ID 공급업체의 클라이언트가 워크로드 아이덴티티 제휴를 사용하여 인증할 수 있도록 지원합니다. 이 방법을 사용하면 다른 인증 프로토콜로 전환하지 않고도 안전한 클라우드에 구애받지 않는 ID 솔루션을 제공할 수 있습니다.
조직에 인증서 기반 인증에 대한 엄격한 요구사항이 있는 경우 mTLS를 선택합니다. 이러한 요구사항은 이미 ID에 TLS 인증서를 사용하는 기존 온프레미스 Kafka 배포를 이전하는 경우 또는 회사 정책에서 모든 애플리케이션에 클라이언트 인증서를 요구하는 경우에 발생합니다. mTLS는 강력한 전송 수준 보안을 제공하지만 mTLS 클라이언트의 승인은 Google Cloud IAM과 별개인 Kafka ACL로만 관리해야 합니다.
SASL/PLAIN 또는 SASL/OAUTHBEARER 구성 워크플로
Managed Service for Apache Kafka에서 SASL 인증을 사용하도록 클라이언트를 구성하려면 클라이언트의 ID에 권한을 부여한 다음 선택한 SASL 메커니즘을 기반으로 클라이언트 애플리케이션을 구성해야 합니다. 다음은 필요한 워크플로의 개요입니다. SASL 구성 방법에 관한 자세한 내용은 SASL 인증 구성을 참고하세요.
IAM 권한 부여 먼저 클라이언트가 인증에 사용하는 서비스 계정에 관리형 Kafka 클라이언트(
roles/managedkafka.client) 역할을 부여해야 합니다. 이 역할은 프로젝트 내에서 Kafka 클러스터에 연결하는 데 필요한managedkafka.clusters.connect권한을 제공합니다.Kafka 클라이언트를 구성합니다. 특정 클라이언트 구성은 SASL/OAUTHBEARER 메커니즘을 사용하는지 SASL/PLAIN 메커니즘을 사용하는지에 따라 달라집니다.
SASL/OAUTHBEARER (권장): 이 메커니즘은 애플리케이션 기본 사용자 인증 정보 ADC를 사용합니다. 구성 방식은 클라이언트의 언어에 따라 다릅니다.
Java 클라이언트: 특수화된 Google Cloud 인증 라이브러리를 애플리케이션의 클래스 경로에 추가합니다. 그런 다음 ADC를 사용하여 인증을 자동으로 처리하는 제공된
GcpLoginCallbackHandler클래스를 사용하도록 Kafka 클라이언트 속성을 구성합니다.GcpLoginCallbackHandler는 Kafka의 OAUTHBEARER 인증 메커니즘과 함께 사용되는 클래스로, Apache Kafka용 관리형 서비스와 함께 사용하도록 특별히 설계되었습니다. Google의 ID 공급자로부터 JSON 웹 토큰 (JWT)을 획득하는 프로세스를 처리하여 Kafka 클라이언트가 ADC를 사용하여 서비스에 인증할 수 있도록 합니다.Java 이외의 클라이언트: 클라이언트의 머신에서 제공된 로컬 인증 서버를 실행합니다. 이 서버는 ADC를 사용하여 사용자 인증 정보를 가져오고 Kafka 클라이언트에 제공합니다. 그러면 클라이언트가 이 로컬 서버의 엔드포인트에서 인증 토큰을 가져오도록 구성됩니다.
SASL/PLAIN
이 메커니즘은 사용자 이름과 비밀번호 조합을 사용합니다. 클라이언트 애플리케이션은 SASL_SSL 보안 프로토콜, PLAIN 메커니즘,
PlainLoginModule클래스를 지정하는 JAAS 구성을 사용하도록 구성해야 합니다.사용자 이름은 서비스 계정의 이메일 주소입니다. 비밀번호는 다음 두 가지 방법 중 하나로 생성할 수 있습니다.
서비스 계정 키 JSON 파일을 base64로 인코딩합니다.
단기 액세스 토큰을 획득합니다.
승인을 구성합니다. 클라이언트가 SASL을 사용하여 인증에 성공하면 클러스터의 IAM 역할 또는 Kafka ACL에 정의된 권한에 따라 액세스가 제어됩니다.
SASL 제한사항
SASL 인증 방법에는 다음과 같은 제한사항이 있습니다.
SASL 인증은 기본적으로 IAM 주 구성원과 연결되어 있습니다. 워크로드 아이덴티티 제휴를 구성하지 않는 한Google Cloud ID와 엄격한 분리가 필요하거나 Google 이외의 ID를 사용하는 조직에는 적합하지 않습니다.
SASL은 인증에 클라이언트 인증서를 사용하지 않습니다. 기존 PKI를 사용하여 애플리케이션을 식별하는 조직에는 적합하지 않습니다.
mTLS 구성 워크플로
Managed Service for Apache Kafka의 mTLS를 구성하려면 인증 기관, Kafka 클러스터, Kafka 클라이언트를 구성해야 합니다. mTLS 구성 방법에 관한 자세한 내용은 mTLS 인증 구성을 참고하세요.
인증 기관 (CA) 구성 먼저 Certificate Authority Service (CA 서비스)에서 CA 풀을 만들고 구성해야 합니다. 다른 프로젝트에 있는 CA 풀을 만드는 경우 이러한 풀에 액세스할 수 있는 권한을 Apache Kafka용 관리형 서비스 서비스 에이전트(
service-PROJECT_NUMBER@gcp-sa-managedkafka.iam.gserviceaccount.com)에 부여해야 합니다. CA 풀 내에서 루트 및 하위 인증서를 만들어야 합니다.Kafka 클러스터를 구성합니다. 구성된 CA 풀의 리소스 식별자를 제공하여 mTLS를 사용 설정하도록 클러스터를 만들거나 업데이트합니다. 또한 ACL에 사용할 간소화된 주 구성원 이름을 만들도록
ssl.principal.mapping.rules브로커 속성을 구성하는 것이 좋습니다. Google Cloud CLI 명령어를 사용하여 이 작업을 수행할 수 있습니다.Kafka 클라이언트를 구성합니다. CA에서 클라이언트 인증서를 가져와 클라이언트 환경(예: Java 키 저장소)에 설치합니다. 그런 다음 클라이언트 애플리케이션이 올바른 보안 프로토콜 (SSL)과 키 저장소 위치로 구성되어 클러스터의 전용 mTLS 부트스트랩 포트인
9192에 연결되어야 합니다.mTLS 모니터링 설정 후
managedkafka.googleapis.com/mtls_truststore_update_count측정항목을 모니터링하여 클러스터가 CA 서비스 풀에서 CA 인증서를 성공적으로 새로고침하는지 확인합니다. 클러스터는 주기적으로 이를 시도합니다. Cloud Logging을 사용할 수도 있습니다.
mTLS 제한사항
mTLS 기능에는 다음과 같은 제한사항이 있습니다.
2025년 6월 24일 이후에 생성된 Apache Kafka용 관리형 서비스 클러스터에서만 mTLS 기능을 사용할 수 있습니다.
Kafka ACL을 사용하여 mTLS 보안 주체의 승인을 구성해야 합니다. IAM 역할 바인딩을 사용하여 mTLS 클라이언트를 승인할 수 없습니다.
서비스는 CA 서비스에서 관리하는 인증서를 제시하는 클라이언트만 인증합니다. 하지만 외부 CA에 연결되는 CA Service 내에 하위 CA를 만들어 외부 신뢰 루트를 통합할 수 있습니다.
최대 10개의 CA 풀을 신뢰하도록 클러스터를 구성할 수 있습니다.