인가와 ACL
인가와 ACL (Authorization and ACLs)
이 페이지는 Kafka에서 ACL(Access Control List)로 리소스 접근을 제어하는 방법을 다뤄요. ACL 구조와 기본 동작, kafka-acls.sh CLI 전 옵션, 실전 예시, 그리고 각 프로토콜(API) 요청이 필요한 작업·리소스 조합까지 자세히 나와 있어요.
출처: 문서
본문
Kafka는 플러그 가능한 인가 프레임워크를 제공하며, 이는 서버 구성의 authorizer.class.name 속성으로 구성됩니다. 구성된 구현은 org.apache.kafka.server.authorizer.Authorizer를 확장해야 합니다. Kafka는 ACL을 클러스터 메타데이터(KRaft 메타데이터 로그)에 저장하는 기본 구현을 제공합니다. KRaft 클러스터의 경우 모든 노드(브로커, 컨트롤러, 또는 combined 브로커/컨트롤러 노드)에서 다음 구성을 사용하세요.
authorizer.class.name=org.apache.kafka.metadata.authorizer.StandardAuthorizer
Kafka ACL은 "Principal {P}는 ResourcePattern {RP}와 일치하는 Resource {R}에서 Host {H}의 Operation {O}가 [허용|거부]된다"는 일반 형식으로 정의됩니다. ACL 구조는 KIP-11, 리소스 패턴은 KIP-290에서 더 자세히 읽을 수 있습니다. ACL을 추가·제거·나열하려면 Kafka ACL CLI kafka-acls.sh를 사용할 수 있습니다.
ACL이 없을 때의 동작 (Behavior Without ACLs)
리소스(R)에 정의된 ACL이 없어, 즉 어떤 ACL도 그 리소스와 일치하지 않으면 Kafka는 그 리소스에 대한 접근을 제한합니다. 이 상황에서는 슈퍼 유저만 접근할 수 있습니다.
기본 동작 변경 (Changing the Default Behavior)
ACL이 없는 리소스를(슈퍼 유저 대신) 모든 사용자가 접근 가능하게 하려면 기본 동작을 변경할 수 있습니다. 그러려면 server.properties에 다음 줄을 추가하세요.
allow.everyone.if.no.acl.found=true
이 설정이 활성화되면 리소스에 ACL이 정의되어 있지 않을 때 Kafka는 모든 사람의 접근을 허용합니다. 리소스에 ACL이 하나 이상 정의되면 그 설정과 무관하게 해당 ACL 규칙이 평소처럼 적용됩니다. server.properties에 다음과 같이 슈퍼 유저를 추가할 수도 있습니다(SSL 사용자 이름에 쉼표가 포함될 수 있으므로 구분자는 세미콜론입니다. 기본 PrincipalType 문자열 "User"는 대소문자를 구분합니다).
super.users=User:Bob;User:Alice
KRaft Principal 전달 (KRaft Principal Forwarding)
KRaft 클러스터에서 CreateTopics나 DeleteTopics 같은 admin 요청은 클라이언트가 브로커 리스너로 보냅니다. 그러면 브로커는 controller.listener.names에 구성된 첫 리스너를 통해 요청을 활성 컨트롤러로 전달합니다. 이 요청들의 인가는 컨트롤러 노드에서 수행됩니다. 이는 클라이언트의 기본 요청과 클라이언트 principal을 모두 패키징하는 Envelope 요청을 통해 달성됩니다. 컨트롤러가 브로커로부터 전달된 Envelope 요청을 받으면, 먼저 인증된 브로커 principal로 Envelope 요청을 인가합니다. 그런 다음 전달된 principal로 기본 요청을 인가합니다. 이 모든 것은 Kafka가 클라이언트 principal을 직렬화·역직렬화하는 방법을 이해해야 함을 의미합니다. 인증 프레임워크는 principal.builder.class 구성을 오버라이드해 커스텀 principal을 허용합니다. 커스텀 principal이 KRaft에서 작동하려면 구성된 클래스가 org.apache.kafka.common.security.auth.KafkaPrincipalSerde를 구현해 Kafka가 principal을 직렬화·역직렬화하는 방법을 알 수 있어야 합니다. 기본 구현 org.apache.kafka.common.security.authenticator.DefaultKafkaPrincipalBuilder는 소스 코드에 정의된 Kafka RPC 형식(clients/src/main/resources/common/message/DefaultPrincipalData.json)을 사용합니다.
SSL 사용자 이름 커스터마이즈 (Customizing SSL User Name)
기본적으로 SSL 사용자 이름은 "CN=writeuser,OU=Unknown,O=Unknown,L=Unknown,ST=Unknown,C=Unknown" 형식입니다. server.properties에서 ssl.principal.mapping.rules를 커스텀 규칙으로 설정해 이를 변경할 수 있습니다. 이 구성은 X.500 distinguished name을 짧은 이름으로 매핑하는 규칙 목록을 허용합니다. 규칙은 순서대로 평가되며, distinguished name과 일치하는 첫 규칙이 그 이름을 짧은 이름으로 매핑하는 데 사용됩니다. 목록의 이후 규칙은 무시됩니다. ssl.principal.mapping.rules의 형식은 각 규칙이 "RULE:"으로 시작하고 다음 형식의 표현식을 담는 목록입니다. 기본 규칙은 X.500 인증서 distinguished name의 문자열 표현을 반환합니다. distinguished name이 패턴과 일치하면 치환 명령이 이름에 대해 실행됩니다. 또한 소문자/대문자 옵션을 지원해 번역 결과를 모두 소문자/대문자로 강제할 수 있습니다. 이는 규칙 끝에 "/L" 또는 "/U"를 추가해 수행합니다.
RULE:pattern/replacement/
RULE:pattern/replacement/[LU]
예시 ssl.principal.mapping.rules 값:
RULE:^CN=(.*?),OU=ServiceUsers.*$/$1/,
RULE:^CN=(.*?),OU=(.*?),O=(.*?),L=(.*?),ST=(.*?),C=(.*?)$/$1@$2/L,
RULE:^.*[Cc][Nn]=([a-zA-Z0-9.]*).*$/$1/L,
DEFAULT
위 규칙은 distinguished name "CN=serviceuser,OU=ServiceUsers,O=Unknown,L=Unknown,ST=Unknown,C=Unknown"을 "serviceuser"로, "CN=adminUser,OU=Admin,O=Unknown,L=Unknown,ST=Unknown,C=Unknown"을 "adminuser@admin"으로 번역합니다. 고급 사용 사례의 경우 server.properties에서 커스텀 PrincipalBuilder를 설정해 이름을 커스터마이즈할 수 있습니다.
principal.builder.class=CustomizedPrincipalBuilderClass
SASL 사용자 이름 커스터마이즈 (Customizing SASL User Name)
기본적으로 SASL 사용자 이름은 Kerberos principal의 기본(primary) 부분입니다. server.properties에서 sasl.kerberos.principal.to.local.rules를 커스텀 규칙으로 설정해 이를 변경할 수 있습니다. sasl.kerberos.principal.to.local.rules의 형식은 각 규칙이 Kerberos 구성 파일(krb5.conf)의 auth_to_local과 같은 방식으로 작동하는 목록입니다. 이는 번역 결과를 모두 소문자/대문자로 강제하는 추가 소문자/대문자 규칙도 지원합니다. 이는 규칙 끝에 "/L" 또는 "/U"를 추가해 수행합니다. 구문은 아래 형식을 확인하세요. 각 규칙은 "RULE:"으로 시작하고 다음 형식의 표현식을 담습니다. 자세한 내용은 Kerberos 문서를 참고하세요.
RULE:[n:string](regexp)s/pattern/replacement/
RULE:[n:string](regexp)s/pattern/replacement/g
RULE:[n:string](regexp)s/pattern/replacement//L
RULE:[n:string](regexp)s/pattern/replacement/g/L
RULE:[n:string](regexp)s/pattern/replacement//U
RULE:[n:string](regexp)s/pattern/replacement/g/U
기본 규칙을 유지하면서 [email protected]을 user로 올바르게 번역하는 규칙을 추가하는 예는 다음과 같습니다.
sasl.kerberos.principal.to.local.rules=RULE:[1:$1@$0](.*@MYDOMAIN.COM)s/@.*//,DEFAULT
커맨드 라인 인터페이스 (Command Line Interface)
Kafka 인가 관리 CLI는 다른 모든 CLI와 함께 bin 디렉터리에서 찾을 수 있습니다. CLI 스크립트는 kafka-acls.sh입니다. 다음은 스크립트가 지원하는 모든 옵션을 나열합니다.
- Read
- Write
- Create
- Delete
- Alter
- Describe
- ClusterAction
- DescribeConfigs
- AlterConfigs
- IdempotentWrite
- CreateTokens
- DescribeTokens
- All
| 옵션 | 설명 | 기본값 | 옵션 타입 |
|---|---|---|---|
| --add | 사용자가 acl을 추가하려고 한다는 것을 스크립트에 표시. | Action | |
| --remove | 사용자가 acl을 제거하려 한다는 것을 표시. | Action | |
| --list | 사용자가 acl을 나열하려 한다는 것을 표시. | Action | |
| --bootstrap-server | Kafka 클러스터 브로커에 연결을 설정하는 데 사용할 host/port 쌍 목록. --bootstrap-server 또는 --bootstrap-controller 중 하나만 지정해야 함. | Configuration | |
| --bootstrap-controller | Kafka 클러스터 컨트롤러에 연결을 설정하는 데 사용할 host/port 쌍 목록. 하나만 지정해야 함. | Configuration | |
| --command-config | Admin Client에 전달할 구성을 담는 속성 파일. 이 옵션은 --bootstrap-server 옵션과만 함께 사용할 수 있음. | Configuration | |
| --cluster | 사용자가 단일 클러스터 리소스에 대한 acl과 상호작용하려 한다는 것을 표시. | ResourcePattern | |
| --topic [topic-name] | 사용자가 토픽 리소스 패턴(들)에 대한 acl과 상호작용하려 한다는 것을 표시. | ResourcePattern | |
| --group [group-name] | 사용자가 컨슈머 그룹 리소스 패턴(들)에 대한 acl과 상호작용하려 한다는 것을 표시. | ResourcePattern | |
| --transactional-id [transactional-id] | ACL을 추가·제거할 transactionalId. 값 *는 ACL이 모든 transactionalId에 적용됨을 나타냄. | ResourcePattern | |
| --delegation-token [delegation-token] | ACL을 추가·제거할 위임 토큰. 값 *는 ACL이 모든 토큰에 적용됨을 나타냄. | ResourcePattern | |
| --user-principal [user-principal] | ACL을 추가·제거할 사용자 리소스. 현재 위임 토큰과 관련해서 지원됨. 값 *는 ACL이 모든 사용자에 적용됨을 나타냄. | ResourcePattern | |
| --resource-pattern-type [pattern-type] | 사용자가 사용하려는 리소스 패턴 타입(--add의 경우) 또는 리소스 패턴 필터(--list와 --remove의 경우). acl 추가 시 'literal' 또는 'prefixed' 같은 구체적 패턴 타입. 목록·제거 시 특정 패턴 타입 필터 또는 'any'·'match' 필터 값을 사용. 'any'는 어떤 패턴 타입도 일치하지만 리소스 이름은 정확히 일치, 'match'는 공급된 리소스(들)에 영향을 주는 모든 acl을 나열·제거하기 위해 패턴 매칭 수행. WARNING: 'match'를 '--remove' 스위치와 함께 사용할 때는 주의해야 함. | literal | Configuration |
| --allow-principal | Allow 권한으로 ACL에 추가될 PrincipalType:name 형식의 principal. 기본 PrincipalType 문자열 "User"는 대소문자 구분. 단일 명령에 여러 --allow-principal 지정 가능. | Principal | |
| --deny-principal | Deny 권한으로 ACL에 추가될 PrincipalType:name 형식의 principal. 기본 "User"는 대소문자 구분. 여러 개 지정 가능. | Principal | |
| --principal | --list 옵션과 함께 사용될 PrincipalType:name 형식의 principal. 기본 "User"는 대소문자 구분. 지정된 principal에 대한 ACL을 나열. 여러 개 지정 가능. | Principal | |
| --allow-host | --allow-principal에 나열된 principal이 접근할 IP 주소. --allow-principal이 지정되면 기본값은 *로 "모든 호스트"를 의미. | if --allow-principal is specified defaults to * | Host |
| --deny-host | --deny-principal에 나열된 principal이 접근이 거부될 IP 주소. --deny-principal이 지정되면 기본값 *는 "모든 호스트". | if --deny-principal is specified defaults to * | Host |
| --operation | 허용 또는 거부될 작업. 유효 값: (위 목록). | All | Operation |
| --producer | 프로듀서 역할에 대한 acl을 추가/제거하는 편의 옵션. 토픽에 대해 WRITE, DESCRIBE, CREATE를 허용하는 acl을 생성. | Convenience | |
| --consumer | 컨슈머 역할에 대한 acl을 추가/제거하는 편의 옵션. 토픽에 대해 READ, DESCRIBE를, 컨슈머 그룹에 대해 READ를 허용하는 acl을 생성. | Convenience | |
| --idempotent | 프로듀서에 대해 멱등성을 활성화. --producer 옵션과 함께 사용해야 함. 프로듀서가 특정 transactional-id에 대해 인가되면 멱등성이 자동으로 활성화됨에 유의. | Convenience | |
| --force | 모든 질문에 yes를 가정하고 프롬프트하지 않는 편의 옵션. | Convenience |
예시 (Examples)
$ bin/kafka-acls.sh --bootstrap-server localhost:9092 --add --allow-principal User:Bob --allow-principal User:Alice --allow-host 198.51.100.0 --allow-host 198.51.100.1 --operation Read --operation Write --topic Test-topic
- ACL 추가: "Principal User:Bob과 User:Alice는 IP 198.51.100.0과 IP 198.51.100.1에서 Topic Test-Topic에 대해 Read와 Write 작업이 허용된다"는 acl을 추가하려 한다고 가정해 봅시다. 다음 옵션으로 CLI를 실행하면 됩니다.
기본적으로 어떤 리소스에 대한 작업에 접근을 허용하는 명시적 acl이 없는 모든 principal은 거부됩니다. 어떤 principal을 제외한 모든 사람에게 접근을 허용하는 allow acl이 정의된 드문 경우에는 --deny-principal과 --deny-host 옵션을 사용해야 합니다. 예를 들어 모든 사용자가 Test-topic에서 Read할 수 있게 하되 IP 198.51.100.3의 User:BadBob만 거부하려면 다음 명령을 사용할 수 있습니다.
$ bin/kafka-acls.sh --bootstrap-server localhost:9092 --add --allow-principal User:'*' --allow-host '*' --deny-principal User:BadBob --deny-host 198.51.100.3 --operation Read --topic Test-topic
--allow-host와 --deny-host는 IP 주소만 지원합니다(호스트 이름은 지원되지 않음). 위 예들은 리소스 패턴 옵션으로 --topic [topic-name]을 지정해 토픽에 acl을 추가합니다. 마찬가지로 --cluster를 지정해 클러스터에, --group [group-name]을 지정해 컨슈머 그룹에 acl을 추가할 수 있습니다. 특정 타입의 모든 리소스에 acl을 추가할 수 있습니다. 예를 들어 "Principal User:Peter는 IP 198.51.200.0에서 어떤 Topic에든 produce할 수 있다"는 acl을 추가하려면 와일드카드 리소스 '*'를 다음과 같이 사용할 수 있습니다.
$ bin/kafka-acls.sh --bootstrap-server localhost:9092 --add --allow-principal User:Peter --allow-host 198.51.200.1 --producer --topic '*'
프리픽스 리소스 패턴에 acl을 추가할 수 있습니다. 예를 들어 "Principal User:Jane은 어떤 호스트에서든 이름이 'Test-'로 시작하는 어떤 Topic에 produce할 수 있다"는 acl을 추가하려면 다음 옵션으로 CLI를 실행하면 됩니다.
$ bin/kafka-acls.sh --bootstrap-server localhost:9092 --add --allow-principal User:Jane --producer --topic Test- --resource-pattern-type prefixed
참고: --resource-pattern-type의 기본값은 'literal'이며, 이는 정확히 같은 이름의 리소스에만 영향을 주거나, 와일드카드 리소스 이름 '*'의 경우 임의의 이름을 가진 리소스에 영향을 줍니다.
$ bin/kafka-acls.sh --bootstrap-server localhost:9092 --remove --allow-principal User:Bob --allow-principal User:Alice --allow-host 198.51.100.0 --allow-host 198.51.100.1 --operation Read --operation Write --topic Test-topic
- ACL 제거: acl 제거도 거의 동일합니다. 유일한 차이는
--add옵션 대신--remove옵션을 지정해야 한다는 것입니다. 위 첫 예에서 추가한 acl을 제거하려면 다음 옵션으로 CLI를 실행하면 됩니다.
위에서 프리픽스 리소스 패턴에 추가한 acl을 제거하려면 다음 옵션으로 CLI를 실행하면 됩니다.
$ bin/kafka-acls.sh --bootstrap-server localhost:9092 --remove --allow-principal User:Jane --producer --topic Test- --resource-pattern-type Prefixed
$ bin/kafka-acls.sh --bootstrap-server localhost:9092 --list --topic Test-topic
- ACL 나열: 리소스와 함께
--list옵션을 지정해 어떤 리소스든 acl을 나열할 수 있습니다. literal 리소스 패턴 Test-topic의 모든 acl을 나열하려면 다음 옵션으로 CLI를 실행하면 됩니다.
하지만 이것은 이 정확한 리소스 패턴에 추가된 acl만 반환합니다. 토픽 접근에 영향을 주는 다른 acl도 존재할 수 있습니다. 예: 토픽 와일드카드 '*'의 acl, 프리픽스 리소스 패턴의 acl. 와일드카드 리소스 패턴의 acl은 명시적으로 조회할 수 있습니다.
$ bin/kafka-acls.sh --bootstrap-server localhost:9092 --list --topic '*'
하지만 Test-topic과 일치하는 프리픽스 리소스 패턴의 acl을 명시적으로 조회하는 것은, 그런 패턴의 이름을 모를 수 있으므로 반드시 가능하지는 않습니다. '--resource-pattern-type match'를 사용해 Test-topic에 영향을 주는 모든 acl을 나열할 수 있습니다.
> bin/kafka-acls.sh --bootstrap-server localhost:9092 --list --topic Test-topic --resource-pattern-type match
이것은 일치하는 모든 literal, 와일드카드, 프리픽스 리소스 패턴의 acl을 나열합니다.
$ bin/kafka-acls.sh --bootstrap-server localhost:9092 --add --allow-principal User:Bob --producer --topic Test-topic
- 프로듀서/컨슈머로 principal 추가 또는 제거: acl 관리의 가장 흔한 사용 사례는 principal을 프로듀서·컨슈머로 추가/제거하는 것이므로 이 경우를 처리하는 편의 옵션을 추가했습니다. User:Bob을 Test-topic의 프로듀서로 추가하려면 다음 명령을 실행할 수 있습니다.
마찬가지로 Alice를 컨슈머 그룹 Group-1과 함께 Test-topic의 컨슈머로 추가하려면 --consumer 옵션을 전달하기만 하면 됩니다.
$ bin/kafka-acls.sh --bootstrap-server localhost:9092 --add --allow-principal User:Bob --consumer --topic Test-topic --group Group-1
참고: consumer 옵션에는 컨슈머 그룹도 지정해야 합니다. principal을 프로듀서 또는 컨슈머 역할에서 제거하려면 --remove 옵션을 전달하기만 하면 됩니다.
인가 기본 요소 (Authorization Primitives)
프로토콜 호출은 보통 Kafka의 특정 리소스에 대해 어떤 작업을 수행합니다. 효과적인 보호를 설정하려면 작업과 리소스를 알아야 합니다. 이 섹션에서는 이러한 작업과 리소스를 나열한 다음, 이들을 프로토콜과 조합해 유효한 시나리오를 확인합니다.
Kafka의 작업 (Operations in Kafka)
권한을 구축하는 데 사용할 수 있는 몇 가지 작업 기본 요소가 있습니다. 이들은 특정 리소스와 연결되어 주어진 사용자의 특정 프로토콜 호출을 허용할 수 있습니다. 이들은 다음과 같습니다.
- Read
- Write
- Create
- Delete
- Alter
- Describe
- ClusterAction
- DescribeConfigs
- AlterConfigs
- IdempotentWrite
- CreateTokens
- DescribeTokens
- All
Kafka의 리소스 (Resources in Kafka)
위 작업들은 아래에 설명된 특정 리소스에 적용할 수 있습니다.
- Topic: 단순히 토픽을 나타냅니다. 토픽에 대해 작동하는(읽기·쓰기 같은) 모든 프로토콜 호출은 해당 권한이 추가되어야 합니다. 토픽 리소스에 인가 오류가 있으면
TOPIC_AUTHORIZATION_FAILED(오류 코드: 29)가 반환됩니다. - Group: 브로커의 컨슈머 그룹을 나타냅니다. 그룹 가입 같은 컨슈머 그룹과 함께 작동하는 모든 프로토콜 호출은 그 그룹에 대한 권한을 가져야 합니다. 권한이 주어지지 않으면 프로토콜 응답에
GROUP_AUTHORIZATION_FAILED(오류 코드: 30)가 반환됩니다. - Cluster: 이 리소스는 클러스터를 나타냅니다. 제어된 종료 같은 클러스터 전체에 영향을 주는 작업은 Cluster 리소스의 권한으로 보호됩니다. 클러스터 리소스에 인가 문제가 있으면
CLUSTER_AUTHORIZATION_FAILED(오류 코드: 31)가 반환됩니다. - TransactionalId: 커밋 같은 트랜잭션 관련 작업을 나타냅니다. 오류가 발생하면 브로커가
TRANSACTIONAL_ID_AUTHORIZATION_FAILED(오류 코드: 53)를 반환합니다. - DelegationToken: 클러스터의 위임 토큰을 나타냅니다. 위임 토큰 describe 같은 작업은 DelegationToken 리소스의 권한으로 보호될 수 있습니다. 이 객체들은 Kafka에서 다소 특별한 동작이 있으므로 KIP-48과 관련 업스트림 문서인 Authentication using Delegation Tokens를 읽는 것이 권장됩니다.
- User:
CreateToken과DescribeToken작업은 User 리소스에 부여해 다른 사용자를 위한 토큰 create·describe를 허용할 수 있습니다. 더 자세한 정보는 KIP-373에서 찾을 수 있습니다.
프로토콜의 작업과 리소스 (Operations and Resources on Protocols)
아래 표에서는 Kafka API 프로토콜이 실행하는 리소스에 대한 유효한 작업을 나열합니다.
| 프로토콜 (API key) | 작업 | 리소스 | 참고 |
|---|---|---|---|
| PRODUCE (0) | Write | TransactionalId | transactional.id가 설정된 트랜잭션 프로듀서는 이 권한이 필요. |
| PRODUCE (0) | IdempotentWrite | Cluster | 멱등 produce 작업에는 이 권한이 필요. |
| PRODUCE (0) | Write | Topic | 일반 produce 작업에 적용. |
| FETCH (1) | ClusterAction | Cluster | 팔로워는 파티션 데이터를 fetch하려면 Cluster 리소스에 ClusterAction이 있어야 함. |
| FETCH (1) | Read | Topic | 일반 Kafka 컨슈머는 fetch하는 각 파티션에 READ 권한이 필요. |
| LIST_OFFSETS (2) | Describe | Topic | |
| METADATA (3) | Describe | Topic | |
| METADATA (3) | Create | Cluster | 토픽 자동 생성이 활성화되면 브로커 측 API가 Cluster 수준 권한의 존재를 확인. 발견되면 토픽 생성 허용, 아니면 Topic 수준 권한을 순회(다음 참고). |
| METADATA (3) | Create | Topic | 활성화된 경우 토픽 자동 생성을 인가하지만 주어진 사용자에게 클러스터 수준 권한(위)이 없을 때. |
| LEADER_AND_ISR (4) | ClusterAction | Cluster | |
| STOP_REPLICA (5) | ClusterAction | Cluster | |
| UPDATE_METADATA (6) | ClusterAction | Cluster | |
| CONTROLLED_SHUTDOWN (7) | ClusterAction | Cluster | |
| OFFSET_COMMIT (8) | Read | Group | 오프셋은 주어진 그룹과 토픽에도 인가될 때만 커밋될 수 있음(아래 참고). 그룹 접근이 먼저 확인되고 그다음 토픽 접근. |
| OFFSET_COMMIT (8) | Read | Topic | 오프셋 커밋은 소비 과정의 일부이므로 읽기 작업에 대한 권한이 필요. |
| OFFSET_FETCH (9) | Describe | Group | OFFSET_COMMIT과 유사하게, 애플리케이션은 fetch하려면 그룹과 토픽 수준 모두의 권한이 있어야 함. 다만 이 경우 읽기 대신 describe 접근이 필요. 그룹 접근 먼저, 그다음 토픽 접근. |
| OFFSET_FETCH (9) | Describe | Topic | |
| FIND_COORDINATOR (10) | Describe | Group | FIND_COORDINATOR 요청은 "Group" 타입일 수 있으며, 이 경우 컨슈머 그룹 코디네이터를 찾는 중. 이 권한은 Group 모드를 나타냄. |
| FIND_COORDINATOR (10) | Describe | TransactionalId | 트랜잭션 프로듀서에만 적용되며, 프로듀서가 트랜잭션 코디네이터를 찾으려 할 때 확인. |
| JOIN_GROUP (11) | Read | Group | |
| HEARTBEAT (12) | Read | Group | |
| LEAVE_GROUP (13) | Read | Group | |
| SYNC_GROUP (14) | Read | Group | |
| DESCRIBE_GROUPS (15) | Describe | Group | |
| LIST_GROUPS (16) | Describe | Cluster | 브로커가 list_groups 요청을 인가할 때 먼저 이 클러스터 수준 인가를 확인. 없으면 그룹을 개별적으로 확인. 이 작업은 CLUSTER_AUTHORIZATION_FAILED를 반환하지 않음. |
| LIST_GROUPS (16) | Describe | Group | 어떤 그룹도 인가되지 않으면 오류 대신 빈 응답이 보내짐. 이 작업은 CLUSTER_AUTHORIZATION_FAILED를 반환하지 않음. 2.1 릴리스부터 적용. |
| SASL_HANDSHAKE (17) | SASL 핸드셰이크는 인증 과정의 일부이므로 여기에는 어떤 인가도 적용할 수 없음. | ||
| API_VERSIONS (18) | API_VERSIONS 요청은 Kafka 프로토콜 핸드셰이크의 일부이며 연결 시, 어떤 인증 전에 발생. 따라서 이를 인가로 제어할 수 없음. | ||
| CREATE_TOPICS (19) | Create | Cluster | 클러스터 수준 인가가 없으면 CLUSTER_AUTHORIZATION_FAILED를 반환하지 않고 바로 아래의 토픽 수준으로 폴백. 거기서 문제가 있으면 오류 발생. |
| CREATE_TOPICS (19) | Create | Topic | 2.0 릴리스부터 적용. |
| DELETE_TOPICS (20) | Delete | Topic | |
| DELETE_RECORDS (21) | Delete | Topic | |
| INIT_PRODUCER_ID (22) | Write | TransactionalId | |
| INIT_PRODUCER_ID (22) | IdempotentWrite | Cluster | |
| OFFSET_FOR_LEADER_EPOCH (23) | ClusterAction | Cluster | 이 작업에 클러스터 수준 권한이 없으면 토픽 수준을 확인. |
| OFFSET_FOR_LEADER_EPOCH (23) | Describe | Topic | 2.1 릴리스부터 적용. |
| ADD_PARTITIONS_TO_TXN (24) | Write | TransactionalId | 이 API는 트랜잭션 요청에만 적용. 먼저 TransactionalId 리소스에 Write 작업을 확인한 다음, 주제의 Topic을 확인(아래). |
| ADD_PARTITIONS_TO_TXN (24) | Write | Topic | |
| ADD_OFFSETS_TO_TXN (25) | Write | TransactionalId | ADD_PARTITIONS_TO_TXN과 유사하게 트랜잭션 요청에만 적용. 먼저 TransactionalId 리소스에 Write 작업을 확인한 다음, 주어진 그룹에 Read할 수 있는지 확인(아래). |
| ADD_OFFSETS_TO_TXN (25) | Read | Group | |
| END_TXN (26) | Write | TransactionalId | |
| WRITE_TXN_MARKERS (27) | Alter | Cluster | |
| WRITE_TXN_MARKERS (27) | ClusterAction | Cluster | |
| TXN_OFFSET_COMMIT (28) | Write | TransactionalId | |
| TXN_OFFSET_COMMIT (28) | Read | Group | |
| TXN_OFFSET_COMMIT (28) | Read | Topic | |
| DESCRIBE_ACLS (29) | Describe | Cluster | |
| CREATE_ACLS (30) | Alter | Cluster | |
| DELETE_ACLS (31) | Alter | Cluster | |
| DESCRIBE_CONFIGS (32) | DescribeConfigs | Cluster | 브로커 구성이 요청되면 브로커가 클러스터 수준 권한을 확인. |
| DESCRIBE_CONFIGS (32) | DescribeConfigs | Topic | 토픽 구성이 요청되면 브로커가 토픽 수준 권한을 확인. |
| ALTER_CONFIGS (33) | AlterConfigs | Cluster | 브로커 구성이 변경되면 브로커가 클러스터 수준 권한을 확인. |
| ALTER_CONFIGS (33) | AlterConfigs | Topic | 토픽 구성이 변경되면 브로커가 토픽 수준 권한을 확인. |
| ALTER_REPLICA_LOG_DIRS (34) | Alter | Cluster | |
| DESCRIBE_LOG_DIRS (35) | Describe | Cluster | 인가 실패 시 빈 응답이 반환됨. |
| SASL_AUTHENTICATE (36) | SASL_AUTHENTICATE는 인증 과정의 일부이므로 여기에는 어떤 인가도 적용할 수 없음. | ||
| CREATE_PARTITIONS (37) | Alter | Topic | |
| CREATE_DELEGATION_TOKEN (38) | 위임 토큰 생성에는 특별한 규칙이 있음. Authentication using Delegation Tokens 섹션 참고. | ||
| CREATE_DELEGATION_TOKEN (38) | CreateTokens | User | User 리소스에 대한 위임 토큰 생성 허용. |
| RENEW_DELEGATION_TOKEN (39) | 위임 토큰 갱신에는 특별한 규칙이 있음. 참고. | ||
| EXPIRE_DELEGATION_TOKEN (40) | 위임 토큰 만료에는 특별한 규칙이 있음. 참고. | ||
| DESCRIBE_DELEGATION_TOKEN (41) | Describe | DelegationToken | 위임 토큰 describe에는 특별한 규칙이 있음. 참고. |
| DESCRIBE_DELEGATION_TOKEN (41) | DescribeTokens | User | User 리소스의 위임 토큰 describe 허용. |
| DELETE_GROUPS (42) | Delete | Group | |
| ELECT_PREFERRED_LEADERS (43) | ClusterAction | Cluster | |
| INCREMENTAL_ALTER_CONFIGS (44) | AlterConfigs | Cluster | 브로커 구성이 변경되면 브로커가 클러스터 수준 권한을 확인. |
| INCREMENTAL_ALTER_CONFIGS (44) | AlterConfigs | Topic | 토픽 구성이 변경되면 브로커가 토픽 수준 권한을 확인. |
| ALTER_PARTITION_REASSIGNMENTS (45) | Alter | Cluster | |
| LIST_PARTITION_REASSIGNMENTS (46) | Describe | Cluster | |
| OFFSET_DELETE (47) | Delete | Group | |
| OFFSET_DELETE (47) | Read | Topic | |
| DESCRIBE_CLIENT_QUOTAS (48) | DescribeConfigs | Cluster | |
| ALTER_CLIENT_QUOTAS (49) | AlterConfigs | Cluster | |
| DESCRIBE_USER_SCRAM_CREDENTIALS (50) | Describe | Cluster | |
| ALTER_USER_SCRAM_CREDENTIALS (51) | Alter | Cluster | |
| VOTE (52) | ClusterAction | Cluster | |
| BEGIN_QUORUM_EPOCH (53) | ClusterAction | Cluster | |
| END_QUORUM_EPOCH (54) | ClusterAction | Cluster | |
| DESCRIBE_QUORUM (55) | Describe | Cluster | |
| ALTER_PARTITION (56) | ClusterAction | Cluster | |
| UPDATE_FEATURES (57) | Alter | Cluster | |
| ENVELOPE (58) | ClusterAction | Cluster | |
| FETCH_SNAPSHOT (59) | ClusterAction | Cluster | |
| DESCRIBE_CLUSTER (60) | Describe | Cluster | |
| DESCRIBE_PRODUCERS (61) | Read | Topic | |
| BROKER_REGISTRATION (62) | ClusterAction | Cluster | |
| BROKER_HEARTBEAT (63) | ClusterAction | Cluster | |
| UNREGISTER_BROKER (64) | Alter | Cluster | |
| DESCRIBE_TRANSACTIONS (65) | Describe | TransactionalId | |
| LIST_TRANSACTIONS (66) | Describe | TransactionalId | |
| ALLOCATE_PRODUCER_IDS (67) | ClusterAction | Cluster | |
| CONSUMER_GROUP_HEARTBEAT (68) | Read | Group | |
| CONSUMER_GROUP_DESCRIBE (69) | Read | Group | |
| CONTROLLER_REGISTRATION (70) | ClusterAction | Cluster | |
| GET_TELEMETRY_SUBSCRIPTIONS (71) | 이 요청에 대해서는 인가 검사가 수행되지 않음. | ||
| PUSH_TELEMETRY (72) | 이 요청에 대해서는 인가 검사가 수행되지 않음. | ||
| ASSIGN_REPLICAS_TO_DIRS (73) | ClusterAction | Cluster | |
| LIST_CONFIG_RESOURCES (74) | DescribeConfigs | Cluster | |
| DESCRIBE_TOPIC_PARTITIONS (75) | Describe | Topic | |
| SHARE_GROUP_HEARTBEAT (76) | Read | Group | |
| SHARE_GROUP_DESCRIBE (77) | Describe | Group | |
| SHARE_FETCH (78) | Read | Group | |
| SHARE_FETCH (78) | Read | Topic | |
| SHARE_ACKNOWLEDGE (79) | Read | Group | |
| SHARE_ACKNOWLEDGE (79) | Read | Topic | |
| INITIALIZE_SHARE_GROUP_STATE (83) | ClusterAction | Cluster | |
| READ_SHARE_GROUP_STATE (84) | ClusterAction | Cluster | |
| WRITE_SHARE_GROUP_STATE (85) | ClusterAction | Cluster | |
| DELETE_SHARE_GROUP_STATE (86) | ClusterAction | Cluster | |
| READ_SHARE_GROUP_STATE_SUMMARY (87) | ClusterAction | Cluster | |
| STREAMS_GROUP_HEARTBEAT (88) | Read | Group | |
| STREAMS_GROUP_HEARTBEAT (88) | Describe | Topic | 그룹 토폴로지에 사용된 모든 소스 토픽과 내부 토픽에 필요. |
| STREAMS_GROUP_HEARTBEAT (88) | Create | Topic | 브로커가 내부 토픽을 자동 생성하도록 모든 내부 토픽에 필요. 내부 토픽이 존재하면 필요 없음. |
| STREAMS_GROUP_DESCRIBE (89) | Describe | Group | |
| STREAMS_GROUP_DESCRIBE (89) | Describe | Topic | 그룹 토폴로지에 사용된 모든 소스 토픽과 내부 토픽에 필요. |
| DESCRIBE_SHARE_GROUP_OFFSETS (90) | Describe | Group | 공유 그룹의 파티션 오프셋 정보를 describe하려면 앱이 그룹과 토픽에 권한이 있어야 함. 그룹 접근 먼저, 그다음 토픽 접근. |
| DESCRIBE_SHARE_GROUP_OFFSETS (90) | Describe | Topic | |
| ALTER_SHARE_GROUP_OFFSETS (91) | Read | Group | 공유 그룹의 파티션 오프셋 정보를 변경하려면 앱이 그룹과 토픽에 권한이 있어야 함. 그룹 먼저, 그다음 토픽. |
| ALTER_SHARE_GROUP_OFFSETS (91) | Read | Topic | |
| DELETE_SHARE_GROUP_OFFSETS (92) | Delete | Group | 공유 그룹의 토픽 오프셋 정보를 삭제하려면 앱이 그룹과 토픽에 권한이 있어야 함. 그룹 먼저, 그다음 토픽. |
| DELETE_SHARE_GROUP_OFFSETS (92) | Read | Topic |
더 알아보기 (Learn more)
- ACL이 없으면 기본적으로 슈퍼 유저 외에는 접근이 제한돼요.
allow.everyone.if.no.acl.found=true로 바꿀 수 있어요. - 프로듀서·컨슈머 편의 옵션(
--producer/--consumer)으로 흔한 ACL을 빠르게 추가할 수 있어요. --resource-pattern-type match로 토픽에 영향을 주는 모든 literal·와일드카드·프리픽스 ACL을 나열할 수 있어요.- 인증 방식은 SASL을 이용한 인증과 SSL을 이용한 암호화와 인증 문서를 참고하세요.