Kafka 보안 — 인증(SASL/SSL)과 인가(ACL)
Apache Kafka 보안(인증/인가) 공식 문서·기술 블로그 종합 및 면접 단골 질문 정리 (웹 리서치, 2026) — Apache Kafka 공식 문서(kafka.apache.org/40/security) + Confluent/Conduktor 등 기술 블로그 종합 Apache Kafka 4.0 공식 문서 security/authorization-and-acls + SASL 메커니즘 비교 자료 종합
이 모듈을 다 읽으면
- Kafka 보안이 암호화·인증·인가 세 계층으로 독립적으로 구성된다는 것을 설명할 수 있다
- SASL의 세 가지 메커니즘(PLAIN/SCRAM/OAUTHBEARER)이 각각 어떤 상황에 적합한지 구분할 수 있다
- ACL이 무엇을 기준으로 허용/거부를 판단하는지, 그리고 KRaft에서 ACL 저장 위치가 어떻게 달라졌는지 설명할 수 있다
kafka-learn-14/19/40에서 SASL/ACL이 산발적으로 언급만 됐던 것을 모아, Kafka 보안의 3계층 구조(암호화/인증/인가)와 각 메커니즘의 실제 동작·선택 기준을 정리한다.
보안의 3개 독립 계층 — 암호화·인증·인가
Kafka의 보안은 서로 독립적인 세 계층으로 나뉜다. (1) 암호화(Encryption): TLS로 클라이언트-브로커, 브로커-브로커 간 통신 구간을 암호화해 도청을 막는다. (2) 인증(Authentication): 접속한 주체가 누구인지 확인한다 — SASL(PLAIN/SCRAM/GSSAPI/OAUTHBEARER) 또는 상호 TLS(mTLS, 클라이언트 인증서로 신원 확인)로 수행한다. (3) 인가(Authorization): 인증된 주체(Principal)가 특정 리소스(토픽, 컨슈머 그룹 등)에 대해 무엇을 할 수 있는지 ACL로 결정한다.
세 계층이 독립적이라는 것은, 예를 들어 TLS로 암호화만 하고 인증은 안 할 수도 있고(운영 관행상 권장되진 않음), SASL 인증은 하되 ACL 인가는 켜지 않아 인증된 사용자는 전부 허용할 수도 있다는 뜻이다. 실무 권장 조합은 TLS(암호화) + SASL/SCRAM 또는 mTLS(인증) + ACL(인가, 최소 권한 원칙)을 전부 켜는 것이다.
핵심 포인트
- 암호화(TLS), 인증(SASL/mTLS), 인가(ACL)는 서로 독립적으로 켜고 끌 수 있는 계층이다
- 실무 권장은 세 계층을 모두 켜는 것 — TLS + SASL/SCRAM(또는 mTLS) + ACL(최소 권한 원칙)
SASL 메커니즘 3가지 — PLAIN vs SCRAM vs OAUTHBEARER
SASL/PLAIN은 사용자명·비밀번호를 평문으로 전송하는 가장 단순한 방식이라 반드시 TLS와 함께 써야 한다(TLS 없이 PLAIN만 쓰면 비밀번호가 그대로 노출된다). SASL/SCRAM(SCRAM-SHA-256 또는 SHA-512)은 비밀번호에 salt를 더해 해시한 값으로 challenge-response 방식의 인증을 수행해, PLAIN보다 훨씬 안전하며 브로커 쪽에도 평문 비밀번호를 저장하지 않는다 — TLS 없이도(권장하진 않지만) PLAIN보다는 안전하다. SASL/OAUTHBEARER는 OAuth 2.0 bearer 토큰으로 인증하는 방식으로, 사내 IdP(Identity Provider)나 클라우드 인증 체계와 Kafka를 연동할 때 쓴다 — 전통적인 사용자명/비밀번호 기반이 아니라 토큰 발급·검증 체계에 올라타는 방식이라 SSO/클라우드 네이티브 환경에 특히 잘 맞는다.
SASL/GSSAPI(Kerberos)는 전통적인 온프레미스 엔터프라이즈 환경(Active Directory 연동)에서 여전히 쓰이지만 설정이 복잡해 신규 구축에서는 SCRAM이나 OAUTHBEARER를 더 선호하는 경향이 있다.
핵심 포인트
- SASL/PLAIN은 평문 전송 — 반드시 TLS와 함께 써야 한다
- SASL/SCRAM은 salt+해시 기반 challenge-response로 PLAIN보다 안전하며 비밀번호를 평문 저장하지 않는다
- SASL/OAUTHBEARER는 OAuth 2.0 토큰 기반 — 사내 IdP/클라우드 인증 체계와 연동할 때 적합
ACL — 누가 무엇을 할 수 있는가
ACL(Access Control List)은 'Principal {P}가 Host {H}에서 Resource {R}에 대해 Operation {O}를 [허용|거부]한다'는 규칙 집합이다. Principal은 인증된 사용자/그룹(예: User:alice), Operation은 Read/Write/Create/Describe/Delete/Alter 등, Resource Type은 Topic/Group/Cluster/TransactionalId 등이며, Resource Name은 정확히 일치하거나 접두사(prefixed) 매칭도 가능하다. Host는 특정 IP로 제한하거나 *(전체 허용)로 둘 수 있다.
kafka-acls.sh CLI로 ACL을 추가/조회/삭제하며, super.users 설정에 등록된 Principal(예: User:admin)은 모든 ACL 검사를 건너뛴다(관리 작업용, 최소한으로 유지해야 한다). ACL을 아예 안 만든 리소스에 대한 기본 동작은 allow.everyone.if.no.acl.found 설정에 따라 달라지는데, 프로덕션에서는 이 값을 false(ACL 없으면 거부)로 두고 필요한 것만 명시적으로 허용하는 최소 권한 원칙이 안전하다.
핵심 포인트
- ACL 규칙 구조: Principal + Host + Resource(Type/Name) + Operation + Allow/Deny
- kafka-acls.sh로 관리하며, super.users에 등록된 Principal은 ACL 검사를 건너뛴다(최소한으로 유지)
- allow.everyone.if.no.acl.found를 false로 두고 최소 권한 원칙(명시적으로 허용한 것만 허용)을 적용하는 게 프로덕션 관행
KRaft에서 달라진 것 — ACL 저장 위치의 이동
kafka-learn-34에서 다룬 ZooKeeper→KRaft 전환은 ACL 저장 방식에도 영향을 준다. ZooKeeper 시절에는 AclAuthorizer가 ACL을 ZooKeeper의 znode에 저장했다. KRaft 모드에서는 authorizer.class.name을 org.apache.kafka.metadata.authorizer.StandardAuthorizer로 설정하며, StandardAuthorizer는 ACL을 ZooKeeper가 아니라 Kafka 자신의 __cluster_metadata 토픽(컨트롤러 쿼럼이 관리하는 메타데이터 로그)에 저장한다 — 이는 KRaft 전체 설계 철학과 일치한다: 메타데이터(토픽 설정, 파티션 배치, 그리고 이제 ACL까지)를 전부 별도 시스템(ZooKeeper) 없이 Kafka 자체 로그로 관리한다.
실무적으로는 kafka-acls.sh 사용법 자체는 거의 동일하지만, 내부적으로 ACL 데이터가 어디 저장되는지(ZooKeeper znode vs __cluster_metadata 토픽)가 바뀌었다는 점과, authorizer.class.name 설정값이 ZooKeeper 시절의 kafka.security.authorizer.AclAuthorizer에서 StandardAuthorizer로 바뀌었다는 점을 알아둬야 한다(구버전 설정을 그대로 KRaft 클러스터에 옮기면 이 설정을 갱신해야 한다).
핵심 포인트
- ZooKeeper 시절: AclAuthorizer가 ACL을 ZooKeeper znode에 저장
- KRaft 모드: StandardAuthorizer(authorizer.class.name)가 ACL을 __cluster_metadata 토픽에 저장 — 메타데이터를 전부 Kafka 자체 로그로 통합한다는 KRaft 철학과 일치
- ZK→KRaft 마이그레이션 시 authorizer.class.name 설정값을 반드시 갱신해야 한다