15.5. OAuth 2.0 토큰 기반 권한 부여 사용


토큰 기반 인증에 Red Hat Single Sign-On과 함께 OAuth 2.0을 사용하는 경우 Red Hat Single Sign-On을 사용하여 Kafka 브로커에 대한 클라이언트 액세스를 제한하도록 권한 부여 규칙을 구성할 수도 있습니다. 인증은 사용자의 ID를 설정합니다. 권한 부여는 해당 사용자의 액세스 수준을 결정합니다.

AMQ Streams는 Red Hat Single Sign-On 인증 서비스를 통해 OAuth 2.0 토큰 기반 권한 사용을 지원하므로 보안 정책과 권한을 중앙에서 관리할 수 있습니다.

Red Hat Single Sign-On에 정의된 보안 정책 및 권한은 Kafka 브로커의 리소스에 대한 액세스 권한을 부여하는 데 사용됩니다. 사용자와 클라이언트는 Kafka 브로커에서 특정 작업을 수행하기 위해 액세스를 허용하는 정책과 일치합니다.

Kafka는 기본적으로 모든 사용자에게 브로커에 대한 전체 액세스를 허용하며 AclAuthorizerStandardAuthorizer 플러그인도 제공하여 ACL(Access Control Lists)을 기반으로 권한 부여를 구성합니다. 이러한 플러그인에서 관리하는 ACL 규칙은 사용자 이름을 기반으로 리소스에 대한 액세스 권한을 부여하거나 거부하는 데 사용되며 이러한 규칙은 Kafka 클러스터 자체에 저장됩니다. 그러나 Red Hat Single Sign-On을 사용한 OAuth 2.0 토큰 기반 권한 부여는 Kafka 브로커에 대한 액세스 제어를 구현하는 방법에 대한 유연성을 훨씬 높여 줍니다. 또한 OAuth 2.0 권한 부여 및 ACL을 사용하도록 Kafka 브로커를 구성할 수 있습니다.

15.5.1. OAuth 2.0 인증 메커니즘

AMQ Streams의 OAuth 2.0 인증에서는 Red Hat Single Sign-On 서버 권한 부여 REST 끝점을 사용하여 특정 사용자에게 정의된 보안 정책을 적용하고 해당 사용자의 다양한 리소스에 부여된 권한 목록을 제공하여 Red Hat Single Sign-On으로 토큰 기반 인증을 확장합니다. 정책은 역할과 그룹을 사용하여 사용자와 권한을 일치시킵니다. OAuth 2.0 권한 부여는 Red Hat Single Sign-On 인증 서비스에서 사용자에 대한 수신된 권한 목록을 기반으로 권한을 로컬로 적용합니다.

15.5.1.1. Kafka 브로커 사용자 정의 승인

Red Hat Single Sign-On 승인자 (KeycloakAuthorizer)는 AMQ Streams와 함께 제공됩니다. Red Hat Single Sign-On에서 제공하는 권한 부여 서비스에 Red Hat Single Sign-On REST 엔드포인트를 사용하려면 Kafka 브로커에서 사용자 지정 승인자를 구성합니다.

인증자는 필요에 따라 권한 부여 서버에서 부여된 권한 목록을 가져와서 Kafka 브로커에 로컬로 권한 부여를 적용하여 각 클라이언트 요청에 대해 신속하게 권한 부여 결정을 내립니다.

15.5.2. OAuth 2.0 권한 부여 지원 구성

다음 절차에서는 Red Hat Single Sign-On 인증 서비스를 사용하여 OAuth 2.0 인증을 사용하도록 Kafka 브로커를 구성하는 방법을 설명합니다.

사전 준비 사항

필요한 액세스 또는 특정 사용자에 대해 제한하려는 경우를 고려하십시오. Red Hat Single Sign-On 그룹,역할,클라이언트사용자를 결합하여 Red Hat Single Sign-On에서 액세스를 구성할 수 있습니다.

일반적으로 그룹은 조직 부서 또는 지리적 위치를 기반으로 사용자와 일치시키는 데 사용됩니다. 및 역할은 해당 기능을 기반으로 사용자와 일치시키는 데 사용됩니다.

Red Hat Single Sign-On을 사용하면 사용자와 그룹을 LDAP에 저장할 수 있지만 클라이언트와 역할은 이러한 방식으로 저장할 수 없습니다. 사용자 데이터에 대한 스토리지 및 액세스는 권한 부여 정책 구성 방법의 요소가 될 수 있습니다.

참고

Super 사용자는 Kafka 브로커에서 구현된 권한 부여에 관계없이 항상 Kafka 브로커에 대한 무제한 액세스 권한을 갖습니다.

사전 요구 사항

  • AMQ Streams는 토큰 기반 인증을 위해 Red Hat Single Sign-On과 함께 OAuth 2.0을 사용하도록 구성해야 합니다. 권한 부여를 설정할 때 동일한 Red Hat Single Sign-On 서버 끝점을 사용합니다.
  • 재인증을 활성화하려면 maxSecondsWithoutReauthentication 옵션을 사용하여 OAuth 2.0 인증을 구성해야 합니다.

프로세스

  1. Red Hat Single Sign-On 관리 콘솔에 액세스하거나 Red Hat Single Sign-On 관리 CLI를 사용하여 OAuth 2.0 인증을 설정할 때 생성한 Kafka 브로커 클라이언트에 대한 인증 서비스를 활성화합니다.
  2. 인증 서비스를 사용하여 클라이언트에 대한 리소스, 권한 부여 범위, 정책 및 권한을 정의합니다.
  3. 역할 및 그룹을 할당하여 사용자 및 클라이언트에 권한을 바인딩합니다.
  4. 편집기에서 Kafka 리소스의 Kafka 브로커 구성(Kafka.spec.kafka)을 업데이트하여 Red Hat Single Sign-On 권한을 사용하도록 Kafka 브로커를 구성합니다.

    oc edit kafka my-cluster
    Copy to Clipboard Toggle word wrap
  5. keycloak 인증을 사용하고 권한 부여 서버 및 권한 부여 서비스에 액세스할 수 있도록 Kafka 브로커 kafka 구성을 구성합니다.

    예를 들면 다음과 같습니다.

    apiVersion: kafka.strimzi.io/v1beta2
    kind: Kafka
    metadata:
      name: my-cluster
    spec:
      kafka:
        # ...
        authorization:
          type: keycloak 
    1
    
          tokenEndpointUri: <https://<auth-server-address>/auth/realms/external/protocol/openid-connect/token> 
    2
    
          clientId: kafka 
    3
    
          delegateToKafkaAcls: false 
    4
    
          disableTlsHostnameVerification: false 
    5
    
          superUsers: 
    6
    
          - CN=fred
          - sam
          - CN=edward
          tlsTrustedCertificates: 
    7
    
          - secretName: oauth-server-cert
            certificate: ca.crt
          grantsRefreshPeriodSeconds: 60 
    8
    
          grantsRefreshPoolSize: 5 
    9
    
          grantsMaxIdleSeconds: 300 
    10
    
          grantsGcPeriodSeconds: 300 
    11
    
          grantsAlwaysLatest: false 
    12
    
          connectTimeoutSeconds: 60 
    13
    
          readTimeoutSeconds: 60 
    14
    
          httpRetries: 2 
    15
    
          enableMetrics: false 
    16
    
          includeAcceptHeader: false 
    17
    
        #...
    Copy to Clipboard Toggle word wrap
    1
    유형 keycloak 에서는 Red Hat Single Sign-On 권한 부여를 활성화합니다.
    2
    Red Hat Single Sign-On 토큰 끝점의 URI입니다. 프로덕션의 경우 항상 https:// urls를 사용합니다. 토큰 기반 oauth 인증을 구성할 때 로컬 JWT 검증을 위한 URI로 jwksEndpointUri 를 지정합니다. tokenEndpointUri URI의 호스트 이름은 동일해야 합니다.
    3
    권한 부여 서비스가 활성화된 Red Hat Single Sign-On의 OAuth 2.0 클라이언트 정의의 클라이언트 ID입니다. 일반적으로 kafka 는 ID로 사용됩니다.
    4
    (선택 사항) Red Hat Single Sign-On 권한 부여 정책에서 액세스가 거부되는 경우 Kafka AclAuthorizerStandardAuthorizer 에 대한 권한을 위임합니다. 기본값은 false 입니다.
    5
    (선택 사항) TLS 호스트 이름 확인을 비활성화합니다. 기본값은 false 입니다.
    6
    (선택 사항) 슈퍼유저 지정.
    7
    (선택 사항) 권한 부여 서버에 대한 TLS 연결에 대한 신뢰할 수 있는 인증서입니다.
    8
    (선택 사항) 두 개의 연속 부여 새로 고침 실행 사이의 시간입니다. 이는 Red Hat Single Sign-On에서 사용자의 권한 변경을 감지할 수 있는 활성 세션의 최대 시간입니다. 기본값은 60입니다.
    9
    (선택 사항) 활성 세션에 대한 권한 부여를 새로 고치는 데 사용할 스레드 수입니다. 기본값은 5입니다.
    10
    (선택 사항) 캐시의 유휴 부여를 제거할 수 있는 시간(초)입니다. 기본값은 300입니다.
    11
    (선택 사항) 캐시에서 오래된 권한을 정리하는 작업의 연속 실행 사이의 시간(초)입니다. 기본값은 300입니다.
    12
    (선택 사항) 새 세션에 대한 최신 권한을 가져올지 여부를 제어합니다. 활성화하면 Red Hat Single Sign-On에서 권한을 검색하고 사용자에게 캐시됩니다. 기본값은 false입니다.
    13
    (선택 사항) Red Hat Single Sign-On 토큰 끝점에 연결할 때 연결 시간(초)입니다. 기본값은 60입니다.
    14
    (선택 사항) Red Hat Single Sign-On 토큰 끝점에 연결할 때 읽기 제한 시간(초)입니다. 기본값은 60입니다.
    15
    (선택 사항) 권한 부여 서버에 실패한 HTTP 요청을 일시 중지하지 않고 재시도할 최대 횟수입니다. 기본값은 0 입니다. 즉, 재시도가 수행되지 않습니다. 이 옵션을 효과적으로 사용하려면 connectTimeoutSecondsreadTimeoutSeconds 옵션의 시간 초과 시간을 줄이는 것이 좋습니다. 그러나 재시도하면 현재 작업자 스레드를 다른 요청에 사용할 수 없게 될 수 있으며 요청이 너무 많으면 Kafka 브로커가 응답하지 않을 수 있습니다.
    16
    (선택 사항) OAuth 메트릭을 활성화하거나 비활성화합니다. 기본값은 false입니다.
    17
    (선택 사항) 일부 인증 서버는 Accept: application/json 헤더를 보내는 클라이언트에 문제가 있습니다. includeAcceptHeader: false 를 설정하면 헤더가 전송되지 않습니다. 기본값은 true 입니다.
  6. 편집기를 저장하고 종료한 다음 롤링 업데이트가 완료될 때까지 기다립니다.
  7. 로그에서 업데이트를 확인하거나 Pod 상태 전환을 확인하여 업데이트를 확인합니다.

    oc logs -f ${POD_NAME} -c kafka
    oc get pod -w
    Copy to Clipboard Toggle word wrap

    롤링 업데이트는 브로커가 OAuth 2.0 인증을 사용하도록 구성합니다.

  8. Kafka 브로커에 특정 역할이 있는 클라이언트 또는 사용자로 액세스하여 구성된 권한에 액세스하고 필요한 액세스 권한이 있는지 또는 권한이 없는지 확인합니다.

15.5.3. Red Hat Single Sign-On 인증 서비스에서 정책 및 권한 관리

이 섹션에서는 Red Hat Single Sign-On 인증 서비스 및 Kafka에서 사용하는 권한 부여 모델에 대해 설명하고 각 모델에서 중요한 개념을 정의합니다.

Kafka 액세스 권한을 부여하려면 Red Hat Single Sign-On에서 OAuth 클라이언트 사양 을 생성하여 Red Hat Single Sign-On 인증 서비스 오브젝트를 Kafka 리소스에 매핑할 수 있습니다. Kafka 권한은 Red Hat Single Sign-On 인증 서비스 규칙을 사용하여 사용자 계정 또는 서비스 계정에 부여됩니다.

주제 생성 및 나열과 같이 일반적인 Kafka 작업에 필요한 다양한 사용자 권한의 는 다음과 같습니다.

15.5.3.1. Kafka 및 Red Hat Single Sign-On 권한 부여 모델 개요

Kafka 및 Red Hat Single Sign-On 인증 서비스는 다른 권한 부여 모델을 사용합니다.

Kafka 인증 모델

Kafka의 권한 부여 모델에서는 리소스 유형을 사용합니다. Kafka 클라이언트가 브로커에서 작업을 수행할 때 브로커는 구성된 KeycloakAuthorizer 를 사용하여 작업 및 리소스 유형에 따라 클라이언트의 권한을 확인합니다.

Kafka는 5가지 리소스 유형을 사용하여 액세스 권한을 제어합니다. Topic,Group,Cluster,TransactionalId, DelegationToken. 각 리소스 유형에는 사용 가능한 권한 세트가 있습니다.

주제

  • 개발
  • 쓰기
  • 읽기
  • delete
  • describe
  • DescribeConfigs
  • 변경
  • AlterConfigs

그룹

  • 읽기
  • describe
  • delete

Cluster

  • 개발
  • describe
  • 변경
  • DescribeConfigs
  • AlterConfigs
  • IdempotentWrite
  • ClusterAction

TransactionalId

  • describe
  • 쓰기

DelegationToken

  • describe
Red Hat Single Sign-On 인증 서비스 모델

Red Hat Single Sign-On 인증 서비스 모델에는 리소스, 권한 부여범위,정책권한 의 정의 및 부여를 위한 네 가지 개념이 있습니다.

Resources
리소스는 허용된 작업과 리소스를 일치시키는 데 사용되는 리소스 정의 집합입니다. 리소스는 개별 주제일 수 있습니다(예: 동일한 접두사로 시작하는 이름이 있는 모든 주제). 리소스 정의는 사용 가능한 모든 작업 세트를 나타내는 사용 가능한 권한 부여 범위 세트와 연결됩니다. 이러한 작업의 하위 집합만 실제로 허용됩니다.
권한 부여 범위
권한 부여 범위는 특정 리소스 정의에서 사용 가능한 모든 작업 세트입니다. 새 리소스를 정의할 때 모든 범위 집합에서 범위를 추가합니다.
Policies

정책은 계정 목록과 일치하도록 기준을 사용하는 권한 부여 규칙입니다. 정책은 다음과 일치할 수 있습니다.

  • 클라이언트 ID 또는 역할을 기반으로 하는 서비스 계정
  • 사용자 이름, 그룹 또는 역할을 기반으로 하는 사용자 계정 입니다.
권한
권한은 특정 리소스 정의의 권한 부여 범위 하위 집합을 사용자 집합에 부여합니다.

Kafka 권한 부여 모델은 Kafka에 대한 액세스를 제어하는 Red Hat Single Sign-On 역할 및 리소스를 정의하는 데 기반으로 사용됩니다.

사용자 계정 또는 서비스 계정에 Kafka 권한을 부여하려면 먼저 Kafka 브로커의 Red Hat Single Sign-On에서 OAuth 클라이언트 사양 을 생성합니다. 그런 다음 클라이언트에서 Red Hat Single Sign-On 권한 부여 서비스를 지정합니다. 일반적으로 브로커를 나타내는 OAuth 클라이언트의 클라이언트 ID는 kafka 입니다. AMQ Streams와 함께 제공되는 구성 파일의 예kafka 를 OAuth 클라이언트 ID로 사용합니다.

참고

Kafka 클러스터가 여러 개인 경우 모두 단일 OAuth 클라이언트(kafka)를 사용할 수 있습니다. 그러면 권한 부여 규칙을 정의하고 관리할 수 있는 단일 통합 공간이 제공됩니다. 그러나 다른 OAuth 클라이언트 ID(예: my-cluster-kafka 또는 cluster-dev-kafka)를 사용하고 각 클라이언트 구성 내에서 각 클러스터에 대한 권한 부여 규칙을 정의할 수도 있습니다.

kafka 클라이언트 정의에는 Red Hat Single Sign-On 관리 콘솔에서 Authorization Enabled 옵션이 활성화되어 있어야 합니다.

모든 권한은 kafka 클라이언트 범위 내에 있습니다. 다른 OAuth 클라이언트 ID로 구성된 Kafka 클러스터가 있는 경우 각각 동일한 Red Hat Single Sign-On 영역의 일부인 경우에도 별도의 권한 세트가 필요합니다.

Kafka 클라이언트가 OAUTHBEARER 인증을 사용하는 경우 Red Hat Single Sign-On 승인자(KeycloakAuthorizer)는 현재 세션의 액세스 토큰을 사용하여 Red Hat Single Sign-On 서버에서 권한 부여 목록을 검색합니다. 권한을 검색하기 위해 인증자는 Red Hat Single Sign-On 인증 서비스 정책 및 권한을 평가합니다.

Kafka 권한에 대한 권한 부여 범위

초기 Red Hat Single Sign-On 구성은 일반적으로 권한 부여 범위를 업로드하여 각 Kafka 리소스 유형에서 수행할 수 있는 모든 가능한 작업 목록을 생성합니다. 이 단계는 권한을 정의하기 전에 한 번만 수행됩니다. 권한 부여 범위를 업로드하는 대신 수동으로 추가할 수 있습니다.

권한 부여 범위에는 리소스 유형에 관계없이 사용 가능한 모든 Kafka 권한이 포함되어야 합니다.

  • 개발
  • 쓰기
  • 읽기
  • delete
  • describe
  • 변경
  • DescribeConfig
  • AlterConfig
  • ClusterAction
  • IdempotentWrite
참고

권한(예: IdempotentWrite)이 필요하지 않은 경우 권한 부여 범위 목록에서 생략할 수 있습니다. 그러나 해당 권한은 Kafka 리소스에서 대상으로 지정할 수 없습니다.

권한 검사에 대한 리소스 패턴

리소스 패턴은 권한 검사를 수행할 때 대상 리소스와 일치하는 패턴에 사용됩니다. 일반적인 패턴 형식은 RESOURCE-TYPE:PATTERN-NAME 입니다.

리소스 유형은 Kafka 권한 부여 모델을 미러링합니다. 이 패턴은 두 가지 일치 옵션을 허용합니다.

  • 정확한 일치(패턴이 *로 끝나지 않는 경우)
  • 접두사 일치(패턴이 *로 종료되면 )

리소스에 대한 패턴 예

Topic:my-topic
Topic:orders-*
Group:orders-*
Cluster:*
Copy to Clipboard Toggle word wrap

또한 일반 패턴 형식 접두사는 kafka-cluster:CLUSTER-NAME 뒤에 쉼표를 사용할 수 있습니다. 여기서 CLUSTER-NAME 은 Kafka 사용자 정의 리소스의 metadata.name 을 나타냅니다.

클러스터 접두사가 있는 리소스의 패턴 예

kafka-cluster:my-cluster,Topic:*
kafka-cluster:*,Group:b_*
Copy to Clipboard Toggle word wrap

kafka-cluster 접두사가 없는 경우 kafka-cluster:* 로 간주됩니다.

리소스를 정의할 때 리소스와 관련된 가능한 권한 부여 범위 목록과 연결할 수 있습니다. 대상 리소스 유형에 적합한 작업을 설정합니다.

모든 리소스에 권한 부여 범위를 추가할 수 있지만 리소스 유형에서 지원하는 범위만 액세스 제어로 간주됩니다.

액세스 권한 적용을 위한 정책

정책은 하나 이상의 사용자 계정 또는 서비스 계정에 대한 권한을 대상으로 하는 데 사용됩니다. 대상 지정은 다음을 참조할 수 있습니다.

  • 특정 사용자 또는 서비스 계정
  • 영역 역할 또는 클라이언트 역할
  • 사용자 그룹
  • 클라이언트 IP 주소와 일치하는 JavaScript 규칙

정책에는 고유한 이름이 지정되며 여러 리소스에 대한 여러 권한을 대상으로 하는 데 재사용할 수 있습니다.

액세스 권한 부여

세분화된 권한을 사용하여 사용자에게 액세스 권한을 부여하는 정책, 리소스 및 권한 부여 범위를 함께 가져옵니다.

각 권한의 이름은 사용자에게 부여하는 권한을 명확하게 정의해야 합니다. 예를 들어 Dev Team B는 x 로 시작하는 주제에서 읽을 수 있습니다.

15.5.3.3. Kafka 작업에 필요한 권한 예

다음 예제에서는 Kafka에서 일반적인 작업을 수행하는 데 필요한 사용자 권한을 보여줍니다.

주제 생성

주제를 만들려면 특정 주제 또는 Cluster:kafka-cluster 에 대한 Create 권한이 필요합니다.

bin/kafka-topics.sh --create --topic my-topic \
  --bootstrap-server my-cluster-kafka-bootstrap:9092 --command-config=/tmp/config.properties
Copy to Clipboard Toggle word wrap

주제 목록

사용자에게 지정된 항목에 대한 설명 권한이 있는 경우 항목이 나열됩니다.

bin/kafka-topics.sh --list \
  --bootstrap-server my-cluster-kafka-bootstrap:9092 --command-config=/tmp/config.properties
Copy to Clipboard Toggle word wrap

주제 세부 정보 표시

주제의 세부 정보를 표시하려면 주제에 대해 설명하고 DescribeConfigs 권한이 필요합니다.

bin/kafka-topics.sh --describe --topic my-topic \
  --bootstrap-server my-cluster-kafka-bootstrap:9092 --command-config=/tmp/config.properties
Copy to Clipboard Toggle word wrap

항목에 메시지 생성

항목에 대한 메시지를 생성하려면 항목에 대해 설명쓰기 권한이 필요합니다.

주제가 아직 생성되지 않았으며 자동 생성 항목이 활성화되어 있는 경우 주제를 만들 수 있는 권한이 필요합니다.

bin/kafka-console-producer.sh  --topic my-topic \
  --bootstrap-server my-cluster-kafka-bootstrap:9092 --producer.config=/tmp/config.properties
Copy to Clipboard Toggle word wrap

주제의 메시지 사용

주제의 메시지를 사용하려면 주제에서 설명읽기 권한이 필요합니다. 주제에서 사용하는 것은 일반적으로 소비자 그룹에 소비자 오프셋을 저장하는 데 의존하며, 소비자 그룹에 대한 추가 설명읽기 권한이 필요합니다.

일치하려면 두 개의 리소스가 필요합니다. 예를 들면 다음과 같습니다.

Topic:my-topic
Group:my-group-*
Copy to Clipboard Toggle word wrap
bin/kafka-console-consumer.sh --topic my-topic --group my-group-1 --from-beginning \
  --bootstrap-server my-cluster-kafka-bootstrap:9092 --consumer.config /tmp/config.properties
Copy to Clipboard Toggle word wrap

idempotent 생산자를 사용하여 주제로 메시지 생성

주제를 생성하는 권한뿐만 아니라 Cluster:kafka-cluster 리소스에 추가 IdempotentWrite 권한이 필요합니다.

일치하려면 두 개의 리소스가 필요합니다. 예를 들면 다음과 같습니다.

Topic:my-topic
Cluster:kafka-cluster
Copy to Clipboard Toggle word wrap
bin/kafka-console-producer.sh  --topic my-topic \
  --bootstrap-server my-cluster-kafka-bootstrap:9092 --producer.config=/tmp/config.properties --producer-property enable.idempotence=true --request-required-acks -1
Copy to Clipboard Toggle word wrap

소비자 그룹 나열

소비자 그룹을 나열할 때 사용자에게 권한이 있는 그룹 만 반환됩니다. 또는 사용자에게 Cluster:kafka-cluster 에 대한 Describe 권한이 있는 경우 모든 소비자 그룹이 반환됩니다.

bin/kafka-consumer-groups.sh --list \
  --bootstrap-server my-cluster-kafka-bootstrap:9092 --command-config=/tmp/config.properties
Copy to Clipboard Toggle word wrap

소비자 그룹 세부 정보 표시

소비자 그룹의 세부 정보를 표시하려면 그룹 및 그룹과 연결된 항목에 대한 설명이 필요합니다.

bin/kafka-consumer-groups.sh --describe --group my-group-1 \
  --bootstrap-server my-cluster-kafka-bootstrap:9092 --command-config=/tmp/config.properties
Copy to Clipboard Toggle word wrap

주제 구성 변경

주제의 구성을 변경하려면 설명 대체 권한이 필요합니다.

bin/kafka-topics.sh --alter --topic my-topic --partitions 2 \
  --bootstrap-server my-cluster-kafka-bootstrap:9092 --command-config=/tmp/config.properties
Copy to Clipboard Toggle word wrap

Kafka 브로커 구성 표시

kafka-configs.sh 를 사용하여 브로커의 구성을 가져오려면 Cluster:kafka-clusterDescribeConfigs 권한이 필요합니다.

bin/kafka-configs.sh --entity-type brokers --entity-name 0 --describe --all \
  --bootstrap-server my-cluster-kafka-bootstrap:9092 --command-config=/tmp/config.properties
Copy to Clipboard Toggle word wrap

Kafka 브로커 구성 변경

Kafka 브로커 구성을 변경하려면 Cluster:kafka-clusterDescribeConfigAlterConfigs 권한이 필요합니다.

bin/kafka-configs --entity-type brokers --entity-name 0 --alter --add-config log.cleaner.threads=2 \
  --bootstrap-server my-cluster-kafka-bootstrap:9092 --command-config=/tmp/config.properties
Copy to Clipboard Toggle word wrap

주제 삭제

주제를 삭제하려면 설명삭제 권한이 해당 항목에 필요합니다.

bin/kafka-topics.sh --delete --topic my-topic \
  --bootstrap-server my-cluster-kafka-bootstrap:9092 --command-config=/tmp/config.properties
Copy to Clipboard Toggle word wrap

지도 파티션 선택

주제 파티션에 대해 리더 선택을 실행하려면 Cluster:kafka-clusterAlter 권한이 필요합니다.

bin/kafka-leader-election.sh --topic my-topic --partition 0 --election-type PREFERRED  /
  --bootstrap-server my-cluster-kafka-bootstrap:9092 --admin.config /tmp/config.properties
Copy to Clipboard Toggle word wrap

파티션 재할당

파티션 재할당 파일을 생성하려면 관련 항목에 대한 권한이 필요합니다.

bin/kafka-reassign-partitions.sh --topics-to-move-json-file /tmp/topics-to-move.json --broker-list "0,1" --generate \
  --bootstrap-server my-cluster-kafka-bootstrap:9092 --command-config /tmp/config.properties > /tmp/partition-reassignment.json
Copy to Clipboard Toggle word wrap

파티션 재할당을 실행하려면 Cluster:kafka-cluster대해 설명합니다. 또한 관련 항목에 대한 사용 권한이 필요합니다. Describe permissions are required on the topics involved.

bin/kafka-reassign-partitions.sh --reassignment-json-file /tmp/partition-reassignment.json --execute \
  --bootstrap-server my-cluster-kafka-bootstrap:9092 --command-config /tmp/config.properties
Copy to Clipboard Toggle word wrap

파티션 재할당을 확인하려면 Cluster:kafka-cluster 및 관련된 각 항목에 대해 파티션 재할당, AlterConfigs 권한이 필요합니다.

bin/kafka-reassign-partitions.sh --reassignment-json-file /tmp/partition-reassignment.json --verify \
  --bootstrap-server my-cluster-kafka-bootstrap:9092 --command-config /tmp/config.properties
Copy to Clipboard Toggle word wrap

15.5.4. Red Hat Single Sign-On 인증 서비스 사용

이 예에서는 Red Hat Single Sign-On 인증 서비스와 keycloak 권한을 사용하는 방법을 설명합니다. Red Hat Single Sign-On 권한 부여 서비스를 사용하여 Kafka 클라이언트에 대한 액세스 제한을 적용합니다. Red Hat Single Sign-On 인증 서비스는 권한 부여 범위, 정책 및 권한을 사용하여 리소스에 액세스 제어를 정의하고 적용합니다.

Red Hat Single Sign-On 권한 부여 서비스 REST 끝점은 인증된 사용자를 위한 리소스에 대한 권한 부여 목록을 제공합니다. 권한 부여 목록은 Kafka 클라이언트가 인증된 세션을 설정한 후 첫 번째 작업으로 Red Hat Single Sign-On 서버에서 가져옵니다. 해당 권한 부여에 대한 변경 사항이 감지되도록 백그라운드에서 목록이 새로 고쳐집니다. 부여는 각 사용자 세션에 대해 Kafka 브로커에 로컬로 캐시되고 적용되어 빠른 권한 부여 결정을 제공합니다.

AMQ Streams는 구성 파일 예제 를 제공합니다. 여기에는 Red Hat Single Sign-On을 설정하기 위한 다음 예제 파일이 포함됩니다.

kafka-ephemeral-oauth-single-keycloak-authz.yaml
Red Hat Single Sign-On을 사용하여 OAuth 2.0 토큰 기반 권한 부여용으로 구성된 Kafka 사용자 정의 리소스의 예입니다. 사용자 정의 리소스를 사용하여 keycloak 권한 부여 및 토큰 기반 oauth 인증을 사용하는 Kafka 클러스터를 배포할 수 있습니다.
kafka-authz-realm.json
샘플 그룹, 사용자, 역할 및 클라이언트로 구성된 Red Hat Single Sign-On 영역의 예입니다. 이 영역을 Red Hat Single Sign-On 인스턴스로 가져와 Kafka에 액세스할 수 있는 세분화된 권한을 설정할 수 있습니다.

Red Hat Single Sign-On에서 예제를 시도하려면 이러한 파일을 사용하여 표시된 순서대로 이 섹션에 설명된 작업을 수행합니다.

인증

토큰 기반 oauth 인증을 구성할 때 로컬 JWT 검증을 위한 URI로 jwksEndpointUri 를 지정합니다. keycloak 권한을 구성할 때 tokenEndpointUri 를 Red Hat Single Sign-On 토큰 끝점의 URI로 지정합니다. 두 URI의 호스트 이름은 동일해야 합니다.

그룹 또는 역할 정책을 사용하여 대상 권한

Red Hat Single Sign-On에서 서비스 계정이 활성화된 기밀 클라이언트는 클라이언트 ID와 시크릿을 사용하여 자체 이름으로 서버에 인증할 수 있습니다. 이는 일반적으로 특정 사용자의 에이전트(예: 웹 사이트)가 아닌 자체 이름으로 작동하는 마이크로 서비스에 편리합니다. 서비스 계정에는 일반 사용자와 같이 할당된 역할이 있을 수 있습니다. 그러나 그룹에는 할당될 수 없습니다. 결과적으로 서비스 계정을 사용하여 마이크로 서비스에 대한 권한을 대상으로 지정하려면 그룹 정책을 사용할 수 없으며 대신 역할 정책을 사용해야 합니다. 반대로 사용자 이름과 암호를 사용한 인증이 필요한 일반 사용자 계정으로만 특정 권한을 제한하려면 역할 정책이 아닌 그룹 정책을 사용하는 부작용으로 이를 수행할 수 있습니다. 이 예제에서는 ClusterManager 로 시작하는 권한에 사용됩니다. 클러스터 관리 수행은 일반적으로 CLI 툴을 사용하여 대화식으로 수행됩니다. 결과 액세스 토큰을 사용하여 Kafka 브로커에 인증하기 전에 사용자가 로그인해야 합니다. 이 경우 액세스 토큰은 클라이언트 애플리케이션이 아닌 특정 사용자를 나타냅니다.

15.5.4.1. Red Hat Single Sign-On 관리 콘솔에 액세스

Red Hat Single Sign-On을 설정한 다음 관리 콘솔에 연결하고 사전 구성된 영역을 추가합니다. 예제 kafka-authz-realm.json 파일을 사용하여 영역을 가져옵니다. Admin Console에서 영역에 대해 정의된 권한 부여 규칙을 확인할 수 있습니다. 이 규칙은 예제 Red Hat Single Sign-On 영역을 사용하도록 구성된 Kafka 클러스터의 리소스에 대한 액세스 권한을 부여합니다.

사전 요구 사항

  • 실행 중인 OpenShift 클러스터입니다.
  • 사전 구성된 영역이 포함된 AMQ Streams 예제/security/keycloak-authorization/kafka-authz-realm.json 파일입니다.

프로세스

  1. Red Hat Single Sign-On 설명서의 서버 설치 및 구성에 설명된 대로 Red Hat Single Sign-On Operator를 사용하여 Red Hat Single Sign-On 서버 를 설치합니다.
  2. Red Hat Single Sign-On 인스턴스가 실행될 때까지 기다립니다.
  3. 관리 콘솔에 액세스할 수 있도록 외부 호스트 이름을 가져옵니다.

    NS=sso
    oc get ingress keycloak -n $NS
    Copy to Clipboard Toggle word wrap

    이 예에서는 Red Hat Single Sign-On 서버가 sso 네임스페이스에서 실행되고 있다고 가정합니다.

  4. admin 사용자의 암호를 가져옵니다.

    oc get -n $NS pod keycloak-0 -o yaml | less
    Copy to Clipboard Toggle word wrap

    암호는 시크릿으로 저장되므로 Red Hat Single Sign-On 인스턴스에 대한 구성 YAML 파일을 가져와 시크릿 이름을 확인합니다(secretKeyRef.name).

  5. 시크릿 이름을 사용하여 일반 텍스트 암호를 가져옵니다.

    SECRET_NAME=credential-keycloak
    oc get -n $NS secret $SECRET_NAME -o yaml | grep PASSWORD | awk '{print $2}' | base64 -D
    Copy to Clipboard Toggle word wrap

    이 예에서는 시크릿 이름이 credential-keycloak 이라고 가정합니다.

  6. 사용자 이름 admin 및 가져온 암호를 사용하여 관리 콘솔에 로그인합니다.

    https://HOSTNAME 을 사용하여 Kubernetes Ingress 에 액세스합니다.

    이제 관리 콘솔을 사용하여 Red Hat Single Sign-On에 예제 영역을 업로드할 수 있습니다.

  7. Add Cryostat 를 클릭하여 예제 영역을 가져옵니다.
  8. examples/security/keycloak-authorization/kafka-authz-realm.json 파일을 추가한 다음 만들기 를 클릭합니다.

    이제 관리 콘솔에서 현재 영역으로 kafka-authz 가 있습니다.

    기본 보기에 마스터 영역이 표시됩니다.

  9. Red Hat Single Sign-On 관리 콘솔에서 클라이언트 > kafka > 인증 > 설정으로 이동하여 의사 결정 전략이 유효한 것으로 설정되어 있는지 확인합니다.

    확인 정책은 클라이언트가 Kafka 클러스터에 액세스하려면 하나 이상의 정책을 충족해야 함을 의미합니다.

  10. Red Hat Single Sign-On 관리 콘솔에서 그룹,사용자,역할클라이언트로 이동하여 영역 구성을 확인합니다.

    그룹
    그룹은 사용자 그룹을 생성하고 사용자 권한을 설정하는 데 사용됩니다. 그룹은 이름이 할당된 사용자 집합입니다. 사용자를 지리적, 조직 또는 부서 단위로 구분하는 데 사용됩니다. 그룹을 LDAP ID 공급자에 연결할 수 있습니다. 예를 들어 Kafka 리소스에 대한 권한을 부여하기 위해 사용자 지정 LDAP 서버 admin 사용자 인터페이스를 통해 사용자에게 그룹의 멤버를 만들 수 있습니다.
    사용자
    사용자는 사용자를 생성하는 데 사용됩니다. 이 예제에서는 alicebob 이 정의됩니다. AliceClusterManager 그룹의 멤버이며 bobClusterManager-my-cluster 그룹의 멤버입니다. 사용자는 LDAP ID 공급자에 저장할 수 있습니다.
    역할
    역할은 사용자 또는 클라이언트가 특정 권한이 있는 것으로 표시합니다. 역할은 그룹과 유사한 개념입니다. 일반적으로 사용자를 조직 역할로 태그 하고 필수 권한이 있는 데 사용됩니다. 역할은 LDAP ID 공급자에 저장할 수 없습니다. LDAP가 요구 사항인 경우 대신 그룹을 사용하고 Red Hat Single Sign-On 역할을 그룹에 추가하여 사용자가 그룹에 할당되면 해당 역할도 가져올 수 있습니다.
    클라이언트

    클라이언트에 는 특정 구성이 있을 수 있습니다. 이 예제에서는 kafka , kafka -cli,team-a-client, team-b-client 클라이언트가 구성됩니다.

    • kafka 클라이언트는 Kafka 브로커가 액세스 토큰 검증에 필요한 OAuth 2.0 통신을 수행하는 데 사용됩니다. 이 클라이언트에는 Kafka 브로커에서 권한 부여를 수행하는 데 사용되는 권한 부여 서비스 리소스 정의, 정책 및 권한 부여 범위도 포함되어 있습니다. 권한 부여 구성은 권한 부여 탭의 kafka 클라이언트에 정의되어 있으며, 설정 탭에서 인증 활성화 가 켜지면 표시됩니다.
    • kafka-cli 클라이언트는 액세스 토큰 또는 새로 고침 토큰을 가져오기 위해 사용자 이름 및 암호로 인증할 때 Kafka 명령줄 툴에서 사용하는 공용 클라이언트입니다.
    • team-a-clientteam-b-client 클라이언트는 특정 Kafka 주제에 대한 부분적인 액세스 권한이 있는 서비스를 나타내는 기밀 클라이언트입니다.
  11. Red Hat Single Sign-On 관리 콘솔에서 Authorization > Permissions 로 이동하여 영역에 정의된 리소스 및 정책을 사용하는 권한이 부여된 권한을 확인합니다.

    예를 들어 kafka 클라이언트에는 다음과 같은 권한이 있습니다.

    Dev Team A can write to topics that start with x_ on any cluster
    Dev Team B can read from topics that start with x_ on any cluster
    Dev Team B can update consumer group offsets that start with x_ on any cluster
    ClusterManager of my-cluster Group has full access to cluster config on my-cluster
    ClusterManager of my-cluster Group has full access to consumer groups on my-cluster
    ClusterManager of my-cluster Group has full access to topics on my-cluster
    Copy to Clipboard Toggle word wrap
    Dev 팀 A
    Dev 팀 A 영역 역할은 모든 클러스터에서 x_ 로 시작하는 항목에 쓸 수 있습니다. 그러면 Topic:x_*, 범위 설명쓰기Dev 팀 A 정책이라는 리소스가 결합됩니다. Dev 팀 A 정책은 Dev 팀 A 라는 realm 역할이 있는 모든 사용자와 일치합니다.
    Dev 팀 B
    Dev 팀 B 영역 역할은 모든 클러스터에서 x_ 로 시작하는 주제에서 읽을 수 있습니다. 주제:x_*, Group:x_* 리소스, 설명읽기 범위, Dev 팀 B 정책이 결합됩니다. Dev 팀 B 정책은 Dev 팀 B 라는 realm 역할이 있는 모든 사용자와 일치합니다. 일치 사용자 및 클라이언트는 주제에서 읽고 x_ 로 시작하는 이름이 있는 주제 및 소비자 그룹에 대해 소비된 오프셋을 업데이트할 수 있습니다.

15.5.4.2. Red Hat Single Sign-On 권한 부여를 사용하여 Kafka 클러스터 배포

Red Hat Single Sign-On 서버에 연결하도록 구성된 Kafka 클러스터를 배포합니다. 예제 kafka-ephemeral-oauth-single-keycloak-authz.yaml 파일을 사용하여 Kafka 클러스터를 Kafka 사용자 정의 리소스로 배포합니다. 이 예제에서는 keycloak 권한 부여 및 oauth 인증을 사용하여 단일 노드 Kafka 클러스터를 배포합니다.

사전 요구 사항

  • Red Hat Single Sign-On 권한 부여 서버는 OpenShift 클러스터에 배포되고 example 영역을 사용하여 로드됩니다.
  • Cluster Operator는 OpenShift 클러스터에 배포됩니다.
  • AMQ Streams examples/security/keycloak-authorization/kafka-ephemeral-oauth-single-keycloak-authz.yaml 사용자 정의 리소스

프로세스

  1. 배포한 Red Hat Single Sign-On 인스턴스의 호스트 이름을 사용하여 Kafka 브로커의 신뢰 저장소 인증서가 Red Hat Single Sign-On 서버와 통신할 수 있도록 준비합니다.

    SSO_HOST=SSO-HOSTNAME
    SSO_HOST_PORT=$SSO_HOST:443
    STOREPASS=storepass
    
    echo "Q" | openssl s_client -showcerts -connect $SSO_HOST_PORT 2>/dev/null | awk ' /BEGIN CERTIFICATE/,/END CERTIFICATE/ { print $0 } ' > /tmp/sso.pem
    Copy to Clipboard Toggle word wrap

    보안(HTTPS) 연결을 위해 Kubernetes Ingress 를 사용하므로 인증서가 필요합니다.

    일반적으로 하나의 인증서가 없지만 인증서 체인이 있습니다. /tmp/sso.pem 파일에 마지막으로 나열된 최상위 발행자 CA만 제공해야 합니다. 수동으로 추출하거나 다음 명령을 사용하여 추출할 수 있습니다.

    인증서 체인에서 최상위 CA 인증서를 추출하는 명령의 예

    split -p "-----BEGIN CERTIFICATE-----" sso.pem sso-
    for f in $(ls sso-*); do mv $f $f.pem; done
    cp $(ls sso-* | sort -r | head -n 1) sso-ca.crt
    Copy to Clipboard Toggle word wrap

    참고

    신뢰할 수 있는 CA 인증서는 일반적으로 openssl 명령을 사용하지 않고 신뢰할 수 있는 소스에서 가져옵니다.

  2. OpenShift에 인증서를 시크릿으로 배포합니다.

    oc create secret generic oauth-server-cert --from-file=/tmp/sso-ca.crt -n $NS
    Copy to Clipboard Toggle word wrap
  3. 호스트 이름을 환경 변수로 설정

    SSO_HOST=SSO-HOSTNAME
    Copy to Clipboard Toggle word wrap
  4. 예제 Kafka 클러스터를 생성하고 배포합니다.

    cat examples/security/keycloak-authorization/kafka-ephemeral-oauth-single-keycloak-authz.yaml | sed -E 's#\${SSO_HOST}'"#$SSO_HOST#" | oc create -n $NS -f -
    Copy to Clipboard Toggle word wrap

15.5.4.3. CLI Kafka 클라이언트 세션에 대한 TLS 연결 준비

대화형 CLI 세션에 사용할 새 Pod를 생성합니다. TLS 연결을 위해 Red Hat Single Sign-On 인증서가 있는 신뢰 저장소를 설정합니다. 신뢰 저장소는 Red Hat Single Sign-On 및 Kafka 브로커에 연결하는 것입니다.

사전 요구 사항

  • Red Hat Single Sign-On 권한 부여 서버는 OpenShift 클러스터에 배포되고 example 영역을 사용하여 로드됩니다.

    Red Hat Single Sign-On 관리 콘솔에서 클라이언트에 할당된 역할이 클라이언트 > 서비스 계정 역할에 표시되는지 확인합니다.

  • Red Hat Single Sign-On과 연결하도록 구성된 Kafka 클러스터는 OpenShift 클러스터에 배포됩니다.

프로세스

  1. AMQ Streams Kafka 이미지를 사용하여 실행 중인 Kafka 브로커에 연결합니다.

    NS=sso
    oc run -ti --restart=Never --image=registry.redhat.io/amq-streams/kafka-37-rhel8:2.7.0 kafka-cli -n $NS -- /bin/sh
    Copy to Clipboard Toggle word wrap
    참고

    이미지 다운로드에서 oc 시간이 초과되면 후속 시도로 인해 AlreadyExists 오류가 발생할 수 있습니다.

  2. Pod 컨테이너에 연결합니다.

    oc attach -ti kafka-cli -n $NS
    Copy to Clipboard Toggle word wrap
  3. Red Hat Single Sign-On 인스턴스의 호스트 이름을 사용하여 TLS를 사용하여 클라이언트 연결에 대한 인증서를 준비합니다.

    SSO_HOST=SSO-HOSTNAME
    SSO_HOST_PORT=$SSO_HOST:443
    STOREPASS=storepass
    
    echo "Q" | openssl s_client -showcerts -connect $SSO_HOST_PORT 2>/dev/null | awk ' /BEGIN CERTIFICATE/,/END CERTIFICATE/ { print $0 } ' > /tmp/sso.pem
    Copy to Clipboard Toggle word wrap

    일반적으로 하나의 인증서가 없지만 인증서 체인이 있습니다. /tmp/sso.pem 파일에 마지막으로 나열된 최상위 발행자 CA만 제공해야 합니다. 수동으로 추출하거나 다음 명령을 사용하여 추출할 수 있습니다.

    인증서 체인에서 최상위 CA 인증서를 추출하는 명령의 예

    split -p "-----BEGIN CERTIFICATE-----" sso.pem sso-
    for f in $(ls sso-*); do mv $f $f.pem; done
    cp $(ls sso-* | sort -r | head -n 1) sso-ca.crt
    Copy to Clipboard Toggle word wrap

    참고

    신뢰할 수 있는 CA 인증서는 일반적으로 openssl 명령을 사용하지 않고 신뢰할 수 있는 소스에서 가져옵니다.

  4. Kafka 브로커에 대한 TLS 연결에 대한 신뢰 저장소를 생성합니다.

    keytool -keystore /tmp/truststore.p12 -storetype pkcs12 -alias sso -storepass $STOREPASS -import -file /tmp/sso-ca.crt -noprompt
    Copy to Clipboard Toggle word wrap
  5. Kafka 부트스트랩 주소를 Kafka 브로커의 호스트 이름으로 사용하고 tls 리스너 포트(9093)를 사용하여 Kafka 브로커의 인증서를 준비합니다.

    KAFKA_HOST_PORT=my-cluster-kafka-bootstrap:9093
    STOREPASS=storepass
    
    echo "Q" | openssl s_client -showcerts -connect $KAFKA_HOST_PORT 2>/dev/null | awk ' /BEGIN CERTIFICATE/,/END CERTIFICATE/ { print $0 } ' > /tmp/my-cluster-kafka.pem
    Copy to Clipboard Toggle word wrap

    가져온 .pem 파일은 일반적으로 하나의 인증서가 아니라 인증서 체인입니다. /tmp/my-cluster-kafka.pem 파일에 마지막으로 나열된 최상위 발행자 CA만 제공해야 합니다. 수동으로 추출하거나 다음 명령을 사용하여 추출할 수 있습니다.

    인증서 체인에서 최상위 CA 인증서를 추출하는 명령의 예

    split -p "-----BEGIN CERTIFICATE-----" /tmp/my-cluster-kafka.pem kafka-
    for f in $(ls kafka-*); do mv $f $f.pem; done
    cp $(ls kafka-* | sort -r | head -n 1) my-cluster-kafka-ca.crt
    Copy to Clipboard Toggle word wrap

    참고

    신뢰할 수 있는 CA 인증서는 일반적으로 openssl 명령을 사용하지 않고 신뢰할 수 있는 소스에서 가져옵니다. 이 예에서는 클라이언트가 Kafka 클러스터가 배포된 동일한 네임스페이스의 Pod에서 실행되고 있다고 가정합니다. 클라이언트가 OpenShift 클러스터 외부에서 Kafka 클러스터에 액세스하는 경우 먼저 부트스트랩 주소를 확인해야 합니다. 이 경우 OpenShift 시크릿에서 직접 클러스터 인증서를 가져올 수 있으며 openssl 이 필요하지 않습니다. 자세한 내용은 14장. Kafka 클러스터에 대한 클라이언트 액세스 설정의 내용을 참조하십시오.

  6. Kafka 브로커의 인증서를 신뢰 저장소에 추가합니다.

    keytool -keystore /tmp/truststore.p12 -storetype pkcs12 -alias my-cluster-kafka -storepass $STOREPASS -import -file /tmp/my-cluster-kafka-ca.crt -noprompt
    Copy to Clipboard Toggle word wrap

    세션을 열린 상태로 유지하여 권한 있는 액세스 권한을 확인합니다.

대화형 CLI 세션을 사용하여 Red Hat Single Sign-On 영역을 통해 적용되는 권한 부여 규칙을 확인합니다. Kafka의 예제 생산자 및 소비자 클라이언트를 사용하여 검사를 적용하여 다른 수준의 액세스 권한이 있는 사용자 및 서비스 계정으로 주제를 생성합니다.

team-a-clientteam-b-client 클라이언트를 사용하여 권한 부여 규칙을 확인합니다. alice admin 사용자를 사용하여 Kafka에서 추가 관리 작업을 수행합니다.

이 예제에서 사용되는 AMQ Streams Kafka 이미지에는 Kafka 생산자 및 소비자 바이너리가 포함되어 있습니다.

사전 요구 사항

클라이언트 및 관리자 구성 설정

  1. team-a-client 클라이언트에 대한 인증 속성을 사용하여 Kafka 구성 파일을 준비합니다.

    SSO_HOST=SSO-HOSTNAME
    
    cat > /tmp/team-a-client.properties << EOF
    security.protocol=SASL_SSL
    ssl.truststore.location=/tmp/truststore.p12
    ssl.truststore.password=$STOREPASS
    ssl.truststore.type=PKCS12
    sasl.mechanism=OAUTHBEARER
    sasl.jaas.config=org.apache.kafka.common.security.oauthbearer.OAuthBearerLoginModule required \
      oauth.client.id="team-a-client" \
      oauth.client.secret="team-a-client-secret" \
      oauth.ssl.truststore.location="/tmp/truststore.p12" \
      oauth.ssl.truststore.password="$STOREPASS" \
      oauth.ssl.truststore.type="PKCS12" \
      oauth.token.endpoint.uri="https://$SSO_HOST/auth/realms/kafka-authz/protocol/openid-connect/token" ;
    sasl.login.callback.handler.class=io.strimzi.kafka.oauth.client.JaasClientOauthLoginCallbackHandler
    EOF
    Copy to Clipboard Toggle word wrap

    SASL OAUTHBEARER 메커니즘이 사용됩니다. 이 메커니즘에는 클라이언트 ID와 클라이언트 시크릿이 필요합니다. 즉, 클라이언트가 먼저 Red Hat Single Sign-On 서버에 연결하여 액세스 토큰을 가져옵니다. 그러면 클라이언트는 Kafka 브로커에 연결하고 액세스 토큰을 사용하여 인증합니다.

  2. team-b-client 클라이언트에 대한 인증 속성을 사용하여 Kafka 구성 파일을 준비합니다.

    cat > /tmp/team-b-client.properties << EOF
    security.protocol=SASL_SSL
    ssl.truststore.location=/tmp/truststore.p12
    ssl.truststore.password=$STOREPASS
    ssl.truststore.type=PKCS12
    sasl.mechanism=OAUTHBEARER
    sasl.jaas.config=org.apache.kafka.common.security.oauthbearer.OAuthBearerLoginModule required \
      oauth.client.id="team-b-client" \
      oauth.client.secret="team-b-client-secret" \
      oauth.ssl.truststore.location="/tmp/truststore.p12" \
      oauth.ssl.truststore.password="$STOREPASS" \
      oauth.ssl.truststore.type="PKCS12" \
      oauth.token.endpoint.uri="https://$SSO_HOST/auth/realms/kafka-authz/protocol/openid-connect/token" ;
    sasl.login.callback.handler.class=io.strimzi.kafka.oauth.client.JaasClientOauthLoginCallbackHandler
    EOF
    Copy to Clipboard Toggle word wrap
  3. curl 을 사용하고 새로 고침 토큰을 가져오기 위해 암호를 부여하여 admin 사용자 alice 를 인증합니다.

    USERNAME=alice
    PASSWORD=alice-password
    
    GRANT_RESPONSE=$(curl -X POST "https://$SSO_HOST/auth/realms/kafka-authz/protocol/openid-connect/token" -H 'Content-Type: application/x-www-form-urlencoded' -d "grant_type=password&username=$USERNAME&password=$PASSWORD&client_id=kafka-cli&scope=offline_access" -s -k)
    
    REFRESH_TOKEN=$(echo $GRANT_RESPONSE | awk -F "refresh_token\":\"" '{printf $2}' | awk -F "\"" '{printf $1}')
    Copy to Clipboard Toggle word wrap

    새로 고침 토큰은 수명이 긴 오프라인 토큰이며 만료되지 않습니다.

  4. admin 사용자 alice 에 대한 인증 속성을 사용하여 Kafka 구성 파일을 준비합니다.

    cat > /tmp/alice.properties << EOF
    security.protocol=SASL_SSL
    ssl.truststore.location=/tmp/truststore.p12
    ssl.truststore.password=$STOREPASS
    ssl.truststore.type=PKCS12
    sasl.mechanism=OAUTHBEARER
    sasl.jaas.config=org.apache.kafka.common.security.oauthbearer.OAuthBearerLoginModule required \
      oauth.refresh.token="$REFRESH_TOKEN" \
      oauth.client.id="kafka-cli" \
      oauth.ssl.truststore.location="/tmp/truststore.p12" \
      oauth.ssl.truststore.password="$STOREPASS" \
      oauth.ssl.truststore.type="PKCS12" \
      oauth.token.endpoint.uri="https://$SSO_HOST/auth/realms/kafka-authz/protocol/openid-connect/token" ;
    sasl.login.callback.handler.class=io.strimzi.kafka.oauth.client.JaasClientOauthLoginCallbackHandler
    EOF
    Copy to Clipboard Toggle word wrap

    kafka-cli 공용 클라이언트는 sasl.jaas.configoauth.client.id 에 사용됩니다. 공개 클라이언트이므로 시크릿이 필요하지 않습니다. 클라이언트는 이전 단계에서 인증된 새로 고침 토큰을 사용하여 인증합니다. 새로 고침 토큰은 백그라운드에서 액세스 토큰을 요청하고, 그런 다음 인증을 위해 Kafka 브로커로 전송됩니다.

권한이 부여된 액세스로 메시지 생성

team-a-client 구성을 사용하여 a_ 또는 x_ 로 시작하는 항목에 메시지를 생성할 수 있는지 확인합니다.

  1. my-topic 주제를 작성합니다.

    bin/kafka-console-producer.sh --bootstrap-server my-cluster-kafka-bootstrap:9093 --topic my-topic \
      --producer.config=/tmp/team-a-client.properties
    First message
    Copy to Clipboard Toggle word wrap

    이 요청은 [my-topic] 오류에 액세스할 수 있는 Not authorized 을 반환합니다.

    team-a-client 에는 a_ 로 시작하는 주제에 대해 지원되는 작업을 수행할 수 있는 권한을 부여하는 Dev 팀 A 역할이 있지만 x_ 로 시작하는 항목에만 쓸 수 있습니다. my-topic 이라는 주제는 해당 규칙 중 어느 것과도 일치하지 않습니다.

  2. a_messages 항목에 씁니다.

    bin/kafka-console-producer.sh --bootstrap-server my-cluster-kafka-bootstrap:9093 --topic a_messages \
      --producer.config /tmp/team-a-client.properties
    First message
    Second message
    Copy to Clipboard Toggle word wrap

    Kafka에 성공적으로 메시지가 생성됩니다.

  3. CTRL+C를 눌러 CLI 애플리케이션을 종료합니다.
  4. 요청에 대해 Authorization GRANTED 의 디버그 로그에 대한 Kafka 컨테이너 로그를 확인합니다.

    oc logs my-cluster-kafka-0 -f -n $NS
    Copy to Clipboard Toggle word wrap

승인된 액세스로 메시지 사용

team-a-client 구성을 사용하여 a_messages 의 메시지를 사용합니다.

  1. 주제 a_messages 에서 메시지를 가져옵니다.

    bin/kafka-console-consumer.sh --bootstrap-server my-cluster-kafka-bootstrap:9093 --topic a_messages \
      --from-beginning --consumer.config /tmp/team-a-client.properties
    Copy to Clipboard Toggle word wrap

    team-a-clientDev Team A 역할은 a_ 로 시작하는 이름이 있는 소비자 그룹에만 액세스할 수 있기 때문에 요청이 오류를 반환합니다.

  2. team-a-client 속성을 업데이트하여 사용할 수 있는 사용자 지정 소비자 그룹을 지정합니다.

    bin/kafka-console-consumer.sh --bootstrap-server my-cluster-kafka-bootstrap:9093 --topic a_messages \
      --from-beginning --consumer.config /tmp/team-a-client.properties --group a_consumer_group_1
    Copy to Clipboard Toggle word wrap

    소비자는 a_messages 주제에서 모든 메시지를 받습니다.

권한이 부여된 액세스로 Kafka 관리

team-a-client 는 클러스터 수준 액세스 권한이 없는 계정이지만 일부 관리 작업과 함께 사용할 수 있습니다.

  1. 주제 나열.

    bin/kafka-topics.sh --bootstrap-server my-cluster-kafka-bootstrap:9093 --command-config /tmp/team-a-client.properties --list
    Copy to Clipboard Toggle word wrap

    a_messages 항목이 반환됩니다.

  2. 소비자 그룹을 나열합니다.

    bin/kafka-consumer-groups.sh --bootstrap-server my-cluster-kafka-bootstrap:9093 --command-config /tmp/team-a-client.properties --list
    Copy to Clipboard Toggle word wrap

    a_consumer_group_1 소비자 그룹이 반환됩니다.

    클러스터 구성에 대한 세부 정보를 가져옵니다.

    bin/kafka-configs.sh --bootstrap-server my-cluster-kafka-bootstrap:9093 --command-config /tmp/team-a-client.properties \
      --entity-type brokers --describe --entity-default
    Copy to Clipboard Toggle word wrap

    작업에 team-a-client 가 없는 클러스터 수준 권한이 필요하므로 요청이 오류를 반환합니다.

다른 권한이 있는 클라이언트 사용

team-b-client 구성을 사용하여 b_ 로 시작하는 항목에 대한 메시지를 생성합니다.

  1. a_messages 항목에 씁니다.

    bin/kafka-console-producer.sh --bootstrap-server my-cluster-kafka-bootstrap:9093 --topic a_messages \
      --producer.config /tmp/team-b-client.properties
    Message 1
    Copy to Clipboard Toggle word wrap

    이 요청은 [a_messages] 오류에 액세스할 수 있는 Not authorized 을 반환합니다.

  2. b_messages 항목에 씁니다.

    bin/kafka-console-producer.sh --bootstrap-server my-cluster-kafka-bootstrap:9093 --topic b_messages \
      --producer.config /tmp/team-b-client.properties
    Message 1
    Message 2
    Message 3
    Copy to Clipboard Toggle word wrap

    Kafka에 성공적으로 메시지가 생성됩니다.

  3. X _messages 항목에 씁니다.

    bin/kafka-console-producer.sh --bootstrap-server my-cluster-kafka-bootstrap:9093 --topic x_messages \
      --producer.config /tmp/team-b-client.properties
    Message 1
    Copy to Clipboard Toggle word wrap

    Not authorized to access topics: [x_messages] 오류가 반환됩니다. team-b-clientx_messages 에서만 읽을 수 있습니다.

  4. team-a-client 를 사용하여 x_messages 주제를 작성합니다.

    bin/kafka-console-producer.sh --bootstrap-server my-cluster-kafka-bootstrap:9093 --topic x_messages \
      --producer.config /tmp/team-a-client.properties
    Message 1
    Copy to Clipboard Toggle word wrap

    이 요청은 [x_messages] 오류에 액세스할 수 있는 Not authorized 을 반환합니다. team-a-clientx_messages 항목에 쓸 수 있지만 아직 존재하지 않는 경우 주제를 생성할 수 있는 권한이 없습니다. team-a-clientx_messages 항목에 작성하려면 관리자 전원 사용자가 파티션 및 복제본 수와 같은 올바른 구성으로 생성해야 합니다.

권한이 있는 admin 사용자로 Kafka 관리

admin 사용자 alice 를 사용하여 Kafka를 관리합니다. Alice 는 모든 Kafka 클러스터에서 모든 것을 관리할 수 있는 전체 액세스 권한을 갖습니다.

  1. x_messages 주제를 alice 로 만듭니다.

    bin/kafka-topics.sh --bootstrap-server my-cluster-kafka-bootstrap:9093 --command-config /tmp/alice.properties \
      --topic x_messages --create --replication-factor 1 --partitions 1
    Copy to Clipboard Toggle word wrap

    주제가 성공적으로 생성되었습니다.

  2. 모든 주제를 alice 로 나열합니다.

    bin/kafka-topics.sh --bootstrap-server my-cluster-kafka-bootstrap:9093 --command-config /tmp/alice.properties --list
    bin/kafka-topics.sh --bootstrap-server my-cluster-kafka-bootstrap:9093 --command-config /tmp/team-a-client.properties --list
    bin/kafka-topics.sh --bootstrap-server my-cluster-kafka-bootstrap:9093 --command-config /tmp/team-b-client.properties --list
    Copy to Clipboard Toggle word wrap

    admin 사용자 alice 는 모든 주제를 나열할 수 있지만 team-a-clientteam-b-client 는 액세스할 수 있는 항목만 나열할 수 있습니다.

    Dev 팀 ADev 팀 B 역할에는 x_ 로 시작하는 주제에 대한 설명 권한이 있지만 해당 역할에 대한 Describe 권한이 없으므로 다른 팀의 주제를 볼 수 없습니다.

  3. team-a-client 를 사용하여 x_messages 항목에 메시지를 생성합니다.

    bin/kafka-console-producer.sh --bootstrap-server my-cluster-kafka-bootstrap:9093 --topic x_messages \
      --producer.config /tmp/team-a-client.properties
    Message 1
    Message 2
    Message 3
    Copy to Clipboard Toggle word wrap

    alicex_messages 주제를 생성했으므로 Kafka에 메시지가 성공적으로 생성됩니다.

  4. team-b-client 를 사용하여 x_messages 항목에 대한 메시지를 생성합니다.

    bin/kafka-console-producer.sh --bootstrap-server my-cluster-kafka-bootstrap:9093 --topic x_messages \
      --producer.config /tmp/team-b-client.properties
    Message 4
    Message 5
    Copy to Clipboard Toggle word wrap

    이 요청은 [x_messages] 오류에 액세스할 수 있는 Not authorized 을 반환합니다.

  5. team-b-client 를 사용하여 x_messages 주제의 메시지를 사용합니다.

    bin/kafka-console-consumer.sh --bootstrap-server my-cluster-kafka-bootstrap:9093 --topic x_messages \
      --from-beginning --consumer.config /tmp/team-b-client.properties --group x_consumer_group_b
    Copy to Clipboard Toggle word wrap

    소비자는 x_messages 주제에서 모든 메시지를 받습니다.

  6. team-a-client 를 사용하여 x_messages 주제의 메시지를 사용합니다.

    bin/kafka-console-consumer.sh --bootstrap-server my-cluster-kafka-bootstrap:9093 --topic x_messages \
      --from-beginning --consumer.config /tmp/team-a-client.properties --group x_consumer_group_a
    Copy to Clipboard Toggle word wrap

    이 요청은 [x_messages] 오류에 액세스할 수 있는 Not authorized 을 반환합니다.

  7. team-a-client 를 사용하여 a_ 로 시작하는 소비자 그룹의 메시지를 사용합니다.

    bin/kafka-console-consumer.sh --bootstrap-server my-cluster-kafka-bootstrap:9093 --topic x_messages \
      --from-beginning --consumer.config /tmp/team-a-client.properties --group a_consumer_group_a
    Copy to Clipboard Toggle word wrap

    이 요청은 [x_messages] 오류에 액세스할 수 있는 Not authorized 을 반환합니다.

    dev 팀 A 에는 x_ 로 시작하는 주제에 대한 읽기 권한이 없습니다.

  8. alice 를 사용하여 x_messages 항목에 대한 메시지를 생성합니다.

    bin/kafka-console-consumer.sh --bootstrap-server my-cluster-kafka-bootstrap:9093 --topic x_messages \
      --from-beginning --consumer.config /tmp/alice.properties
    Copy to Clipboard Toggle word wrap

    Kafka에 성공적으로 메시지가 생성됩니다.

    Alice 는 모든 항목에서 읽거나 쓸 수 있습니다.Alice can read from or write to any topic.

  9. alice 를 사용하여 클러스터 구성을 읽습니다.

    bin/kafka-configs.sh --bootstrap-server my-cluster-kafka-bootstrap:9093 --command-config /tmp/alice.properties \
      --entity-type brokers --describe --entity-default
    Copy to Clipboard Toggle word wrap

    이 예제의 클러스터 구성은 비어 있습니다.

맨 위로 이동
Red Hat logoGithubredditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

Red Hat을 사용하는 고객은 신뢰할 수 있는 콘텐츠가 포함된 제품과 서비스를 통해 혁신하고 목표를 달성할 수 있습니다. 최신 업데이트를 확인하세요.

보다 포괄적 수용을 위한 오픈 소스 용어 교체

Red Hat은 코드, 문서, 웹 속성에서 문제가 있는 언어를 교체하기 위해 최선을 다하고 있습니다. 자세한 내용은 다음을 참조하세요.Red Hat 블로그.

Red Hat 소개

Red Hat은 기업이 핵심 데이터 센터에서 네트워크 에지에 이르기까지 플랫폼과 환경 전반에서 더 쉽게 작업할 수 있도록 강화된 솔루션을 제공합니다.

Theme

© 2026 Red Hat