AWS Lambda가 자체 관리형 Apache Kafka 이벤트 소스 매핑에 OAuth 2.0 인증 옵션을 더했다. 이벤트 소스 매핑은 Kafka 토픽을 읽어 Lambda 함수로 이벤트를 전달하는 연결이다. 이번 설정은 Lambda가 Kafka 브로커에 SASL/OAUTHBEARER 방식으로 인증할 수 있게 한다. AWS 문서에 따르면 Lambda가 필요한 액세스 토큰을 요청하며, 고객은 사용할 인증 재료와 권한 범위를 설정한다.
고객 자격 증명을 사용하는 방식에서는 OAuth 클라이언트 정보를 AWS Secrets Manager에 보관하고 그 시크릿 ARN을 연결 설정에 넣는다. scope는 Lambda가 토큰을 요청할 때 요구할 권한 범위, audience는 토큰을 받을 서비스 대상을 가리킨다. IAM 기반 옵션은 Lambda 실행 역할을 바탕으로 웹 아이덴티티 토큰을 요청하며, 이 방식에서는 대상 서비스와 브로커가 그 신원을 신뢰하도록 맞춰야 한다. 두 방식은 사용하는 자격 증명과 역할 경계가 다르다.
토큰보다 브로커 권한까지 맞춰야 한다
토큰을 취득하는 일은 Lambda가 처리하지만, 어떤 인증 방식을 쓰고 클라이언트 시크릿이나 실행 역할을 어떻게 관리할지는 고객의 설정 책임이다. 팀은 토큰에 요청할 scope와 audience를 정하고, Kafka 브로커에는 해당 신원이 필요한 토픽과 소비자 그룹에 접근할 권한을 부여해야 한다. 클라이언트 시크릿을 쓰는 조직은 교체와 접근통제 절차도 운영해야 한다. AWS 문서는 토큰 갱신 주기 같은 세부 동작을 정하지 않으므로 이를 임의로 가정해서는 안 된다.
이 흐름은 “Kafka가 이벤트를 쌓고, Lambda가 연결 설정에 따라 토큰을 받아 브로커에 인증한 다음, 이벤트를 함수로 넘기는” 구조다. 그래서 OAuth 설정은 로그인 화면을 추가하는 일이 아니라 서비스 간 신원과 브로커 권한을 다시 묶는 작업이다. scope나 audience가 맞지 않으면 연결은 살아 있어도 인증에 실패할 수 있고, 지나치게 넓은 권한은 장애 범위를 키울 수 있다.
도입 전에는 테스트 토픽에서 두 인증 방식의 권한 부여, 거부, 시크릿 교체와 실행 역할 변경을 확인해야 한다. AWS의 공식 Lambda·CLI 문서는 지원 필드와 토큰 요청 설정을 설명한다. 실제 리전과 Kafka 제공자 지원 여부는 적용할 환경의 문서와 구성을 기준으로 점검하면 된다.
