mTLS 인증 구성

상호 TLS (mTLS)를 사용하여 Kafka 클라이언트를 인증하도록 Apache Kafka용 관리형 서비스 클러스터를 구성할 수 있습니다. 이 방법은 인증의 기준으로 Certificate Authority Service (CA 서비스)의 클라이언트 인증서를 사용합니다. 이 옵션은 Identity and Access Management(IAM) 보안 주체를 사용하는 기본 SASL 메커니즘의 대안을 제공합니다.

mTLS를 사용하는 경우 Kafka ACL을 사용하여 승인을 구성해야 합니다. 기본 개념은 다음 문서를 참고하세요.

시작하기 전에

mTLS 인증을 구성하기 전에 다음을 완료하세요.

클러스터 자격 요건을 확인합니다. 2025년 6월 24일 이후에 생성된 기존 Apache Kafka용 관리형 서비스 클러스터가 있는지 확인합니다. 이러한 클러스터만 mTLS 인증을 지원합니다. 클러스터 생성 날짜를 확인하려면 gcloud managed-kafka clusters describe 명령어를 사용하거나 콘솔에서 클러스터 세부정보 페이지를 확인하세요.
CA 서비스 구성 클라이언트 인증서를 발급하는 데 사용할 CA 서비스 및 CA 풀을 설정합니다. CA 풀 내에서 루트 및 하위 인증서를 만들어야 합니다.
1. CA 풀을 만듭니다. CA 풀 ID를 기록해 둡니다.
  
  CA 풀을 만드는 방법에 대한 자세한 내용은 CA 풀 만들기를 참고하세요.
2. 풀의 루트 CA를 만들고 사용 설정합니다.
  
  풀의 루트 CA를 사용 설정하는 방법에 대한 자세한 내용은 루트 CA 만들기를 참고하세요.
3. 하나 이상의 하위 CA를 만들고 사용 설정합니다. 루트 CA를 직접 사용하는 대신 하위 CA를 사용하여 클라이언트 인증서를 발급하는 것이 좋습니다.
  
  하위 CA를 만드는 방법에 대한 자세한 내용은 하위 인증 기관 만들기를 참고하세요.

필수 역할 및 권한

mTLS를 구성하려면 사용자 및 Apache Kafka용 관리형 서비스 서비스 에이전트 모두에 필요한 IAM 권한이 있어야 합니다. 이는 mTLS를 구성하기 위해 새 클러스터를 만드는지 아니면 기존 클러스터를 업데이트하는지에 따라 적용됩니다.

사용자 권한

mTLS용 Apache Kafka용 관리형 서비스 클러스터를 만들거나 구성하려면 클러스터 리소스를 만들거나 업데이트할 수 있는 권한이 필요합니다. 이렇게 하려면 관리자에게 클러스터가 포함된 프로젝트에 대한 관리형 Kafka 클러스터 편집자 (roles/managedkafka.clusterEditor) 역할을 부여해 달라고 요청하세요.

이 사전 정의된 역할에는 managedkafka.clusters.create 및 managedkafka.clusters.update 권한이 포함되어 있습니다. 이러한 권한을 사용하면 새 클러스터를 만들거나 기존 클러스터를 수정하여 mTLS에 필요한 CA 서비스 (CA) 풀 구성을 추가할 수 있습니다.

CA 풀의 전체 리소스 경로가 있는 경우 Kafka 클러스터에서 mTLS를 구성하기 위해 CA 서비스 리소스에 대한 별도의 권한이 필요하지 않습니다. 하지만Google Cloud 콘솔에서 CA 풀을 보거나 만들거나 관리하려면 CA 서비스 관리자 (roles/privateca.admin) 또는 CA 서비스 운영자 (roles/privateca.operator)와 같은 CA 서비스 전용 추가 역할이 필요합니다.

서비스 에이전트 권한

mTLS 통합이 작동하려면 Apache Kafka용 관리형 서비스 서비스 에이전트가 지정된 CA 풀에 액세스할 권한이 필요합니다. 서비스 에이전트는 프로젝트의 Google 관리 서비스 계정입니다.

Apache Kafka용 관리형 서비스 클러스터와 CA 풀이 동일한 프로젝트에 있는 경우 서비스 에이전트에는 기본적으로 필요한 권한이 있습니다. 프로젝트의 서비스 에이전트에게 자동으로 부여되는 managedkafka.serviceAgent 역할에는 필수 privateca.caPools.get 권한이 포함되어 있습니다.
CA 풀이 Apache Kafka용 관리형 서비스 클러스터와 다른 프로젝트에 있는 경우 서비스 에이전트가 CA 풀에 액세스할 수 있도록 권한을 수동으로 부여해야 합니다. CA 풀이 포함된 프로젝트에서 서비스 에이전트에게 비공개 CA 풀 리더 (roles/privateca.poolReader) 역할을 부여합니다.

필수 권한 요약

필요한 권한을 정확하게 확인하려면 다음 섹션을 펼치세요.

필수 권한

사용자 권한:

managedkafka.clusters.create: mTLS용으로 구성된 새 Kafka 클러스터를 만드는 데 필요합니다.
managedkafka.clusters.update: 기존 Kafka 클러스터를 업데이트하여 mTLS를 구성하는 데 필요합니다.

Apache Kafka용 관리형 서비스 서비스 에이전트 권한:

privateca.caPools.get: 서비스 에이전트가 CA 풀에 액세스하는 데 필요합니다. 이는 roles/privateca.poolReader 역할에 포함됩니다.

커스텀 역할이나 다른 사전 정의된 역할을 사용하여 이 권한을 부여받을 수도 있습니다.

서비스 에이전트에 CA 풀에 대한 액세스 권한 부여

CA 서비스 CA 풀과 Apache Kafka용 관리형 서비스 클러스터가 서로 다른 Google Cloud 프로젝트에 있는 경우 클러스터의 서비스 에이전트가 CA 풀에 액세스할 수 있는 권한을 부여해야 합니다. Apache Kafka용 관리형 서비스 서비스 에이전트의 이름은 service-CLUSTER_PROJECT_NUMBER@gcp-sa-managedkafka.iam.gserviceaccount.com입니다.

CA가 포함된 개별 풀 수준 (권장) 또는 프로젝트의 모든 풀에서 Managed Service for Apache Kafka 서비스 에이전트에 CA 풀 리더(roles/privateca.poolReader) 역할을 부여합니다. 이 역할은 필요한 privateca.caPools.get 권한을 제공합니다.

개별 CA 풀

단일 CA 풀에 권한을 부여하는 것이 최소 권한의 원칙을 따르므로 권장되는 방법입니다.

gcloud privateca pools add-iam-policy-binding 명령어를 실행합니다.

gcloud privateca pools add-iam-policy-binding CA_POOL_ID \
    --location=CA_POOL_LOCATION \
    --member='serviceAccount:service-CLUSTER_PROJECT_NUMBER@gcp-sa-managedkafka.iam.gserviceaccount.com' \
    --role='roles/privateca.poolReader'

다음을 바꿉니다.

CA_POOL_ID: 액세스 권한을 부여할 CA 풀의 ID입니다. 예를 들면 test-mtls-pool1입니다.
CA_POOL_LOCATION: CA 풀이 있는 Google Cloud 리전입니다. 예를 들면 us-central1입니다.
CLUSTER_PROJECT_NUMBER: Apache Kafka용 관리형 서비스 클러스터가 포함된 프로젝트의 프로젝트 번호입니다. 예를 들면 12341234123입니다.

모든 CA 풀

또는 프로젝트 수준에서 정책을 설정하여 서비스 에이전트가 프로젝트 내의 모든 CA 풀에 액세스할 수 있는 권한을 부여할 수 있습니다.

gcloud projects add-iam-policy-binding 명령어를 실행합니다.

gcloud projects add-iam-policy-binding CA_PROJECT_ID \
    --member='serviceAccount:service-CLUSTER_PROJECT_NUMBER@gcp-sa-managedkafka.iam.gserviceaccount.com' \
    --role='roles/privateca.poolReader'

다음을 바꿉니다.

CA_PROJECT_ID: 액세스 권한을 부여할 CA 풀이 포함된 프로젝트의 ID입니다. 예를 들면 test-cas-project입니다.
CLUSTER_PROJECT_NUMBER: Apache Kafka용 관리형 서비스 클러스터가 포함된 프로젝트의 프로젝트 번호입니다. 예를 들면 12341234123입니다.

클러스터에서 mTLS 사용 설정

mTLS를 사용 설정하려면 클라이언트 인증에 사용할 CA Service CA 풀의 리소스 이름을 클러스터에 제공합니다. 새 클러스터를 만들거나 2025년 6월 24일 이후에 생성된 기존 클러스터를 업데이트할 때 이 작업을 실행할 수 있습니다.

CA 풀 식별자를 제공하면 서비스가 지정된 풀에서 CA 인증서를 자동으로 다운로드하여 클러스터의 각 브로커의 신뢰 저장소에 설치합니다.

콘솔

생성 중에 새 클러스터에서 또는 기존 클러스터를 수정하여 mTLS를 사용 설정할 수 있습니다.

새 클러스터

Google Cloud 콘솔에서 클러스터 페이지로 이동합니다.

클러스터로 이동
만들기를 선택합니다.
Kafka 클러스터 만들기 페이지가 열립니다.
클러스터 만들기의 단계를 따릅니다.
마지막 단계 전에 선택적 mTLS 구성 섹션을 찾습니다.
CA 풀의 전체 리소스 이름을 projects/PROJECT_ID/LOCATION/LOCATION/caPools/POOL_ID 형식으로 입력합니다.
CA 풀을 더 추가하려면 CA 풀 추가를 클릭합니다. 최대 10개의 CA 풀을 추가할 수 있습니다.
(선택사항) 주 구성원 매핑 규칙을 입력합니다.
만들기를 클릭하여 mTLS가 사용 설정된 클러스터를 만듭니다.

기존 클러스터에서

Google Cloud 콘솔에서 클러스터 페이지로 이동합니다.
클러스터로 이동
업데이트할 클러스터의 이름을 클릭합니다.
수정을 클릭합니다.
mTLS 구성 섹션에서 CA 풀 목록을 추가하거나 수정합니다. 최대 10개의 CA 풀을 추가할 수 있습니다.
(선택사항) 주 구성원 매핑 규칙을 입력하거나 수정합니다.
저장을 클릭합니다.

gcloud

새 클러스터

In the Google Cloud console, activate Cloud Shell.

Activate Cloud Shell

At the bottom of the Google Cloud console, a Cloud Shell session starts and displays a command-line prompt. Cloud Shell is a shell environment with the Google Cloud CLI already installed and with values already set for your current project. It can take a few seconds for the session to initialize.

--mtls-ca-pools 플래그와 함께 gcloud managed-kafka clusters create 명령어를 실행합니다. 이 예시에서는 두 개의 CA 풀이 구성됩니다.

gcloud managed-kafka clusters create CLUSTER_ID \
    --location=LOCATION \
    --cpu=3 \
    --memory=3GiB \
    --subnets=projects/PROJECT_ID/locations/LOCATION/subnetworks/SUBNET_ID \
    --mtls-ca-pools=projects/PROJECT_ID/locations/LOCATION/caPools/POOL_ID_1,projects/PROJECT_ID/locations/LOCATION/caPools/POOL_ID_2

다음을 바꿉니다.

CLUSTER_ID: 클러스터의 ID 또는 이름입니다.
클러스터 이름을 지정하는 방법에 대한 자세한 내용은 Apache Kafka용 관리형 서비스 리소스 이름 지정 가이드라인을 참고하세요. 예: test-mtls-cluster
LOCATION: 클러스터의 위치입니다.
지원되는 위치에 대한 자세한 내용은 지원되는 Apache Kafka용 관리형 서비스 위치를 참고하세요. 예: us-central1
SUBNETS: 연결할 서브넷 목록입니다. 쉼표를 사용하여 여러 서브넷 값을 구분합니다.
서브넷 형식은 projects/PROJECT_ID/locations/LOCATION/subnetworks/SUBNET_ID입니다.

POOL_ID_1: 첫 번째 CA 풀의 ID입니다. 예: test-mtls-pool1

POOL_ID_2: 두 번째 CA 풀의 ID입니다. 예: test-mtls-pool2

기존 클러스터에서

In the Google Cloud console, activate Cloud Shell.

Activate Cloud Shell

At the bottom of the Google Cloud console, a Cloud Shell session starts and displays a command-line prompt. Cloud Shell is a shell environment with the Google Cloud CLI already installed and with values already set for your current project. It can take a few seconds for the session to initialize.
gcloud managed-kafka clusters update 명령어를 사용합니다. 이 명령어는 현재 구성된 전체 풀을 덮어씁니다. 필요한 CA 풀의 전체 목록을 제공합니다. 이 예시에서는 두 개의 CA 풀이 구성됩니다.
```
gcloud managed-kafka clusters update CLUSTER_ID \
    --location=LOCATION \
    --mtls-ca-pools=projects/PROJECT_ID/locations/LOCATION/caPools/POOL_ID_1,projects/PROJECT_ID/locations/LOCATION/caPools/POOL_ID_2
```

다음을 바꿉니다.

CLUSTER_ID: 클러스터의 ID 또는 이름입니다.
클러스터 이름을 지정하는 방법에 대한 자세한 내용은 Apache Kafka용 관리형 서비스 리소스 이름 지정 가이드라인을 참고하세요. 예: test-mtls-cluster
LOCATION: 클러스터의 위치입니다.
지원되는 위치에 대한 자세한 내용은 지원되는 Apache Kafka용 관리형 서비스 위치를 참고하세요. 예: us-central1

POOL_ID_1: 첫 번째 CA 풀의 ID입니다. 예: test-mtls-pool1

POOL_ID_2: 두 번째 CA 풀의 ID입니다. 예: test-mtls-pool2

주 구성원 이름 매핑 구성

클라이언트가 mTLS로 인증하면 기본적으로 Kafka 주체는 인증서의 주체 식별 이름 (DN)에서 파생되며 User:CN=...,OU=...,O=...,L=...,ST=...,C=... 형식입니다. 인증서의 Subject DN을 Kafka ACL에서 더 쉽게 사용할 수 있는 편리한 별칭으로 변환하는 매핑 규칙을 만듭니다. 주체 DN 형식에 대한 자세한 내용은 Apache Kafka 문서의 SSL 사용자 이름 맞춤설정을 참고하세요.

이러한 변환은 정규 표현식을 사용하여 인증서 주체의 일부를 추출하고 다시 포맷하는 ssl.principal.mapping.rules Kafka 브로커 속성으로 정의됩니다.

예를 들어 다음과 같이 규칙을 적용하여 전체 Subject DN을 별칭으로 변환할 수 있습니다.

인증서 주체 DN: CN=order-processing-app,OU=marketing,O=company,C=US
매핑 규칙: RULE:^.*[Cc][Nn]=([a-zA-Z0-9.-]*).*$/$1/L,DEFAULT
결과 Kafka 주 구성원: order-processing-app

이 예시 규칙은 인증서 주체에서 일반 이름 (CN)을 추출하여 Kafka에서 주 구성원 이름으로 사용합니다.

Google Cloud CLI를 사용하여 클러스터에 매핑 규칙을 설정하려면 다음 단계를 따르세요. 콘솔을 사용하는 경우 클러스터를 만들거나 업데이트하는 동안 매핑 규칙을 설정할 수 있습니다.

클러스터를 업데이트하려면 --ssl-principal-mapping-rules 플래그와 함께 gcloud managed-kafka clusters update 명령어를 사용합니다.
```
gcloud managed-kafka clusters update CLUSTER_ID \
    --location=REGION \
    --ssl-principal-mapping-rules='MAPPING_RULE'
```
다음을 바꿉니다.
- CLUSTER_ID: 만들려는 Apache Kafka용 관리형 서비스 클러스터의 ID입니다. 예: test-kafka-cluster
- REGION: 클러스터를 만들 Google Cloud 리전입니다. 예: us-central1
- MAPPING_RULE*: 적용할 매핑 규칙입니다. 예: RULE:^.*[Cc][Nn]=([a-zA-Z0-9.-]*).*$/$1/L,DEFAULT

매핑 규칙을 작성하는 방법에 대한 자세한 내용은 Apache Kafka 문서의 승인 및 ACL을 참고하세요.

mTLS 보안 주체에 대한 Kafka ACL 구성

기본적으로 유효한 mTLS 인증서로 인증에 성공한 클라이언트에는 클러스터에 대한 전체 액세스 권한이 부여됩니다. 최소 권한의 원칙을 적용하려면 Kafka ACL을 만들어 mTLS 주 구성원의 특정 권한을 정의해야 합니다. mTLS 클라이언트의 주체는 인증서의 주체 DN (또는 매핑된 별칭)이며 User:가 앞에 붙습니다.

Kafka ACL을 만들려면 관리형 Kafka ACL 편집자(roles/managedkafka.aclEditor) IAM 역할이 필요합니다.

인증서로 식별되고 orders-topic에 메시지를 생성하고 analytics-topic에서 메시지를 소비하는 애플리케이션이 있다고 가정해 보겠습니다. 매핑 규칙으로 간소화된 애플리케이션의 주 구성원은 order-processing-app입니다. Kafka ACL을 만들 때는 주체에 User:를 접두사로 붙여야 합니다.

클러스터에 WRITE ACL을 적용합니다. gcloud managed-kafka acls add-entry 명령어를 실행하여 orders-topic에 WRITE 권한을 부여합니다.
```
gcloud managed-kafka acls add-entry topic/orders-topic \
    --cluster=CLUSTER_ID \
    --location=REGION \
    --principal=User:order-processing-app \
    --operation=WRITE \
    --permission-type=ALLOW \
    --host="*"
```
다음을 바꿉니다.
- CLUSTER_ID: 만들려는 Apache Kafka용 관리형 서비스 클러스터의 ID입니다. 예: test-kafka-cluster
- REGION: 클러스터를 만들 Google Cloud 리전입니다. 예: us-central1

클러스터에 READ ACL을 적용합니다. gcloud managed-kafka acls add-entry 명령어를 실행하여 analytics-topic에 READ 권한을 부여합니다.

gcloud managed-kafka acls add-entry topic/analytics-topic \
    --cluster=CLUSTER_ID \
    --location=REGION \
    --principal=User:order-processing-app \
    --operation=READ \
    --permission-type=ALLOW \
    --host="*"

이러한 ACL을 적용한 후에는 order-processing-app 클라이언트에 부여한 특정 권한만 있습니다. ACL을 만드는 방법에 대한 자세한 내용은 Kafka ACL 만들기를 참고하세요.

Kafka 클라이언트 구성

클러스터에서 mTLS를 구성한 후에는 이 방법을 사용하여 인증하도록 클라이언트 애플리케이션을 구성해야 합니다. 이 프로세스에는 클라이언트 인증서를 만들고 이를 사용하도록 클라이언트의 속성을 구성하는 작업이 포함됩니다.

클라이언트 머신에서 클라이언트 인증서를 만들고 다운로드합니다. gcloud privateca certificates create 명령어를 실행하여 클러스터에 대해 구성한 CA 풀 중 하나에서 새 인증서를 발급합니다.

이 명령어는 인증서 client-cert.pem와 비공개 키 client-key.pem를 로컬 환경에 다운로드합니다.
```
gcloud privateca certificates create CERTIFICATE_ID \
    --project=PROJECT_ID \
    --issuer-location=REGION \
    --issuer-pool=POOL_ID \
    --ca=CA_NAME \
    --generate-key \
    --dns-san="client.example.com" \
    --subject="CN=test-client-app" \
    --key-output-file=client-key.pem \
    --cert-output-file=client-cert.pem
```
다음을 바꿉니다.
- CERTIFICATE_ID: 인증서 객체의 고유한 이름입니다. 예: order-app-cert
- PROJECT_ID: CA 풀이 포함된 프로젝트의 ID입니다. 예: test-project-12345
- REGION: CA 풀이 있는 리전입니다. 예: us-central1
- POOL_ID: 인증서를 발급할 CA 풀의 ID입니다. 예: test-mtls-pool1
- CA_NAME: 풀 내 인증 기관의 이름입니다. 예: test-sub-ca
- --dns-san="client.example.com": DNS 주체 대체 이름 클라이언트와 관련된 값을 사용할 수 있습니다.
- --subject="CN=test-client-app": 주체 DN입니다. 주 구성원 이름 매핑 규칙을 구성하지 않은 경우 이 이름이 mTLS 주 구성원으로 사용됩니다.

클라이언트 인증서를 보고, 인증서 주체를 보고, ssl.principal.mapping.rules를 확인합니다. gcloud privateca certificates describe 명령어를 실행합니다.

gcloud privateca certificates describe CERTIFICATE_ID \
   --issuer-pool=POOL_ID \
   --issuer-location=REGION

다음을 바꿉니다.

CERTIFICATE_ID: 인증서 객체의 고유한 이름입니다. 예를 들면 order-app-cert입니다.
POOL_ID: 인증서를 발급한 CA 풀의 ID입니다. 예를 들면 test-mtls-pool1입니다.
REGION: CA 풀이 있는 리전입니다. 예를 들면 us-central1입니다.

출력은 다음과 비슷합니다.

certificateDescription:
  aiaIssuingCertificateUrls:
  - http://privateca-content-68e092f4-0000-288c-95cf-30fd3814648c.storage.googleapis.com/a6553d092bbedd752e34/ca.crt
  authorityKeyId:
    keyId: 9568aa9d2baa11a097addc2e24adeaebea0d6a2a
  certFingerprint:
    sha256Hash: 230e52b8411fd094048fca194fc6cf80e41b3e8561298aec3519e13cb1fd05eb
  ...
  subjectDescription:
    hexSerialNumber: 2107b74cf5a814043a38a87eeb6cd7c7891a5f
    lifetime: P30D
    notAfterTime: '2025-07-13T15:34:43Z'
    notBeforeTime: '2025-06-13T15:34:44Z'
    subject:
      commonName: test-client-app
    subjectAltName:
      dnsNames:
      - client.example.com
  ...

Java 키 저장소를 만듭니다. 인증서와 비공개 키를 PKCS#12 파일로 결합한 다음 Java KeyStore (.jks) 파일로 가져옵니다.

# Create a password for the keystore
export KEYSTORE_PASSWORD="KEYSTORE_PASSWORD"

# Combine the key and cert into a PKCS#12 file
openssl pkcs12 -export -inkey client-key.pem -in client-cert.pem \
  -name client -out client-keystore.p12 -password "pass:$KEYSTORE_PASSWORD"

# Import the PKCS#12 file into a Java KeyStore
keytool -importkeystore -srckeystore client-keystore.p12 -srcstoretype pkcs12 \
  -destkeystore client-keystore.jks -srcstorepass "$KEYSTORE_PASSWORD" -deststorepass "$KEYSTORE_PASSWORD"

다음 명령어를 실행하여 키가 성공적으로 저장되었는지 확인할 수 있습니다.

keytool -v -list -keystore client-keystore.jks -storepass "$KEYSTORE_PASSWORD"

출력은 다음과 비슷합니다.

Keystore type: JKS
Keystore provider: SUN

Your keystore contains 1 entry

Alias name: client
Creation date: Jun 13, 2024
Entry type: Private key entry
Certificate chain length: 1
Certificate[1]:
Owner: CN=test-client-app
Issuer: CN=test-sub-ca
...

Owner 줄에는 인증서 주체 DN이 표시됩니다. 기본적으로 Kafka는 Kafka 주 구성원을 CN=...,OU=...,O=...,L=...,ST=...,C=... 형식으로 설정합니다. 자세한 내용은 Apache Kafka 문서의 승인 및 ACL을 참고하세요.

Kafka 클라이언트 속성 및 부트스트랩 주소를 구성합니다. Kafka 클라이언트 애플리케이션에서 SSL 연결의 키 저장소를 사용하도록 다음 속성을 설정합니다. 또한 포트 9192를 사용하여 올바른 부트스트랩 주소를 사용해야 합니다. 클라이언트를 설정하는 방법에 대한 자세한 내용은 빠른 시작: Apache Kafka용 관리형 서비스 클러스터 만들기 및 클라이언트 연결을 참고하세요.
```
security.protocol=SSL
ssl.keystore.location=KEYSTORE_LOCATION
ssl.keystore.password=KEYSTORE_PASSWORD
bootstrap.servers=CLUSTER_BOOTSTRAP_ADDRESS
```
다음을 바꿉니다.
- KEYSTORE_LOCATION: .jks 파일의 경로입니다.
- KEYSTORE_PASSWORD: 키 저장소의 비밀번호입니다.
- CLUSTER_BOOTSTRAP_ADDRESS: 클러스터의 부트스트랩 주소입니다. 부트스트랩 주소를 확인하려면 클러스터 세부정보 보기를 참고하세요. 포트 번호를 9192로 추가해야 합니다.

클라이언트 구성 보안

위의 예에서는 비공개 키와 비밀번호를 로컬에 저장하므로 프로덕션 환경에는 권장하지 않습니다. 프로덕션의 경우 클라이언트 보안 비밀을 안전하게 처리하세요. 옵션은 다음과 같습니다.

키 저장소와 비밀번호를 Google Cloud Secret Manager에 보안 비밀로 저장하고 런타임에 애플리케이션 코드에서 검색합니다.
GKE에 애플리케이션을 배포하는 경우 Secret Manager 부가기능을 사용하여 런타임에 애플리케이션의 파일 시스템에 보안 비밀을 마운트합니다.

mTLS 모니터링

Cloud Monitoring 및 Cloud Logging의 측정항목과 로그를 사용하여 mTLS 인증서 업데이트의 상태를 모니터링할 수 있습니다.

mTLS 인증서 업데이트 상태를 사전 예방적으로 모니터링하려면 Monitoring에서 managedkafka.googleapis.com/mtls_truststore_update_count 측정항목을 사용하세요. 이 측정항목은 트러스트 저장소 업데이트 시도 횟수를 집계하며 SUCCESS 또는 CA_POOL_FETCH_ERROR와 같은 실패 이유일 수 있는 STATUS 라벨을 포함합니다.

Managed Service for Apache Kafka 서비스는 클러스터별로 시간당 한 번씩 신뢰 저장소를 새로고침하려고 시도합니다. 이 측정항목이 3시간 이상 지속적인 오류 수를 보고하는 경우 알림을 만드는 것이 좋습니다. 이는 수동 개입이 필요한 잘못된 구성을 나타낼 수 있기 때문입니다.

신뢰 저장소 업데이트는 Certificate Authority Service API의 할당량을 사용합니다. 다음 사항을 이해하는 것이 중요합니다.

업데이트 프로세스에서는 FetchCaCerts 메서드를 호출하며, 이 메서드에는 API requests per minute per region 할당량이 적용됩니다.
이 할당량 사용량은 참조된 CA 풀이 포함된 프로젝트에 귀속되며 Apache Kafka용 관리형 서비스 프로젝트에는 귀속되지 않습니다.
기본 한도는 리전당 초당 쿼리 수 (QPS) 400개입니다. 클러스터당 시간당 요청 빈도가 낮으므로 이러한 신뢰 저장소 업데이트로 인해 이 할당량을 초과할 가능성은 낮습니다.

Logging에서 로그를 확인하여 신뢰 저장소 업데이트를 추적할 수도 있습니다. 다음 로그 항목을 찾아 업데이트가 성공했는지 확인합니다.

Managed Service for Apache Kafka updated the mTLS trust store
Added root CA certificate to trust store

다음 단계

클러스터를 만드는 방법을 알아보세요.
클러스터 세부정보를 보는 방법을 알아보세요.

Apache Kafka®는 미국 및/또는 다른 국가에서 사용되는 Apache Software Foundation 또는 해당 계열사의 등록 상표입니다.

mTLS 인증 구성 컬렉션을 사용해 정리하기 내 환경설정을 기준으로 콘텐츠를 저장하고 분류하세요.

시작하기 전에

필수 역할 및 권한

필수 권한

서비스 에이전트에 CA 풀에 대한 액세스 권한 부여

개별 CA 풀

모든 CA 풀

클러스터에서 mTLS 사용 설정

콘솔

새 클러스터

기존 클러스터에서

gcloud

새 클러스터

기존 클러스터에서

주 구성원 이름 매핑 구성

mTLS 보안 주체에 대한 Kafka ACL 구성

Kafka 클라이언트 구성

클라이언트 구성 보안

mTLS 모니터링

다음 단계

mTLS 인증 구성