지원콘솔개발자평가판 시작연락처

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

Apache Kafka의 스트림은 토큰 기반 인증에 OAuth 2.0 사용을 지원합니다. OAuth 2.0 권한 부여 서버는 액세스에 대한 액세스 권한 및 문의 부여를 처리합니다. Kafka 클라이언트는 Kafka 브로커에 인증합니다. 브로커 및 클라이언트는 필요에 따라 권한 부여 서버와 통신하여 액세스 토큰을 얻거나 검증합니다.

Apache Kafka용 Streams 배포를 위해 OAuth 2.0 통합에서는 다음과 같은 지원이 제공됩니다.

  • Kafka 브로커에 대한 서버 측 OAuth 2.0 인증
  • Kafka MirrorMaker, Kafka Connect 및 Kafka 브리지의 클라이언트 측 OAuth 2.0 인증

17.2.1. 리스너에서 OAuth 2.0 인증 구성
링크 복사

OAuth 2.0 인증을 사용하여 Kafka 브로커를 보호하려면 OAUth 2.0 인증 및 클라이언트 인증 메커니즘을 사용하도록 Kafka 리소스에서 리스너를 구성하고 인증에 사용되는 인증 메커니즘 및 토큰 검증 유형에 따라 추가 구성을 추가합니다.

oauth 인증을 사용하도록 리스너 구성

oauth 인증 유형을 사용하여 Kafka 리소스에서 리스너를 지정합니다. 내부 및 외부 리스너를 구성할 수 있습니다. TLS 암호화와 함께 OAuth 2.0 인증을 사용하는 것이 좋습니다(tls: true). 암호화 없이 연결은 토큰 도난을 통해 네트워크 도청 및 무단 액세스에 취약합니다.

OAuth 2.0 인증을 사용한 리스너 구성 예

apiVersion: kafka.strimzi.io/v1beta2
kind: Kafka
spec:
  kafka:
    # ...
    listeners:
      - name: tls
        port: 9093
        type: internal
        tls: true
        authentication:
          type: oauth
      - name: external3
        port: 9094
        type: loadbalancer
        tls: true
        authentication:
          type: oauth
      #...

SASL 인증 메커니즘 활성화

클라이언트가 인증 정보를 교환하고 Kafka로 인증된 세션을 설정하는 데 다음 SASL 메커니즘 중 하나 또는 둘 다를 사용합니다.

OAUTHBEARER

인증 정보 교환은 OAUTHBEARER 인증 메커니즘을 사용하여 OAuth 콜백 처리기에서 제공하는 전달자 토큰을 사용합니다. 다음 방법을 사용하도록 토큰 프로비저닝을 구성할 수 있습니다.

  • 클라이언트 ID 및 시크릿( OAuth 2.0 클라이언트 인증 정보 메커니즘사용)
  • 클라이언트 ID 및 클라이언트 어설션
  • 장기 액세스 토큰 또는 서비스 계정 토큰
  • 수명이 긴 새로 고침 토큰을 수동으로 가져 오기

OAUTHBEARER 는 PLAIN 보다 높은 수준의 보안을 제공하지만 프로토콜 수준에서 OAUTHBEARER 메커니즘을 지원하는 Kafka 클라이언트에서만 사용할 수 있습니다. 클라이언트 인증 정보는 Kafka와 공유되지 않습니다.

PLAIN

PLAIN 은 모든 Kafka 클라이언트 툴에서 사용하는 간단한 인증 메커니즘입니다. OAUTHBEARER 를 지원하지 않는 Kafka 클라이언트에서만 PLAIN 을 사용하는 것이 좋습니다. PLAIN 인증 메커니즘을 사용하여 다음 방법을 사용하도록 인증 정보 교환을 구성할 수 있습니다.

  • 클라이언트 ID 및 시크릿( OAuth 2.0 클라이언트 인증 정보 메커니즘사용)
  • 장기 액세스 토큰
    사용된 방법 중 없이 클라이언트가 Kafka에 사용자 이름과 암호 속성을 제공해야 합니다.

인증 정보는 OAUTHBEARER 인증 사용과 유사한 호환 권한 부여 서버 뒤에서 중앙 집중식으로 처리됩니다. 사용자 이름 추출 프로세스는 권한 부여 서버 구성에 따라 다릅니다.

OAUTHBEARER 는 Kafka 브로커의 oauth 리스너 구성에서 자동으로 활성화됩니다. PLAIN 메커니즘을 사용하려면 enablePlain 속성을 true 로 설정해야 합니다.

다음 예제에서는 PLAIN 메커니즘이 활성화되고 enableOauthBearer 속성을 사용하여 리스너에서 OAUTHBEARER 메커니즘이 비활성화됩니다.

PLAIN 메커니즘에 대한 리스너 구성의 예

apiVersion: kafka.strimzi.io/v1beta2
kind: Kafka
spec:
  kafka:
    # ...
    listeners:
      - name: tls
        port: 9093
        type: internal
        tls: true
        authentication:
          type: oauth
      - name: external3
        port: 9094
        type: loadbalancer
        tls: true
        authentication:
          type: oauth
          enablePlain: true
          enableOauthBearer: false
      #...

인증 유형을 OAuth 2.0으로 정의한 경우 인트로스펙션 엔드포인트를 사용하여 빠른 로컬 JWT 검증 또는 토큰 검증으로 검증 유형에 따라 구성을 추가합니다.

빠른 로컬 JWT 토큰 검증 구성

빠른 로컬 JWT 토큰 검증은 토큰이 다음 기준을 충족하는지 확인하기 위해 로컬에서 JWT 토큰 서명을 확인하는 것입니다.

  • Bearer 의 typ (type) 또는 token_type 헤더 클레임 값을 포함하여 액세스 토큰임을 나타냅니다.
  • 현재 유효하고 만료되지 않음
  • 유효한IssuerURI와 일치하는 발행자가 있음

리스너를 구성할 때 권한 부여 서버가 발행하지 않은 모든 토큰이 거부되도록 유효한IssuerURI 속성을 지정합니다.

빠른 로컬 JWT 토큰 검증 중에 권한 부여 서버에 연결할 필요가 없습니다. OAuth 2.0 권한 부여 서버에서 노출하는 끝점인 jwksEndpointUri 속성을 지정하여 빠른 로컬 JWT 토큰 검증을 활성화합니다. 엔드포인트에는 Kafka 클라이언트가 인증 정보로 전송되는 서명된 JWT 토큰의 유효성을 검사하는 데 사용되는 공개 키가 포함되어 있습니다.

권한 부여 서버와의 모든 통신은 TLS 암호화를 사용하여 수행해야 합니다. 인증서 신뢰 저장소를 Apache Kafka 프로젝트 네임스페이스의 Streams에서 OpenShift Secret 으로 구성하고 tlsTrustedCertificates 속성을 사용하여 truststore 파일이 포함된 OpenShift 시크릿을 가리킬 수 있습니다.

JWT 토큰에서 사용자 이름을 올바르게 추출하도록 userNameClaim 을 구성할 수 있습니다. 필요한 경우 "['user.info'].['user.id']" 와 같은 JsonPath 표현식을 사용하여 토큰 내의 중첩된 JSON 속성에서 사용자 이름을 검색할 수 있습니다.

Kafka ACL 권한 부여를 사용하려면 인증 중에 사용자 이름으로 사용자를 식별합니다. ( JWT 토큰의 하위 클레임은 일반적으로 사용자 이름이 아닌 고유 ID입니다.)

빠른 로컬 JWT 토큰 검증을 위한 구성 예

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

    validIssuerUri: https://<auth_server_address>/<issuer-context>
2 

    jwksEndpointUri: https://<auth_server_address>/<path_to_jwks_endpoint>
3 

    userNameClaim: preferred_username
4 

    maxSecondsWithoutReauthentication: 3600
5 

    tlsTrustedCertificates:
6 

      - secretName: oauth-server-cert
        pattern: "*.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 연결에 대해 지정된 시크릿 내에서 X.509 형식으로 저장된 인증서입니다.
7
(선택 사항) TLS 호스트 이름 확인을 비활성화합니다. 기본값은 false 입니다.
8
JWKS 인증서가 만료되기 전에 유효한 인증서로 간주됩니다. 기본값은 360 초입니다. 더 긴 시간을 지정하면 취소된 인증서에 대한 액세스를 허용할 위험을 고려하십시오.
9
JWKS 인증서 새로 고침 간격입니다. 간격은 만료 간격보다 60초 이상 짧아야 합니다. 기본값은 300 초입니다.
10
JWKS 공개 키를 새로 고치는 시도 사이의 최소 일시 중지 시간(초)입니다. 알 수 없는 서명 키가 발생하면 JWKS 키 새로 고침이 마지막 새로 고침 시도 이후 지정된 일시 중지를 사용하여 정기적인 스케줄 외부에 예약됩니다. 키를 새로 고치는 것은 지수 백오프 규칙을 따르며 jwksRefreshSeconds 에 도달할 때까지 일시 중지를 늘리면 실패한 새로 고침을 다시 시도합니다. 기본값은 1입니다.

OpenShift 서비스 계정을 사용하여 빠른 로컬 JWT 토큰 검증 구성

OpenShift 서비스 계정에 대한 리스너를 구성하려면 Kubernetes API 서버를 권한 부여 서버로 사용해야 합니다.

인증 서버로 Kubernetes API 서버를 사용하여 빠른 로컬 JWT 토큰 검증을 위한 구성의 예

#...
- name: external3
  port: 9094
  type: loadbalancer
  tls: true
  authentication:
    type: oauth
    validIssuerUri: https://kubernetes.default.svc.cluster.local
1 

    jwksEndpointUri: https://kubernetes.default.svc.cluster.local/openid/v1/jwks
2 

    serverBearerTokenLocation: /var/run/secrets/kubernetes.io/serviceaccount/token
3 

    checkAccessTokenType: false
4 

    includeAcceptHeader: false
5 

    tlsTrustedCertificates:
6 

      - secretName: oauth-server-cert
        pattern: "*.crt"
    maxSecondsWithoutReauthentication: 3600
    customClaimCheck: "@.['kubernetes.io'] && @.['kubernetes.io'].['namespace'] in ['myproject']"
7

1
인증에 사용되는 토큰 발행자의 URI입니다. OpenShift 클러스터 구성에 따라 다를 수 있는 .cluster.local 확장을 포함하여 FQDN을 사용해야 합니다.
2
로컬 JWT 검증에 사용되는 JWKS 인증서 끝점의 URI입니다. OpenShift 클러스터 구성에 따라 다를 수 있는 .cluster.local 확장을 포함하여 FQDN을 사용해야 합니다.
3
jwksEndpointUri 에 액세스하기 위해 Kafka 브로커가 사용하는 액세스 토큰의 위치입니다.
4
서비스 계정 토큰에 대한 클레임이 없으므로 액세스 토큰 유형 검사를 건너뜁니다.
5
Kubernetes API 서버가 지원하지 않기 때문에 HTTP 요청의 Accept 헤더를 JWKS 엔드포인트로 보내는 것을 건너뜁니다.
6
권한 부여 서버에 연결하기 위한 신뢰할 수 있는 인증서입니다. 이렇게 하면 /var/run/secrets/kubernetes.io/serviceaccount/ca.crt 에서 실행 중인 Pod에 마운트되는 Kubernetes API 서버 공용 인증서가 포함된 수동으로 생성된 Secret을 가리켜야 합니다. 다음 명령을 사용하여 보안을 생성할 수 있습니다. 
oc get cm kube-root-ca.crt -o jsonpath="{['data']['ca\.crt']}" > /tmp/ca.crt
oc create secret generic oauth-server-cert --from-file=ca.crt=/tmp/ca.crt
7
(선택 사항) JWT 토큰이 JsonPath 필터 쿼리로 표현되기 위해 수행해야 하는 추가 제약 조건입니다. 이 예에서 서비스 계정은 인증할 수 있도록 myproject 네임스페이스에 속해야 합니다.

위의 구성에서는 서비스 계정 JWT 토큰의 하위 클레임을 사용자 ID로 사용합니다. 예를 들어 myproject 네임스페이스에 배포된 Pod의 기본 서비스 계정에는 username: system:serviceaccount:myproject:default 가 있습니다.

ACL을 구성하는 경우 ServiceAccount 사용자를 참조하는 방법의 일반 양식은 다음과 같습니다: User:system:serviceaccount:<Namespace>:<ServiceAccount-name>

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

OAuth 2.0 인트로스펙션 엔드포인트를 사용하는 토큰 검증은 수신된 액세스 토큰을 불투명으로 처리합니다. Kafka 브로커는 검증에 필요한 토큰 정보로 응답하는 인트로스펙션 엔드포인트에 액세스 토큰 토큰을 보냅니다. 중요한 것은 특정 액세스 토큰이 유효한 경우 최신 정보와 토큰이 만료되는 시기에 대한 정보를 반환합니다.

OAuth 2.0 인트로스펙션 기반 검증을 구성하려면 빠른 로컬 JWT 토큰 검증에 지정된 jwksEndpointUri 속성 대신 introspectionEndpointUri 속성을 지정합니다. 인증 서버에 따라 인트로스펙션 엔드포인트가 일반적으로 보호되므로 clientId 및 clientSecret 을 지정해야 합니다.

인트로스펙션 끝점을 사용한 토큰 검증 구성 예

- name: external3
  port: 9094
  type: loadbalancer
  tls: true
  authentication:
    type: oauth
    validIssuerUri: https://<auth_server_address>/<issuer-context>
    introspectionEndpointUri: https://<auth_server_address>/<path_to_introspection_endpoint>
1 

    clientId: kafka-broker
2 

    clientSecret:
3 

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

    maxSecondsWithoutReauthentication: 3600
5 

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

1
토큰 인트로스펙션 엔드포인트의 URI입니다.
2
클라이언트를 식별하는 클라이언트 ID입니다.
3
클라이언트 시크릿 및 클라이언트 ID는 인증에 사용됩니다.
4
사용자를 식별하는 데 사용되는 실제 사용자 이름을 포함하는 토큰 클레임(또는 키)입니다. 해당 값은 권한 부여 서버에 따라 다릅니다. 필요한 경우 "['user.info'].['user.id']" 와 같은 JsonPath 표현식을 사용하여 토큰 내의 중첩된 JSON 속성에서 사용자 이름을 검색할 수 있습니다.
5
(선택 사항) 액세스 토큰과 동일한 기간에 세션 만료를 적용하는 Kafka 재인증 메커니즘을 활성화합니다. 지정된 값이 액세스 토큰이 만료될 때까지 남은 시간보다 작으면 클라이언트는 실제 토큰 만료 전에 다시 인증해야 합니다. 기본적으로 액세스 토큰이 만료되고 클라이언트가 재인증을 시도하지 않으면 세션이 만료되지 않습니다.

권한 부여 서버 보호 엔드 포인트에 브로커 인증

일반적으로 인증 서버의 인증서 끝점(jwksEndpointUri)은 공개적으로 액세스할 수 있는 반면 인트로스펙션 엔드 포인트(introspectionEndpointUri)는 보호됩니다. 그러나 권한 부여 서버 구성에 따라 달라질 수 있습니다.

Kafka 브로커는 HTTP 인증 체계를 사용하는 두 가지 방법 중 하나로 권한 부여 서버의 보호 엔드포인트에 인증할 수 있습니다.

  • HTTP 기본 인증은 클라이언트 ID와 시크릿을 사용합니다.
  • HTTP 전달자 인증은 전달자 토큰을 사용합니다.

HTTP 기본 인증을 구성하려면 다음 속성을 설정합니다.

  • clientId
  • clientSecret

HTTP 전달자 인증의 경우 다음 속성을 설정합니다.

  • serverBearerTokenLocation: 전달자 토큰이 포함된 디스크에서 파일 경로를 지정합니다.

추가 구성 옵션 포함

인증 요구 사항 및 사용 중인 권한 부여 서버에 따라 추가 설정을 지정합니다. 이러한 속성 중 일부는 특정 인증 메커니즘에만 적용되거나 다른 속성과 함께 사용되는 경우만 적용됩니다.

예를 들어 PLAIN 을 통해 OAUth를 사용하는 경우 액세스 토큰은 $accessToken: 접두사를 사용하거나 사용하지 않고 password 속성 값으로 전달됩니다.

  • 리스너 구성에서 토큰 끝점(tokenEndpointUri)을 구성하는 경우 접두사가 필요합니다.
  • 리스너 구성에서 토큰 끝점을 구성하지 않으면 접두사가 필요하지 않습니다. Kafka 브로커는 암호를 원시 액세스 토큰으로 해석합니다.

암호 가 액세스 토큰으로 설정된 경우 사용자 이름은 Kafka 브로커가 액세스 토큰에서 얻는 것과 동일한 주체 이름으로 설정해야 합니다. userNameClaim,usernamePrefix,fallbackUserNameClaim,fallbackUsernamePrefix, userInfoEndpointUri 속성을 사용하여 리스너에서 사용자 이름 추출 옵션을 지정할 수 있습니다. 사용자 이름 추출 프로세스는 권한 부여 서버(특히 클라이언트 ID를 계정 이름에 매핑하는 방법)에 따라 다릅니다.

참고

PLAIN 메커니즘은 암호 부여 인증을 지원하지 않습니다. 클라이언트 인증 정보(클라이언트 ID + 시크릿) 또는 인증에 대한 액세스 토큰을 사용합니다.

선택적 구성 설정 예

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

    checkAudience: true
2 

    usernamePrefix: user-
3 

    fallbackUserNameClaim: client_id
4 

    fallbackUserNamePrefix: client-account-
5 

    serverBearerTokenLocation: path/to/access/token
6 

    validTokenType: bearer
7 

    userInfoEndpointUri: https://<auth_server_address>/<path_to_userinfo_endpoint>
8 

    enableOauthBearer: false
9 

    enablePlain: true
10 

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

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

    clientAudience: audience
13 

    clientScope: scope
14 

    connectTimeoutSeconds: 60
15 

    readTimeoutSeconds: 60
16 

    httpRetries: 2
17 

    httpRetryPauseMs: 300
18 

    groupsClaim: "$.groups"
19 

    groupsClaimDelimiter: ","
20 

    includeAcceptHeader: false
21

1
권한 부여 서버에서 iss 클레임을 제공하지 않으면 발급자 검사를 수행할 수 없습니다. 이 경우 checkIssuer 를 false 로 설정하고 유효한IssuerUri 를 지정하지 마십시오. 기본값은 true 입니다.
2
권한 부여 서버가 aud (audience) 클레임을 제공하고 대상 검사를 적용하려는 경우 checkAudience 를 true 로 설정합니다. 대상 검사에서는 의도된 토큰 수신자를 식별합니다. 결과적으로 Kafka 브로커는 aud 클레임에 clientId 가 없는 토큰을 거부합니다. 기본값은 false 입니다.
3
사용자 ID를 구성할 때 사용되는 접두사입니다. 이는 userNameClaim 이 구성된 경우에만 적용됩니다.
4
권한 부여 서버는 일반 사용자와 클라이언트를 모두 식별하는 단일 속성을 제공하지 않을 수 있습니다. 클라이언트가 자체 이름으로 인증하면 서버에서 클라이언트 ID 를 제공할 수 있습니다. 사용자가 사용자 이름과 암호를 사용하여 새로 고침 토큰 또는 액세스 토큰을 가져오는 경우 서버는 클라이언트 ID 외에도 사용자 이름 속성을 제공할 수 있습니다. 기본 사용자 ID 속성을 사용할 수 없는 경우 사용할 사용자 이름 클레임(attribute)을 지정하려면 이 대체 옵션을 사용합니다. 필요한 경우 "['client.info'].['client.id']" 와 같은 JsonPath 표현식을 사용하여 대체 사용자 이름을 검색하여 토큰 내의 중첩된 JSON 속성에서 사용자 이름을 검색할 수 있습니다.
5
fallbackUserNameClaim 이 적용 가능한 경우 사용자 이름 클레임의 값과 대체 사용자 이름 클레임의 이름 충돌을 방지할 수도 있습니다. producer 라는 클라이언트가 존재하지만 producer 라는 일반 사용자도 존재하는 상황을 고려하십시오. 이 속성을 사용하여 클라이언트의 사용자 ID에 접두사를 추가할 수 있습니다.
6
Kafka 브로커가 보호된 엔드포인트에 액세스하기 위해 Kubernetes API 서버를 인증하는 데 사용하는 액세스 토큰의 위치입니다. 권한 부여 서버는 OAUTHBEARER 인증을 지원해야 합니다. 이는 PLAIN 인증을 사용하는 clientId 및 clientSecret 을 지정하는 대안입니다.
7
( introspectionEndpointUri) 사용 중인 권한 부여 서버에 따라 인트로스펙션 엔드 포인트가 토큰 유형 속성을 반환하거나 반환하지 않거나 다른 값을 포함할 수 있습니다. 인트로스펙션 끝점의 응답에 포함되어야 하는 유효한 토큰 유형 값을 지정할 수 있습니다.
8
( introspectionEndpointUri를 사용하는 경우에만 적용됨) 인증 서버가 인트로스펙션 엔드포인트 응답에서 식별 가능한 정보를 제공하지 않도록 인증 서버를 구성하거나 구현할 수 있습니다. 사용자 ID를 얻으려면 userinfo 끝점의 URI를 폴백으로 구성할 수 있습니다. userNameClaim,fallbackUserNameClaim 및 fallbackUserNamePrefix 설정은 userinfo 끝점 응답에 적용됩니다.
9
리스너에서 OAUTHBEARER 메커니즘을 비활성화하려면 이를 false 로 설정합니다. PLAIN 또는 OAUTHBEARER 중 하나 이상을 활성화해야 합니다. 기본값은 true 입니다.
10
모든 플랫폼에서 클라이언트에 지원되는 리스너에서 PLAIN 인증을 활성화하려면 true 로 설정합니다.
11
PLAIN 메커니즘에 대한 추가 구성입니다. 지정된 경우 클라이언트는 $accessToken: 접두사를 사용하여 암호로 액세스 토큰을 전달하여 PLAIN 을 통해 인증할 수 있습니다. 프로덕션의 경우 항상 https:// urls를 사용합니다.
12
이를 JsonPath 필터 쿼리로 설정하여 검증 중에 JWT 액세스 토큰에 추가 사용자 지정 규칙을 적용할 수 있습니다. 액세스 토큰에 필요한 데이터가 포함되어 있지 않으면 거부됩니다. introspectionEndpointUri 를 사용하는 경우 사용자 정의 검사가 인트로스펙션 엔드포인트 응답 JSON에 적용됩니다.
13
토큰 끝점에 전달된 audience 매개변수입니다. 대상 은broker 간 인증을 위한 액세스 토큰을 가져올 때 사용됩니다. clientId 및 secret 을 사용하는 PLAIN 클라이언트 인증의 OAuth 2.0용 클라이언트 이름에도 사용됩니다. 이는 권한 부여 서버에 따라 토큰과 토큰의 콘텐츠에만 영향을 미칩니다. 리스너의 토큰 검증 규칙에는 영향을 미치지 않습니다.
14
토큰 끝점에 전달된 scope 매개변수입니다. 범위는 broker 간 인증을 위한 액세스 토큰을 가져올 때 사용됩니다. clientId 및 secret 을 사용하는 PLAIN 클라이언트 인증의 OAuth 2.0용 클라이언트 이름에도 사용됩니다. 이는 권한 부여 서버에 따라 토큰과 토큰의 콘텐츠에만 영향을 미칩니다. 리스너의 토큰 검증 규칙에는 영향을 미치지 않습니다.
15
권한 부여 서버에 연결할 때 연결 시간(초)입니다. 기본값은 60입니다.
16
권한 부여 서버에 연결할 때 읽기 제한 시간(초)입니다. 기본값은 60입니다.
17
권한 부여 서버에 실패한 HTTP 요청을 재시도하는 최대 횟수입니다. 기본값은 0 입니다. 즉, 재시도가 수행되지 않습니다. 이 옵션을 효과적으로 사용하려면 connectTimeoutSeconds 및 readTimeoutSeconds 옵션의 시간 초과 시간을 줄이는 것이 좋습니다. 그러나 재시도하면 현재 작업자 스레드를 다른 요청에 사용할 수 없게 될 수 있으며 요청이 너무 많으면 Kafka 브로커가 응답하지 않을 수 있습니다.
18
권한 부여 서버에 실패한 HTTP 요청을 다시 시도하기 전에 대기하는 시간입니다. 기본적으로 이 시간은 0으로 설정되어 있으므로 일시 중지가 적용되지 않습니다. 이는 실패한 요청을 유발하는 많은 문제가 요청당 네트워크 결함 또는 프록시 문제로 인해 신속하게 해결할 수 있기 때문입니다. 그러나 권한 부여 서버가 과부하가 발생하거나 트래픽이 많은 경우 이 옵션을 100ms 이상으로 설정하여 서버의 부하를 줄이고 성공적인 재시도 가능성을 높일 수 있습니다.
19
JWT 토큰 또는 인트로스펙션 엔드포인트 응답에서 그룹 정보를 추출하는 데 사용되는 JsonPath 쿼리입니다. 이 옵션은 기본적으로 설정되어 있지 않습니다. 이 옵션을 구성하면 사용자 정의 작성자가 사용자 그룹을 기반으로 권한 부여 결정을 내릴 수 있습니다.
20
그룹으로 구분된 단일 문자열로 반환될 때 그룹 정보를 구문 분석하는 데 사용되는 구분 기호입니다. 기본값은 ',' (comma)입니다.
21
일부 인증 서버는 Accept: application/json 헤더를 보내는 클라이언트에 문제가 있습니다. includeAcceptHeader: false 를 설정하면 헤더가 전송되지 않습니다. 기본값은 true 입니다.
Red Hat logoGithubRedditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 소개

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

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

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

Red Hat 문서 정보

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

Legal Notice

Theme

© 2026 Red Hat맨 위로 이동