[Kafka 101] 카프카 보안 - 인증과 인가 (Kafka Security - Authentication & Authorization)

들어가며

 기본적으로 카프카는 어느 누구나 메시지를 쓸 수 있고, 또 어느 누구나 메시지를 읽어갈 수 있습니다. 하지만 이러한 환경은 개발 환경이나 혹은 극도로 폐쇄된 환경이 아니라면 적합하지 않습니다. 이번 글은 카프카에 누가 요청을 보내는지, 나아가 그 요청자의 권한에 따라 요청 범위를 적절하게 제한하는 카프카 인증과 인가에 대해 살펴봅니다. 

 참고로 이번 글은 살펴보는 글이기 때문에 자세한 설정 및 구성 방법 등에 대해서 설명하지 않습니다. 해당 내용은 공식 문서를 참고하시길 바랍니다.

카프카 인증

 카프카가 인증을 처리하는 방식은 SSL 방식과 SASL 방식으로 크게 2가지 방식이 있습니다. 

• SSL 방식 : 인증서를 이용한 인증 방식
• SASL 방식 : SASL 프로토콜을 이용한 인증 방식

 SSL 방식은 일반적인 방식이라서 적용하는 것에 큰 러닝 커브는 없습니다. 다만, SSL 방식을 적용할 경우 클라이언트에서 메시지가 암호화되어 전달됩니다. 이 암호화된 메시지는 브로커에서 다시 복호화가 되는데, 이때 CPU 부하가 발생하게 됩니다. 메시지 암호화가 필수적인 파이프라인이라면 인증과 함께 고려해볼 수 있겠습니다.

 반대로 SASL(Simple Authentication and Security Layer) 방식은 많이 생소한 방식이라 SSL 방식보다 러닝커브가 있습니다(저는 그랬습니다ㅠ). 하지만 SASL 프레임워크는 인증 처리 방식을 요구사항에 맞게 변경할 수 있는 plug-in 형태이기 때문에 SSL 방식보다 더욱 유연합니다. 그리고 기본적으로 메시지 암호화를 하지 않기 때문에 추가적인 부하가 발생하지 않습니다. (추가로 SSL을 적용할 수 있습니다)

SASL 프레임워크와 카프카에서 지원하는 SASL 메커니즘

 SASL 프레임워크는 Simple Authentication and Security Layer라는 이름처럼 애플리케이션 프로토콜들로 부터 인증 처리를 위한 별도의 층(Layer)을 분리하고, 그 층에서 인증을 처리하는 방식입니다. 조금 더 쉽게 그리고 카프카와 관련지어서 설명하자면, 클라이언트와 카프카가 처음 연결을 할 때 인증을 위한 단계(층; Layer)를 거친 후에 메시지 요청을 실행하게 됩니다. 따라서 처음에 인증 단계를 거치면 이후에 애플리케이션 단에서 인증을 처리하지 않아도 됩니다.

매우 추상화된 SASL 프레임워크를 통한 인증 처리 단계

 위 그림에서 볼 수 있는 것처럼 SASL 프레임워크는 다양한 메커니즘으로 인증을 처리할 수 있습니다. 카프카에서 기본적으로 제공하는 SASL 메커니즘은 다음 4가지가 있습니다.

• PLAIN : 문자열 아이디/패스워드를 이용한 인증
• SCRAM : Salt 등을 이용한 SCRAM 방식을 이용한 인증
• OAUTHBEARER : OAuth2 방식을 이용한 인증
• GSSAPI : Kerberos를 이용한 인증

 PLAIN 메커니즘은 말 그대로 아이디와 패스워드에 대한 문자열을 서로 비교하는 방식입니다. SSL을 적용하지 않으면 계정 유출 등에 위험이 있고, 또 매우 약한 단계의 인증 방식이므로 거의 사용되지 않습니다. SCRAM 메커니즘은 번들로 제공되는 `kafka-configs`명령어 스크립트를 이용하여 주키퍼에 계정 정보를 생성하고, 이 계정 정보를 이용하여 인증을 요청/처리합니다.

 그리고 가장 최근(?)에 추가된 인증 방식인 OAUTHBEARER 메커니즘은 JWT을 이용한 OAuth2 인증 프로토콜을 사용하는 메커니즘 입니다. 근래에 가장 익숙한 인증 방식이지만, 별도의 OAuth2 인증 서버와 별도의 OAuth2 인증을 처리할 CallbackHandler를 구현해야 합니다. 기본적으로 카프카에서 제공하는 oauthbearer callbackhander는 아무런 보안 처리가 되어있지 않기 때문입니다.

 GSSAPI 메커니즘은 Kerberos 프로토콜을 이용한 인증 방식입니다. 그렇기 때문에 적용하는데에 가장 어렵고 또 Keytab 파일을 클라이언트와 공유해야 하기 때문에 운영 관리에 복잡한 부분이 있습니다. 하지만 앞서 살펴본 메커니즘 중에서 가장 강력한 보안성을 제공합니다. (실제로 대부분의 환경에서 적용되어 있습니다.)

커버로스의 인증 처리 과정. SS가 카프카가 됩니다.(출처 : https://ldap.or.kr)

카프카 인가

 인증이 완료되면 클라이언트 계정 정보를 바탕으로 권한을 확인합니다. 카프카는 기본적으로 ACL(Access Control List) 방식으로 권한을 확인합니다. ACL은 해당 계정 정보가 어떤 권한이 있는지 저장하고 권한을 확인하는 방식인데, 카프카는 권한 정보를 주키퍼에 저장하고 관리하므로써 인가를 처리합니다.

카프카 인가 리소스와 범위

kafka-acls --bootstrap-server localhost:9092 --command-config adminclient-configs.conf \
 --add --allow-principal User:alice --allow-principal User:fred --allow-host host-1 \
 --allow-host host-2 --operation read --operation write --topic finance-topic

 위는 번들로 제공되는 `kafka-acls` 명령어 스크립트를 이용하여, alice, fred 계정이 host-1, host-2로부터 finance-topic 토픽에 대한 read, write 요청 권한을 추가하는 명령어입니다. 이처럼 카프카 acl은 일반적으로 "계정 P는 호스트 H로부터 패턴 RP에 대응하는 리소스 R에 대한 작업 O를 허가/불가 한다"는 포맷으로 저장, 관리됩니다. 

 그렇다면 카프카의 어떤 리소스까지 권한 관리가 가능할까요? 권한 관리가 되는 카프카 리소스는 다음과 같습니다.

• 토픽 (Topic)
• 컨슈머 그룹 (Group)
• 클러스터 (Cluster)
• 트랜젝션 ID (TransactionalId)
• Delegation Token

그리고 이러한 리소스에 대해 카프카는 다음 작업에 대한 권한 관리가 가능합니다.

• 읽기 (Read)
• 쓰기 (Write)
• 생성 (Create)
• 삭제 (Delete)
• 수정 (Alter)
• 상세 (Describe)
• ClusterAction
• DescribeConfigs
• AlterConfigs
• IdempotentWrite
• All

 이처럼 다양한 리소스와 작업에 대해 ACL을 등록하여 권한을 관리할 수 있습니다. 

마무리

 카프카는 아키텍처 중앙에서 다양한 클라이언트의 요청을 수용합니다. 특히 메시지 발행의 경우 임의의 프로듀서가 토픽 파티션에 메시지를 발행할 경우 해당 토픽 파티션이 망가져, 아예 다른 토픽으로 마이그레이션해야 할 수도 있습니다(카프카는 한번 쓰이면 수정할 수 없기 때문입니다.). 그렇기 때문에 카프카를 구성할 때 인증과 인가는 필수적입니다. 

ps 1. 혹시 잘못되거나 부족한 부분은 댓글로 남겨주시길 바랍니다. 
ps 2. 내용이 마음에 드셨다면 공감 버튼❤️을 눌러주세요!