17.2.5.3. Kafka 구성 요소에서 OAuth 2.0 설정

프로세스

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 및 클라이언트 어설션
   • 클라이언트 ID 및 새로 고침 토큰
   • 액세스 토큰
   • 사용자 이름 및 암호
   • TLS

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

   클라이언트 시크릿을 사용한 OAuth 2.0 인증 구성 예

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

   1

   
       tokenEndpointUri: https://<auth_server_address>/<path_to_token_endpoint> 

   2

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

   3

   
         - secretName: oauth-server-cert
           pattern: "*.crt"

   1

   oauth 로 설정된 인증 유형입니다.

   2

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

   3

   권한 부여 서버에 대한 TLS 연결에 대해 지정된 보안 내에서 X.509 형식으로 저장된 인증서입니다.

   이 예에서 OAuth 2.0은 클라이언트 ID와 클라이언트 어설션 파일의 위치를 사용하여 Kafka 브리지 클라이언트에 할당되며, TLS는 권한 부여 서버에 연결합니다.

   클라이언트 어설션을 사용한 OAuth 2.0 인증 구성 예

   apiVersion: kafka.strimzi.io/v1beta2
   kind: KafkaBridge
   metadata:
     name: my-bridge
   spec:
     # ...
     authentication:
       type: oauth
       tokenEndpointUri: https://<auth_server_address>/<path_to_token_endpoint>
       clientId: kafka-bridge
       clientAssertionLocation: /var/run/secrets/sso/assertion 

   1

   
       tlsTrustedCertificates:
         - secretName: oauth-server-cert
           pattern: "*.crt"

   1

   클라이언트를 인증하는 데 사용되는 클라이언트 어설션 파일의 파일 시스템 경로입니다. 이 파일은 일반적으로 외부 운영자 서비스에서 배포된 포드에 추가됩니다. 또는 clientAssertion 을 사용하여 클라이언트 어설션 값이 포함된 시크릿을 나타냅니다.

   여기에서 OAuth 2.0은 서비스 계정 토큰을 사용하여 Kafka 브리지 클라이언트에 할당됩니다.

   서비스 계정 토큰을 사용한 OAuth 2.0 인증 구성의 예

   apiVersion: kafka.strimzi.io/v1beta2
   kind: KafkaBridge
   metadata:
     name: my-bridge
   spec:
     # ...
     authentication:
       type: oauth
       accessTokenLocation: /var/run/secrets/kubernetes.io/serviceaccount/token 

   1

   1

   서비스 계정 토큰 파일 위치의 경로입니다.

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

   추가 구성 옵션

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

   1

   
       accessTokenIsJwt: false 

   2

   
       scope: any 

   3

   
       audience: kafka 

   4

   
       connectTimeoutSeconds: 60 

   5

   
       readTimeoutSeconds: 60 

   6

   
       httpRetries: 2 

   7

   
       httpRetryPauseMs: 300 

   8

   
       includeAcceptHeader: false 

   9

   1

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

   2

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

   3

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

   4

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

   5

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

   6

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

   7

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

   8

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

   9

   (선택 사항) 일부 인증 서버는 Accept: application/json 헤더를 보내는 클라이언트에 문제가 있습니다. includeAcceptHeader: false 를 설정하면 헤더가 전송되지 않습니다. 기본값은 true 입니다.

3. 구성 요소의 리소스 구성에 변경 사항을 적용합니다.

4. 로그에서 업데이트를 확인하거나 Pod 상태 전환을 확인하여 업데이트를 확인합니다.

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

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