14.4. OAuth 2.0 토큰 기반 인증 사용

1. Kafka 클라이언트는 클라이언트 ID 및 시크릿과 선택적으로 새로 고침 토큰을 사용하여 권한 부여 서버에서 액세스 토큰을 요청합니다. 또는 클라이언트는 사용자 이름과 암호를 사용하여 인증할 수 있습니다.
2. 권한 부여 서버는 새 액세스 토큰을 생성합니다.
3. Kafka 클라이언트는 SASL OAUTHB>-<ER 메커니즘을 사용하여 액세스 토큰을 전달하는 Kafka 브로커로 인증합니다.
4. Kafka 브로커는 자체 클라이언트 ID 및 시크릿을 사용하여 권한 부여 서버에서 토큰 인트로스펙션 끝점을 호출하여 액세스 토큰을 검증합니다.
5. 토큰이 유효한 경우 Kafka 클라이언트 세션이 설정됩니다.

1. Kafka 클라이언트는 클라이언트 ID 및 시크릿을 사용하여 토큰 끝점에서 권한 부여 서버와 선택적으로 새로 고침 토큰을 사용하여 인증합니다. 또는 클라이언트는 사용자 이름과 암호를 사용하여 인증할 수 있습니다.
2. 권한 부여 서버는 새 액세스 토큰을 생성합니다.
3. Kafka 클라이언트는 SASL OAUTHB>-<ER 메커니즘을 사용하여 액세스 토큰을 전달하는 Kafka 브로커로 인증합니다.
4. Kafka 브로커는 JWT 토큰 서명 확인 및 로컬 토큰 인트로스펙션을 사용하여 액세스 토큰을 로컬에서 검증합니다.

1. Kafka 클라이언트는 SASL OAUTHB>-<ER 메커니즘을 사용하여 장기간의 액세스 토큰을 전달하는 Kafka 브로커로 인증합니다.
2. Kafka 브로커는 자체 클라이언트 ID 및 시크릿을 사용하여 권한 부여 서버에서 토큰 인트로스펙션 끝점을 호출하여 액세스 토큰을 검증합니다.
3. 토큰이 유효한 경우 Kafka 클라이언트 세션이 설정됩니다.

1. Kafka 클라이언트는 SASL OAUTHB>-<ER 메커니즘을 사용하여 장기간의 액세스 토큰을 전달하는 Kafka 브로커로 인증합니다.
2. Kafka 브로커는 JWT 토큰 서명 확인 및 로컬 토큰 인트로스펙션을 사용하여 로컬에서 액세스 토큰을 검증합니다.

1. Kafka 클라이언트는 clientId 를 사용자 이름으로, 시크릿 을 암호로 전달합니다.
2. Kafka 브로커는 토큰 끝점을 사용하여 clientId 및 시크릿 을 권한 부여 서버에 전달합니다.
3. 클라이언트 인증 정보가 유효하지 않은 경우 권한 부여 서버에서 새 액세스 토큰 또는 오류를 반환합니다.

4. Kafka 브로커는 다음 방법 중 하나로 토큰을 검증합니다.

   1. 토큰 인트로스펙션 엔드 포인트가 지정되면 Kafka 브로커는 권한 부여 서버에서 끝점을 호출하여 액세스 토큰을 검증합니다. 토큰 검증에 성공하면 세션이 설정됩니다.
   2. 로컬 토큰 인트로스펙션이 사용되는 경우 권한 부여 서버에 대한 요청이 수행되지 않습니다. Kafka 브로커는 JWT 토큰 서명 검사를 사용하여 로컬에서 액세스 토큰을 검증합니다.

1. Kafka 클라이언트는 사용자 이름과 암호를 전달합니다. password는 클라이언트를 실행하기 전에 수동으로 가져와 구성한 액세스 토큰의 값을 제공합니다.

2. 암호는 Kafka 브로커 리스너가 인증을 위해 토큰 끝점으로 구성되었는지에 따라 $accessToken: 문자열 접두사를 사용하여 전달됩니다.

   1. 토큰 끝점이 구성된 경우 브로커에 클라이언트 시크릿 대신 액세스 토큰이 포함되어 있음을 알리기 위해 암호 앞에 $accessToken: 접두사가 추가해야 합니다. Kafka 브로커는 사용자 이름을 계정 사용자 이름으로 해석합니다.
   2. Kafka 브로커 리스너에 토큰 끝점이 구성되지 않은 경우( no-client-credentials 모드강화) 암호는 접두사 없이 액세스 토큰을 제공해야 합니다. Kafka 브로커는 사용자 이름을 계정 사용자 이름으로 해석합니다. 이 모드에서 클라이언트는 클라이언트 ID와 시크릿을 사용하지 않으며 password 매개변수는 항상 원시 액세스 토큰으로 해석됩니다.

3. Kafka 브로커는 다음 방법 중 하나로 토큰을 검증합니다.

   1. 토큰 인트로스펙션 엔드 포인트가 지정되면 Kafka 브로커는 권한 부여 서버에서 끝점을 호출하여 액세스 토큰을 검증합니다. 토큰 검증에 성공하면 세션이 설정됩니다.
   2. 로컬 토큰 인트로스펙션을 사용하는 경우 권한 부여 서버에 대한 요청이 없습니다. Kafka 브로커는 JWT 토큰 서명 검사를 사용하여 로컬에서 액세스 토큰을 검증합니다.

절차

1. 클러스터에 권한 부여 서버를 배포합니다.

2. 인증 서버의 CLI 또는 관리 콘솔에 액세스하여 AMQ Streams에 대한 OAuth 2.0을 구성합니다.

   이제 AMQ Streams에서 작동하도록 권한 부여 서버를 준비합니다.

3. kafka-broker 클라이언트를 구성합니다.
4. 애플리케이션의 각 Kafka 클라이언트 구성 요소에 대해 클라이언트를 구성합니다.

절차

1. 편집기에서 Kafka 리소스의 Kafka 브로커 구성(Kafka.spec.kafka)을 업데이트합니다.

   oc edit kafka my-cluster

2. Kafka 브로커 리스너 구성을 구성합니다.

   각 유형의 리스너에 대한 구성은 서로 독립적이므로 동일하지 않아도 됩니다.

   다음 예제에서는 외부 리스너에 대해 구성된 구성 옵션을 보여줍니다.

   예 1: 빠른 로컬 JWT 토큰 검증 구성

   #...
   - name: external
     port: 9094
     type: loadbalancer
     tls: true
     authentication:
       type: oauth 

   1

   
       validIssuerUri: https://<auth_server_address>/auth/realms/external 

   2

   
       jwksEndpointUri: https://<auth_server_address>/auth/realms/external/protocol/openid-connect/certs 

   3

   
       userNameClaim: preferred_username 

   4

   
       maxSecondsWithoutReauthentication: 3600 

   5

   
       tlsTrustedCertificates: 

   6

   
       - secretName: oauth-server-cert
         certificate: ca.crt
       disableTlsHostnameVerification: true 

   7

   
       jwksExpirySeconds: 360 

   8

   
       jwksRefreshSeconds: 300 

   9

   
       jwksMinRefreshPauseSeconds: 1 

   10

   1

   리스너 유형을 oauth 로 설정합니다.

   2

   인증에 사용되는 토큰 발행자의 URI입니다.

   3

   로컬 JWT 검증에 사용되는 JWKS 인증서 끝점의 URI입니다.

   4

   사용자를 식별하는 데 사용되는 실제 사용자 이름을 포함하는 토큰 클레임(또는 키)입니다. 해당 값은 권한 부여 서버에 따라 다릅니다. 필요한 경우 "['user.info'].['user.id']" 와 같은 JsonPath 표현식을 사용하여 토큰 내의 중첩된 JSON 속성에서 사용자 이름을 검색할 수 있습니다.

   5

   (선택 사항) 액세스 토큰과 동일한 기간 동안 세션 만료를 적용하는 Kafka 재인증 메커니즘을 활성화합니다. 지정된 값이 액세스 토큰이 만료되기 위해 남은 시간보다 작으면 실제 토큰 만료 전에 클라이언트가 다시 인증해야 합니다. 기본적으로 액세스 토큰이 만료되면 세션이 만료되지 않으며 클라이언트는 재인증을 시도하지 않습니다.

   6

   (선택 사항) 권한 부여 서버에 대한 TLS 연결에 필요한 신뢰할 수 있는 인증서입니다.

   7

   (선택 사항) TLS 호스트 이름 확인을 비활성화합니다. 기본값은 false 입니다.

   8

   JWKS 인증서는 만료되기 전에 유효한 것으로 간주됩니다. 기본값은 360 초입니다. 더 긴 시간을 지정하는 경우 취소된 인증서에 대한 액세스를 허용할 위험을 고려하십시오.

   9

   JWKS 인증서 새로 고침 간격입니다. 간격은 만료 간격보다 최소 60초 짧어야 합니다. 기본값은 300 초입니다.

   10

   연속한 시도 사이에 최소 일시 정지(초)는 JWKS 공개 키를 새로 고침합니다. 알 수 없는 서명 키가 발생하면 JWKS 키 새로 고침은 마지막 새로 고침 시도 이후 지정된 일시 중지를 포함하여 정기적인 일정 외부에서 예약됩니다. 키를 새로 고치면 exponential 백오프 규칙을 따르고 jwksRefreshSeconds 에 도달할 때까지 일시 중지를 계속 늘리면 실패한 새로 고침을 다시 시도합니다. 기본값은 1입니다.

   예 2: 인트로스펙션 끝점을 사용하여 토큰 검증 구성

   - name: external
     port: 9094
     type: loadbalancer
     tls: true
     authentication:
       type: oauth
       validIssuerUri: https://<auth_server_address>/auth/realms/external
       introspectionEndpointUri: https://<auth_server_address>/auth/realms/external/protocol/openid-connect/token/introspect 

   1

   
       clientId: kafka-broker 

   2

   
       clientSecret: 

   3

   
         secretName: my-cluster-oauth
         key: clientSecret
       userNameClaim: preferred_username 

   4

   
       maxSecondsWithoutReauthentication: 3600 

   5

   1

   토큰 인트로스펙션 끝점의 URI입니다.

   2

   클라이언트를 식별하는 클라이언트 ID입니다.

   3

   클라이언트 시크릿 및 클라이언트 ID가 인증에 사용됩니다.

   4

   사용자를 식별하는 데 사용되는 실제 사용자 이름을 포함하는 토큰 클레임(또는 키)입니다. 해당 값은 권한 부여 서버에 따라 다릅니다. 필요한 경우 "['user.info'].['user.id']" 와 같은 JsonPath 표현식을 사용하여 토큰 내의 중첩된 JSON 속성에서 사용자 이름을 검색할 수 있습니다.

   5

   (선택 사항) 액세스 토큰과 동일한 기간 동안 세션 만료를 적용하는 Kafka 재인증 메커니즘을 활성화합니다. 지정된 값이 액세스 토큰이 만료되기 위해 남은 시간보다 작으면 실제 토큰 만료 전에 클라이언트가 다시 인증해야 합니다. 기본적으로 액세스 토큰이 만료되면 세션이 만료되지 않으며 클라이언트는 재인증을 시도하지 않습니다.

   OAuth 2.0 인증 및 권한 부여 서버 유형에 따라 사용할 수 있는 추가(선택 사항) 구성 설정이 있습니다.

     # ...
     authentication:
       type: oauth
       # ...
       checkIssuer: false 

   1

   
       checkAudience: true 

   2

   
       fallbackUserNameClaim: client_id 

   3

   
       fallbackUserNamePrefix: client-account- 

   4

   
       validTokenType: bearer 

   5

   
       userInfoEndpointUri: https://<auth_server_address>/auth/realms/external/protocol/openid-connect/userinfo 

   6

   
       enableOauthBearer: false 

   7

   
       enablePlain: true 

   8

   
       tokenEndpointUri: https://<auth_server_address>/auth/realms/external/protocol/openid-connect/token 

   9

   
       customClaimCheck: "@.custom == 'custom-value'" 

   10

   
       clientAudience: audience 

   11

   
       clientScope: scope 

   12

   
       connectTimeoutSeconds: 60 

   13

   
       readTimeoutSeconds: 60 

   14

   
       httpRetries: 2 

   15

   
       httpRetryPauseMs: 300 

   16

   
       groupsClaim: "$.groups" 

   17

   
       groupsClaimDelimiter: "," 

   18

   1

   권한 부여 서버에서 iss 클레임을 제공하지 않으면 발급자 검사를 수행할 수 없습니다. 이 경우 checkIssuer 를 false 로 설정하고 validIssuerUri 를 지정하지 마십시오. 기본값은 true 입니다.

   2

   권한 부여 서버에서 aud (audience) 클레임을 제공하고 오디언스 검사를 적용하려면 checkAudience 를 true 로 설정합니다. 대상 검사에서 의도된 토큰 수신자를 식별합니다. 결과적으로 Kafka 브로커는 aud 클레임에 clientId 가 없는 토큰을 거부합니다. 기본값은 false 입니다.

   3

   권한 부여 서버는 일반 사용자와 클라이언트를 모두 식별하는 단일 속성을 제공하지 않을 수 있습니다. 클라이언트가 자체 이름으로 인증되면 서버에서 클라이언트 ID 를 제공할 수 있습니다. 사용자가 사용자 이름과 암호를 사용하여 새로 고침 토큰 또는 액세스 토큰을 가져오는 경우 서버는 클라이언트 ID 외에도 사용자 이름 속성을 제공할 수 있습니다. 기본 사용자 ID 속성을 사용할 수 없는 경우 사용할 사용자 이름 클레임(attribute)을 지정하려면 이 대체 옵션을 사용합니다. 필요한 경우 "['client.info'].['client.id']" 와 같은 JsonPath 표현식을 사용하여 대체 사용자 이름을 검색하여 토큰 내의 중첩된 JSON 속성에서 사용자 이름을 검색할 수 있습니다.

   4

   fallbackUserNameClaim 이 적용되는 상황에서는 사용자 이름 클레임 값과 대체 사용자 이름 클레임의 값 간에 이름 충돌을 방지해야 할 수도 있습니다. 생산자라는 클라이언트뿐만 아니라 생산자 라는 일반 사용자도 존재하는 상황을 고려하십시오. 이 속성을 사용하여 클라이언트의 사용자 ID에 접두사를 추가할 수 있습니다.You can use this property to add a prefix to the user ID of the client.

   5

   (사용 중인 권한 부여 서버에 따라 introspectionEndpointUri를 사용하는 경우에만 적용 가능) 인트로스펙션 끝점에서 토큰 유형 특성을 반환하거나 반환하지 않거나 다른 값을 포함할 수 있습니다. 인트로스펙션 끝점의 응답에 포함해야 하는 유효한 토큰 유형 값을 지정할 수 있습니다.

   6

   (Introspection EndpointUri를 사용하는 경우에만) 권한 부여 서버는 Introspection Endpoint 응답으로 식별 가능한 정보를 제공하지 않도록 구성되거나 구현될 수 있습니다. 사용자 ID를 가져오려면 userinfo 끝점의 URI를 폴백으로 구성할 수 있습니다. userNameClaim,fallbackUserNameClaim, fallbackUserNamePrefix 설정이 userinfo 끝점의 응답에 적용됩니다.

   7

   이 값을 false 로 설정하여 리스너에서 OAUTHBREER 메커니즘을 비활성화합니다. 최소 하나의 PLAIN 또는 OAUTHB possibilityER를 사용하도록 설정해야 합니다. 기본값은 true 입니다.

   8

   모든 플랫폼의 클라이언트에 대해 지원되는 리스너에서 PLAIN 인증을 활성화하려면 true 로 설정합니다.

   9

   PLAIN 메커니즘에 대한 추가 구성입니다. 지정된 경우 클라이언트는 $accessToken: 접두사 를 사용하여 액세스 토큰을 암호로 전달하여 PLAIN을 통해 인증할 수 있습니다. 프로덕션의 경우 항상 https:// URL을 사용합니다.

   10

   이 값을 JsonPath 필터 쿼리로 설정하여 검증 중에 JWT 액세스 토큰에 추가 사용자 지정 규칙을 적용할 수 있습니다. 액세스 토큰에 필요한 데이터가 포함되어 있지 않으면 거부됩니다. introspectionEndpointUri 를 사용하는 경우 사용자 정의 검사가 인트로스펙션 끝점 응답 JSON에 적용됩니다.

   11

   토큰 끝점에 전달된 대상 매개변수입니다. 구독자 간 인증을 위한 액세스 토큰을 가져올 때 대상 사용자가 사용됩니다.An audience is used when obtaining an access token for inter-broker authentication. 또한 clientId 및 시크릿 을 사용하여 PLAIN 클라이언트 인증을 통해 OAuth 2.0에 대한 클라이언트 이름에 사용됩니다. 권한 부여 서버에 따라 토큰과 토큰의 콘텐츠만 가져올 수 있습니다. 리스너의 토큰 검증 규칙에는 영향을 미치지 않습니다.

   12

   토큰 끝점에 전달된 범위 매개변수입니다. 범위는broker 간 인증을 위한 액세스 토큰을 가져올 때 사용됩니다. 또한 clientId 및 시크릿 을 사용하여 PLAIN 클라이언트 인증을 통해 OAuth 2.0에 대한 클라이언트 이름에 사용됩니다. 권한 부여 서버에 따라 토큰과 토큰의 콘텐츠만 가져올 수 있습니다. 리스너의 토큰 검증 규칙에는 영향을 미치지 않습니다.

   13

   권한 부여 서버에 연결할 때 연결 제한 시간(초)입니다. 기본값은 60입니다.

   14

   권한 부여 서버에 연결할 때 읽기 제한 시간(초)입니다. 기본값은 60입니다.

   15

   권한 부여 서버에 실패한 HTTP 요청을 재시도하는 최대 횟수입니다. 기본값은 0 입니다. 즉, 재시도가 수행되지 않습니다. 이 옵션을 효과적으로 사용하려면 connectTimeoutSeconds 및 readTimeoutSeconds 옵션에 대한 시간 초과 시간을 줄이는 것이 좋습니다. 그러나 재시도하면 현재 작업자 스레드를 다른 요청에서 사용할 수 없게 할 수 있으며 요청이 너무 많으면 Kafka 브로커가 응답하지 않을 수 있습니다.

   16

   권한 부여 서버에 실패한 HTTP 요청의 다른 재시도를 시도하기 전에 대기하는 시간입니다. 기본적으로 이 시간은 0으로 설정되어 일시 중지가 적용되지 않습니다. 실패한 요청으로 인해 많은 문제가 요청별 네트워크 결함 또는 프록시 문제로 신속하게 해결될 수 있기 때문입니다. 그러나 권한 부여 서버가 과부하 상태에 있거나 트래픽이 높은 경우 이 옵션을 100ms 이상으로 설정하여 서버의 부하를 줄이고 재시도 횟수 가능성을 높일 수 있습니다.

   17

   JWT 토큰 또는 인트로스펙션 끝점 응답에서 그룹 정보를 추출하는 데 사용되는 JsonPath 쿼리입니다. 이 옵션은 기본적으로 설정되어 있지 않습니다. 이 옵션을 구성하면 사용자 정의 작성자가 사용자 그룹을 기반으로 권한 결정을 내릴 수 있습니다.

   18

   하나의 구분된 단일 문자열로 반환될 때 그룹 정보를 구문 분석하는 데 사용되는 구분 기호입니다. 기본값은 ','(comma)입니다.

3. 편집기를 저장하고 종료한 다음 롤링 업데이트가 완료될 때까지 기다립니다.

4. 로그 또는 Pod 상태 전환을 확인하여 업데이트를 확인합니다.

   oc logs -f ${POD_NAME} -c ${CONTAINER_NAME}
   oc get pod -w

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

절차

1. OAuth 2.0 지원이 포함된 클라이언트 라이브러리를 Kafka 클라이언트의 pom.xml 파일에 추가합니다.

   <dependency>
    <groupId>io.strimzi</groupId>
    <artifactId>kafka-oauth-client</artifactId>
    <version>0.13.0.redhat-00008</version>
   </dependency>

2. 속성 파일에 다음 구성을 지정하여 클라이언트 속성을 구성합니다.

   • 보안 프로토콜
   • SASL 메커니즘

   • 사용 중인 방법에 따른 module 및 인증 속성

     예를 들어 client.properties 파일에 다음을 추가할 수 있습니다.

     클라이언트 자격 증명 메커니즘 속성

     security.protocol=SASL_SSL 

     1

     
     sasl.mechanism=OAUTHBEARER 

     2

     
     ssl.truststore.location=/tmp/truststore.p12 

     3

     
     ssl.truststore.password=$STOREPASS
     ssl.truststore.type=PKCS12
     sasl.jaas.config=org.apache.kafka.common.security.oauthbearer.OAuthBearerLoginModule required \
       oauth.token.endpoint.uri="<token_endpoint_url>" \ 

     4

     
       oauth.client.id="<client_id>" \ 

     5

     
       oauth.client.secret="<client_secret>" \ 

     6

     
       oauth.ssl.truststore.location="/tmp/oauth-truststore.p12" \ 

     7

     
       oauth.ssl.truststore.password="$STOREPASS" \ 

     8

     
       oauth.ssl.truststore.type="PKCS12" \ 

     9

     
       oauth.scope="<scope>" \ 

     10

     
       oauth.audience="<audience>" ; 

     11

     1

     TLS 암호화 연결을 위한 SASL_SSL 보안 프로토콜. 로컬 개발에만 암호화되지 않은 연결에서는 SASL_PLAINTEXT 를 사용하십시오.

     2

     SASL 메커니즘을 OAUTHB learnER 또는 PLAIN 으로 지정합니다.

     3

     Kafka 클러스터에 대한 보안 액세스를 위한 신뢰 저장소 구성입니다.

     4

     권한 부여 서버 토큰 끝점의 URI입니다.

     5

     클라이언트 ID: 권한 부여 서버에서 클라이언트를 생성할 때 사용되는 이름입니다.

     6

     권한 부여 서버에서 클라이언트를 생성할 때 생성된 클라이언트 시크릿입니다.

     7

     위치에는 권한 부여 서버의 공개 키 인증서(truststore.p12)가 포함됩니다.

     8

     신뢰 저장소에 액세스하기 위한 암호입니다.

     9

     truststore 유형입니다.

     10

     (선택 사항) 토큰 끝점에서 토큰을 요청하는 범위입니다. 권한 부여 서버에 범위를 지정하기 위해 클라이언트가 필요할 수 있습니다.

     11

     (선택 사항) 토큰 끝점에서 토큰을 요청하는 대상입니다. 권한 부여 서버에 대상을 지정하기 위해 클라이언트가 필요할 수 있습니다.

     password grant mechanism properties

     security.protocol=SASL_SSL
     sasl.mechanism=OAUTHBEARER
     ssl.truststore.location=/tmp/truststore.p12
     ssl.truststore.password=$STOREPASS
     ssl.truststore.type=PKCS12
     sasl.jaas.config=org.apache.kafka.common.security.oauthbearer.OAuthBearerLoginModule required \
       oauth.token.endpoint.uri="<token_endpoint_url>" \
       oauth.client.id="<client_id>" \ 

     1

     
       oauth.client.secret="<client_secret>" \ 

     2

     
       oauth.password.grant.username="<username>" \ 

     3

     
       oauth.password.grant.password="<password>" \ 

     4

     
       oauth.ssl.truststore.location="/tmp/oauth-truststore.p12" \
       oauth.ssl.truststore.password="$STOREPASS" \
       oauth.ssl.truststore.type="PKCS12" \
       oauth.scope="<scope>" \
       oauth.audience="<audience>" ;

     1

     클라이언트 ID: 권한 부여 서버에서 클라이언트를 생성할 때 사용되는 이름입니다.

     2

     (선택 사항) 권한 부여 서버에서 클라이언트를 생성할 때 생성된 클라이언트 시크릿입니다.

     3

     암호 부여 인증에 대한 사용자 이름입니다. OAuth 암호 부여 구성(사용자 이름 및 암호)은 OAuth 2.0 암호 부여 방법을 사용합니다. 암호 부여를 사용하려면 제한된 권한이 있는 권한 부여 서버에서 클라이언트에 대한 사용자 계정을 만듭니다. 계정이 서비스 계정처럼 작동해야 합니다. 인증에 사용자 계정이 필요하지만 새로 고침 토큰을 사용하는 것이 필요한 환경에서 사용합니다.

     4

     암호 부여 인증의 암호입니다.

     참고

     SASL PLAIN은 OAuth 2.0 암호 부여 방법을 사용하여 사용자 이름과 암호(암호 부여) 전달을 지원하지 않습니다.

     액세스 토큰 속성

     security.protocol=SASL_SSL
     sasl.mechanism=OAUTHBEARER
     ssl.truststore.location=/tmp/truststore.p12
     ssl.truststore.password=$STOREPASS
     ssl.truststore.type=PKCS12
     sasl.jaas.config=org.apache.kafka.common.security.oauthbearer.OAuthBearerLoginModule required \
       oauth.token.endpoint.uri="<token_endpoint_url>" \
       oauth.access.token="<access_token>" ; 

     1

     
       oauth.ssl.truststore.location="/tmp/oauth-truststore.p12" \
       oauth.ssl.truststore.password="$STOREPASS" \
       oauth.ssl.truststore.type="PKCS12" \

     1

     Kafka 클라이언트의 장기 액세스 토큰입니다.

     토큰 속성 새로 고침

     security.protocol=SASL_SSL
     sasl.mechanism=OAUTHBEARER
     ssl.truststore.location=/tmp/truststore.p12
     ssl.truststore.password=$STOREPASS
     ssl.truststore.type=PKCS12
     sasl.jaas.config=org.apache.kafka.common.security.oauthbearer.OAuthBearerLoginModule required \
       oauth.token.endpoint.uri="<token_endpoint_url>" \
       oauth.client.id="<client_id>" \ 

     1

     
       oauth.client.secret="<client_secret>" \ 

     2

     
       oauth.refresh.token="<refresh_token>" ; 

     3

     
       oauth.ssl.truststore.location="/tmp/oauth-truststore.p12" \
       oauth.ssl.truststore.password="$STOREPASS" \
       oauth.ssl.truststore.type="PKCS12" \

     1

     클라이언트 ID: 권한 부여 서버에서 클라이언트를 생성할 때 사용되는 이름입니다.

     2

     (선택 사항) 권한 부여 서버에서 클라이언트를 생성할 때 생성된 클라이언트 시크릿입니다.

     3

     Kafka 클라이언트의 장기 새로 고침 토큰입니다.

3. OAUTH 2.0 인증에 대한 클라이언트 속성을 Java 클라이언트 코드로 입력합니다.

   클라이언트 속성 입력 표시 예

   Properties props = new Properties();
   try (FileReader reader = new FileReader("client.properties", StandardCharsets.UTF_8)) {
     props.load(reader);
   }

4. Kafka 클라이언트가 Kafka 브로커에 액세스할 수 있는지 확인합니다.

절차

1. 클라이언트 시크릿을 생성하고 구성 요소에 환경 변수로 마운트합니다.

   예를 들어, 여기서는 Kafka 브리지의 클라이언트 보안을 생성하고 있습니다.

   apiVersion: kafka.strimzi.io/v1beta2
   kind: Secret
   metadata:
    name: my-bridge-oauth
   type: Opaque
   data:
    clientSecret: MGQ1OTRmMzYtZTllZS00MDY2LWI5OGEtMTM5MzM2NjdlZjQw 

   1

   1

   clientSecret 키는 base64 형식이어야 합니다.

2. OAuth 2.0 인증이 인증 속성에 맞게 구성되도록 Kafka 구성 요소의 리소스를 생성하거나 편집합니다.

   OAuth 2.0 인증의 경우 다음 옵션을 사용할 수 있습니다.

   • 클라이언트 ID 및 시크릿
   • 클라이언트 ID 및 새로 고침 토큰
   • 액세스 토큰
   • 사용자 이름 및 암호
   • TLS

   예를 들어 여기에서는 OAuth 2.0이 클라이언트 ID 및 시크릿 및 TLS를 사용하여 Kafka 브리지 클라이언트에 할당됩니다.

   apiVersion: kafka.strimzi.io/v1beta2
   kind: KafkaBridge
   metadata:
     name: my-bridge
   spec:
     # ...
     authentication:
       type: oauth 

   1

   
       tokenEndpointUri: https://<auth-server-address>/auth/realms/master/protocol/openid-connect/token 

   2

   
       clientId: kafka-bridge
       clientSecret:
         secretName: my-bridge-oauth
         key: clientSecret
       tlsTrustedCertificates: 

   3

   
       - secretName: oauth-server-cert
         certificate: tls.crt

   1

   인증 유형을 oauth 로 설정합니다.

   2

   인증을 위한 토큰 끝점의 URI입니다.

   3

   권한 부여 서버에 대한 TLS 연결에 필요한 신뢰할 수 있는 인증서입니다.

   OAuth 2.0 인증 및 권한 부여 서버 유형에 따라 사용할 수 있는 추가 구성 옵션이 있습니다.

   # ...
   spec:
     # ...
     authentication:
       # ...
       disableTlsHostnameVerification: true 

   1

   
       checkAccessTokenType: false 

   2

   
       accessTokenIsJwt: false 

   3

   
       scope: any 

   4

   
       audience: kafka 

   5

   
       connectTimeoutSeconds: 60 

   6

   
       readTimeoutSeconds: 60 

   7

   
       httpRetries: 2 

   8

   
       httpRetryPauseMs: 300 

   9

   1

   (선택 사항) TLS 호스트 이름 확인을 비활성화합니다. 기본값은 false 입니다.

   2

   권한 부여 서버가 JWT 토큰 내에 typ (유형) 클레임을 반환하지 않으면 checkAccessTokenType: false 를 적용하여 토큰 유형 검사를 건너뛸 수 있습니다. 기본값은 true 입니다.

   3

   불투명 토큰을 사용하는 경우 액세스 토큰이 JWT 토큰으로 처리되지 않도록 accessTokenIsJwt: false 를 적용할 수 있습니다.

   4

   (선택 사항) 토큰 끝점에서 토큰을 요청하는 범위입니다. 권한 부여 서버에 범위를 지정하기 위해 클라이언트가 필요할 수 있습니다. 이 경우 이 모든 것입니다.

   5

   (선택 사항) 토큰 끝점에서 토큰을 요청하는 대상입니다. 권한 부여 서버에 대상을 지정하기 위해 클라이언트가 필요할 수 있습니다. 이 경우 kafka 입니다.

   6

   (선택 사항) 권한 부여 서버에 연결할 때 연결 제한 시간(초)입니다. 기본값은 60입니다.

   7

   (선택 사항) 권한 부여 서버에 연결할 때 읽기 제한 시간(초)입니다. 기본값은 60입니다.

   8

   (선택 사항) 권한 부여 서버에 실패한 HTTP 요청을 재시도하는 최대 횟수입니다. 기본값은 0 입니다. 즉, 재시도가 수행되지 않습니다. 이 옵션을 효과적으로 사용하려면 connectTimeoutSeconds 및 readTimeoutSeconds 옵션에 대한 시간 초과 시간을 줄이는 것이 좋습니다. 그러나 재시도하면 현재 작업자 스레드를 다른 요청에서 사용할 수 없게 할 수 있으며 요청이 너무 많으면 Kafka 브로커가 응답하지 않을 수 있습니다.

   9

   (선택 사항) 권한 부여 서버에 실패한 HTTP 요청의 다른 재시도를 시도하기 전에 대기하는 시간입니다. 기본적으로 이 시간은 0으로 설정되어 일시 중지가 적용되지 않습니다. 실패한 요청으로 인해 많은 문제가 요청별 네트워크 결함 또는 프록시 문제로 신속하게 해결될 수 있기 때문입니다. 그러나 권한 부여 서버가 과부하 상태에 있거나 트래픽이 높은 경우 이 옵션을 100ms 이상으로 설정하여 서버의 부하를 줄이고 재시도 횟수 가능성을 높일 수 있습니다.

3. Kafka 리소스 배포에 변경 사항을 적용합니다.

   oc apply -f your-file

4. 로그 또는 Pod 상태 전환을 확인하여 업데이트를 확인합니다.

   oc logs -f ${POD_NAME} -c ${CONTAINER_NAME}
   oc get pod -w

   롤링 업데이트는 OAuth 2.0 인증을 사용하여 Kafka 브로커와 상호 작용하도록 구성 요소를 구성합니다.