검색

4장. 추가 개념

download PDF

4.1. 인증

4.1.1. 개요

그러면 인증 계층에서 OpenShift Container Platform API에 대한 요청과 관련된 사용자를 확인합니다. 그런 다음 권한 부여 계층에서는 요청하는 사용자에 대한 정보를 사용하여 요청을 허용해야 하는지 여부를 결정합니다.

관리자는 마스터 구성 파일을 사용하여 인증을 구성할 수 있습니다.

4.1.2. 사용자 및 그룹

OpenShift Container Platform에서 사용자는 OpenShift Container Platform API에 요청할 수 있는 엔티티입니다. 일반적으로 OpenShift Container Platform과 상호 작용하는 개발자 또는 관리자 계정을 의미합니다.

사용자는 하나 이상의 그룹에 할당될 수 있으며, 각 그룹은 특정 사용자 집합을 나타냅니다. 그룹은 사용자에게 개별적으로 부여하는 대신 권한 부여 정책을 관리하여 여러 사용자에게 한 번에 권한을 부여할 때 유용합니다(예: 프로젝트오브젝트에 대한 액세스 허용).

명시적으로 정의된 그룹 외에도 OpenShift에서 자동으로 프로비저닝하는 시스템 그룹 또는 가상 그룹이 있습니다. 클러스터 바인딩을 볼 때 볼 수 있습니다.

가상 그룹의 기본 집합에서는 특히 다음 사항에 유의하십시오.

가상 그룹설명

system:authenticated

인증된 모든 사용자와 자동으로 연결됩니다.

system:authenticated:oauth

OAuth 액세스 토큰을 사용하여 인증된 모든 사용자와 자동으로 연결됩니다.

system:unauthenticated

인증되지 않은 모든 사용자와 자동으로 연결됩니다.

4.1.3. API 인증

OpenShift Container Platform API에 대한 요청은 다음과 같은 방법으로 인증됩니다.

OAuth 액세스 토큰
  • <master> /oauth/authorize 및 <master> /oauth/token 끝점을 사용하여 OpenShift Container Platform OAuth 서버에서 가져옵니다.
  • 인증: 전달자…​ 헤더.
  • WebSocket 요청의 경우 base64url.bearer.authorization.k8s.io.<base64url-encoded-token> 형식의 WebSocket 하위 프로토콜 헤더로 전송됩니다.
X.509 클라이언트 인증서
  • API 서버에 대한 HTTPS 연결이 필요합니다.
  • 신뢰할 수 있는 인증 기관 번들과 대조하여 API 서버에서 확인합니다.
  • API 서버는 인증서를 작성하고 컨트롤러에 분배하여 자체적으로 인증합니다.

유효하지 않은 액세스 토큰 또는 유효하지 않은 인증서가 있는 요청은 401 오류와 함께 인증 계층에서 거부됩니다.

액세스 토큰이나 인증서가 없는 경우 인증 계층은 system:anonymous 가상 사용자 및 system:unauthenticated 가상 그룹을 요청에 할당합니다. 그러면 권한 부여 계층에서 익명 사용자가 할 수 있는 요청(있는 경우)을 결정합니다.

4.1.3.1. 가장

OpenShift Container Platform API 요청에는 Impersonate-User 헤더가 포함될 수 있습니다. 이 헤더는 요청자가 지정된 사용자로부터 온 것처럼 요청을 처리하려고 함을 나타냅니다. 요청에 --as=<user> 플래그를 추가하여 사용자를 가장합니다.

사용자 A가 사용자 B를 가장할 수 있으려면 사용자 A가 인증됩니다. 그런 다음 권한 부여 확인이 발생하여 사용자 A가 User B라는 사용자를 가장할 수 있는지 확인합니다. 사용자 A가 서비스 계정을 가장하도록 요청하는 경우 system:serviceaccount:namespace:name 은 OpenShift Container Platform에서 User A가 이름이serviceaccount네임스페이스 에서 가장할 수 있는지 확인합니다. 검사에 실패하면 403(Forbidden) 오류 코드와 함께 요청이 실패합니다.

기본적으로 프로젝트 관리자 및 편집기는 해당 네임스페이스의 서비스 계정을 가장할 수 있습니다. sudoers 역할을 사용하면 system:admin 을 가장할 수 있으며, 이로 인해 클러스터 관리자 권한이 부여됩니다. system:admin 은 클러스터를 관리하는 사용자를 위해 보안이 아닌 오타에 대해 일부 보호 권한을 부여합니다. 예를 들어 oc delete nodes --all 을 실행하면 실패하지만 oc delete nodes --all --as=system:admin 을 실행하면 성공합니다. 다음 명령을 실행하여 권한을 사용자에게 부여할 수 있습니다.

$ oc create clusterrolebinding <any_valid_name> --clusterrole=sudoer --user=<username>

사용자를 대신하여 프로젝트 요청을 생성해야 하는 경우 명령에 --as=<user> --as-group=<group1> --as-group=<group2> 플래그를 포함합니다. system:authenticated:oauth 는 프로젝트 요청을 생성할 수 있는 유일한 부트스트랩 그룹이므로 다음 예와 같이 해당 그룹을 가장해야 합니다.

$ oc new-project <project> --as=<user> \
--as-group=system:authenticated --as-group=system:authenticated:oauth

4.1.4. OAuth

OpenShift Container Platform 마스터에는 내장 OAuth 서버가 포함되어 있습니다. 사용자는 API 인증을 위해 OAuth 액세스 토큰을 가져옵니다.

사용자가 새 OAuth 토큰을 요청하면 OAuth 서버는 구성된 ID 공급자를 사용하여 요청한 사용자의 ID를 확인합니다.

그런 다음 해당 ID와 매핑되는 사용자를 결정하고 그 사용자를 위한 액세스 토큰을 만들어 제공합니다.

4.1.4.1. OAuth 클라이언트

OAuth 토큰을 요청할 때마다 토큰을 받고 사용할 OAuth 클라이언트를 지정해야 합니다. OpenShift Container Platform API를 시작하면 다음 OAuth 클라이언트가 자동으로 생성됩니다.

OAuth 클라이언트사용법

openshift-web-console

웹 콘솔의 토큰을 요청합니다.

openshift-browser-client

대화형 로그인을 처리할 수 있는 사용자 에이전트를 사용하여 <master>/oauth/token/request 에서 토큰을 요청합니다.

openshift-challenging-client

WWW-Authenticate 챌린지를 처리할 수 있는 사용자 에이전트로 토큰을 요청합니다.

추가 클라이언트를 등록하려면 다음을 수행합니다.

$ oc create -f <(echo '
kind: OAuthClient
apiVersion: oauth.openshift.io/v1
metadata:
 name: demo 1
secret: "..." 2
redirectURIs:
 - "http://www.example.com/" 3
grantMethod: prompt 4
')
1
OAuth 클라이언트의 이름은 <master> /oauth/authorize 및 <master> /oauth/token 에 요청할 때 client_id 매개변수로 사용됩니다.
2
secret<master>/oauth/token 에 요청할 때 client_secret 매개변수로 사용됩니다.
3
<master> /oauth/authorize 및 < master>/oauth/token 에 대한 요청에 지정된 redirect_uri 매개변수는 redirectURIs 의 URI 중 하나와 같아야 합니다.
4
grantMethod는 이 클라이언트에서 토큰을 요청할 때 사용자가 아직 액세스 권한을 부여받지 않은 경우 수행할 조치를 결정하는 데 사용됩니다. grant Options(제한 옵션)에 표시되는 동일한 값을 사용합니다.

4.1.4.2. OAuth 클라이언트로서의 서비스 계정

서비스 계정은 제한된 형태의 OAuth 클라이언트로 사용할 수 있습니다. 서비스 계정은 서비스 계정의 자체 네임스페이스 내에서 일부 기본 사용자 정보 및 역할 기반 권한에 액세스할 수 있는 부분만 요청할 수 있습니다.

  • user:info
  • user:check-access
  • role:<any_role>:<serviceaccount_namespace>
  • role:<any_role>:<serviceaccount_namespace>:!

서비스 계정을 OAuth 클라이언트로 사용하는 경우에는 다음과 같습니다.

  • client_idsystem:serviceaccount:<serviceaccount_namespace>:<serviceaccount_name>입니다.
  • client_secret은 해당 서비스 계정의 API 토큰 중 하나일 수 있습니다. 예를 들면 다음과 같습니다.

    $ oc sa get-token <serviceaccount_name>
  • WWW-Authenticate 챌린지를 가져오려면 서비스 계정의 serviceaccounts.openshift.io/oauth-want-challenges 주석을 true로 설정합니다.
  • redirect_uri는 서비스 계정의 주석과 일치해야 합니다. 서비스 계정의 URI를 OAuth 클라이언트에서 자세한 정보를 제공하므로 리디렉션합니다.

4.1.4.3. 서비스 계정의 URI를 OAuth 클라이언트로 리디렉션

주석 키에는 접두사 serviceaccounts.openshift.io/oauth-redirecturi. 또는 serviceaccounts.openshift.io/oauth-redirectreference.가 있어야 합니다. 예를 들면 다음과 같습니다.

serviceaccounts.openshift.io/oauth-redirecturi.<name>

가장 간단한 형식의 주석을 사용하여 유효한 리디렉션 URI를 직접 지정할 수 있습니다. 예를 들면 다음과 같습니다.

"serviceaccounts.openshift.io/oauth-redirecturi.first":  "https://example.com"
"serviceaccounts.openshift.io/oauth-redirecturi.second": "https://other.com"

위 예에서 firstsecond라는 접미사는 두 개의 유효한 리디렉션 URI를 구분하는 데 사용됩니다.

복잡한 구성에서는 정적 리디렉션 URI로는 충분하지 않을 수 있습니다. 예를 들어 경로의 모든 인그레스가 유효한 것으로 간주될 수 있습니다. 이 경우 serviceaccounts.openshift.io/oauth-redirectreference 접두사를 통한 동적 리디렉션 URI가 작동합니다.

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

"serviceaccounts.openshift.io/oauth-redirectreference.first": "{\"kind\":\"OAuthRedirectReference\",\"apiVersion\":\"v1\",\"reference\":{\"kind\":\"Route\",\"name\":\"jenkins\"}}"

이 주석의 값은 직렬화된 JSON 데이터를 포함하므로 확장된 형식으로 쉽게 볼 수 있습니다.

{
  "kind": "OAuthRedirectReference",
  "apiVersion": "v1",
  "reference": {
    "kind": "Route",
    "name": "jenkins"
  }
}

이제 OAuthRedirectReference를 통해 jenkins라는 경로를 참조할 수 있음을 확인할 수 있습니다. 따라서 해당 경로의 모든 인그레스가 이제 유효한 것으로 간주됩니다. OAuthRedirectReference의 전체 사양은 다음과 같습니다.

{
  "kind": "OAuthRedirectReference",
  "apiVersion": "v1",
  "reference": {
    "kind": ..., 1
    "name": ..., 2
    "group": ... 3
  }
}
1
kind는 참조되는 오브젝트의 유형을 나타냅니다. 현재는 route만 지원됩니다.
2
name은 오브젝트의 이름을 나타냅니다. 오브젝트는 서비스 계정과 동일한 네임스페이스에 있어야 합니다.
3
group은 오브젝트 그룹을 나타냅니다. 경로 그룹이 빈 문자열이므로 이 필드를 비워둡니다.

두 주석 접두사를 결합하여 참조 오브젝트에서 제공하는 데이터를 덮어쓸 수 있습니다. 예를 들면 다음과 같습니다.

"serviceaccounts.openshift.io/oauth-redirecturi.first":  "custompath"
"serviceaccounts.openshift.io/oauth-redirectreference.first": "{\"kind\":\"OAuthRedirectReference\",\"apiVersion\":\"v1\",\"reference\":{\"kind\":\"Route\",\"name\":\"jenkins\"}}"

first 접미사는 주석을 연결하는 데 사용됩니다. jenkins 경로에 https://example.com 의 인그레스가 있다고 가정하면 이제 https://example.com/custompath 은 유효한 것으로 간주되지만 https://example.com 은 유효한 것으로 간주되지 않습니다. 데이터 덮어쓰기를 부분적으로 제공하는 형식은 다음과 같습니다.

유형구문

스키마

"https://"

호스트 이름

"//website.com"

포트

"//:8000"

경로

"examplepath"

참고

호스트 이름 덮어쓰기를 지정하면 참조된 오브젝트의 호스트 이름 데이터가 교체되며 이는 바람직한 동작이 아닙니다.

위 구문의 모든 조합은 다음과 같은 형식을 사용하여 결합할 수 있습니다.

<scheme:>//<hostname><:port>/<path>

유연성을 개선하기 위해 동일한 오브젝트를 두 번 이상 참조할 수 있습니다.

"serviceaccounts.openshift.io/oauth-redirecturi.first":  "custompath"
"serviceaccounts.openshift.io/oauth-redirectreference.first": "{\"kind\":\"OAuthRedirectReference\",\"apiVersion\":\"v1\",\"reference\":{\"kind\":\"Route\",\"name\":\"jenkins\"}}"
"serviceaccounts.openshift.io/oauth-redirecturi.second":  "//:8000"
"serviceaccounts.openshift.io/oauth-redirectreference.second": "{\"kind\":\"OAuthRedirectReference\",\"apiVersion\":\"v1\",\"reference\":{\"kind\":\"Route\",\"name\":\"jenkins\"}}"

jenkins 라는 경로에 https://example.com 수신이 있다고 가정하면 https://example.com:8000https://example.com/custompath 가 모두 유효한 것으로 간주됩니다.

정적 및 동적 주석을 동시에 사용하여 원하는 동작을 수행할 수 있습니다.

"serviceaccounts.openshift.io/oauth-redirectreference.first": "{\"kind\":\"OAuthRedirectReference\",\"apiVersion\":\"v1\",\"reference\":{\"kind\":\"Route\",\"name\":\"jenkins\"}}"
"serviceaccounts.openshift.io/oauth-redirecturi.second": "https://other.com"
4.1.4.3.1. OAuth에 대한 API 이벤트

경우에 따라 API 서버는 API 마스터 로그에 직접 액세스하지 않고 디버그하기 어려운 예기치 않은 조건 오류 메시지를 반환합니다. 근본적인 오류 원인은 인증되지 않은 사용자에게 서버 상태에 대한 정보를 제공하지 않기 위해 의도적으로 숨겨져 있습니다.

이러한 오류 중 일부는 서비스 계정 OAuth 구성 문제와 관련이 있습니다. 이와 같은 문제는 관리자가 아닌 사용자가 볼 수 있는 이벤트에서 발견됩니다. OAuth 중에 unexpected condition 서버 오류가 발생하면 oc get events를 실행하여 ServiceAccount에서 해당 이벤트를 확인하십시오.

다음 예는 적절한 OAuth 리디렉션 URI가 없는 서비스 계정에 대해 경고합니다.

$ oc get events | grep ServiceAccount

출력 예

1m         1m          1         proxy                    ServiceAccount                                  Warning   NoSAOAuthRedirectURIs   service-account-oauth-client-getter   system:serviceaccount:myproject:proxy has no redirectURIs; set serviceaccounts.openshift.io/oauth-redirecturi.<some-value>=<redirect> or create a dynamic URI using serviceaccounts.openshift.io/oauth-redirectreference.<some-value>=<reference>

oc describe sa/<service-account-name>을 실행하면 지정된 서비스 계정 이름과 관련된 OAuth 이벤트가 보고됩니다.

$ oc describe sa/proxy | grep -A5 Events

출력 예

Events:
  FirstSeen     LastSeen        Count   From                                    SubObjectPath   Type            Reason                  Message
  ---------     --------        -----   ----                                    -------------   --------        ------                  -------
  3m            3m              1       service-account-oauth-client-getter                     Warning         NoSAOAuthRedirectURIs   system:serviceaccount:myproject:proxy has no redirectURIs; set serviceaccounts.openshift.io/oauth-redirecturi.<some-value>=<redirect> or create a dynamic URI using serviceaccounts.openshift.io/oauth-redirectreference.<some-value>=<reference>

다음은 가능한 이벤트 오류 목록입니다.

리디렉션 URI 주석이 없거나 유효하지 않은 URI가 지정되었습니다

Reason                  Message
NoSAOAuthRedirectURIs   system:serviceaccount:myproject:proxy has no redirectURIs; set serviceaccounts.openshift.io/oauth-redirecturi.<some-value>=<redirect> or create a dynamic URI using serviceaccounts.openshift.io/oauth-redirectreference.<some-value>=<reference>

잘못된 경로가 지정되었습니다

Reason                  Message
NoSAOAuthRedirectURIs   [routes.route.openshift.io "<name>" not found, system:serviceaccount:myproject:proxy has no redirectURIs; set serviceaccounts.openshift.io/oauth-redirecturi.<some-value>=<redirect> or create a dynamic URI using serviceaccounts.openshift.io/oauth-redirectreference.<some-value>=<reference>]

유효하지 않은 참조 유형이 지정되었습니다

Reason                  Message
NoSAOAuthRedirectURIs   [no kind "<name>" is registered for version "v1", system:serviceaccount:myproject:proxy has no redirectURIs; set serviceaccounts.openshift.io/oauth-redirecturi.<some-value>=<redirect> or create a dynamic URI using serviceaccounts.openshift.io/oauth-redirectreference.<some-value>=<reference>]

SA 토큰이 없습니다

Reason                  Message
NoSAOAuthTokens         system:serviceaccount:myproject:proxy has no tokens
4.1.4.3.1.1. 잘못된 구성에서 사용되는 샘플 API 이벤트

다음 단계에서는 사용자가 손상된 상태로 전환하는 방법 한 가지와 문제를 디버그하거나 해결하는 방법을 보여줍니다.

  1. 서비스 계정을 OAuth 클라이언트로 사용하여 프로젝트를 생성합니다.

    1. 프록시 서비스 계정 오브젝트에 대한 YAML을 생성하고 경로 프록시 를 사용하는지 확인합니다.

      $ vi serviceaccount.yaml

      다음 샘플 코드를 추가합니다.

      apiVersion: v1
      kind: ServiceAccount
      metadata:
        name: proxy
        annotations:
          serviceaccounts.openshift.io/oauth-redirectreference.primary: '{"kind":"OAuthRedirectReference","apiVersion":"v1","reference":{"kind":"Route","name":"proxy"}}'
    2. 경로 오브젝트에 대한 YAML을 생성하여 프록시에 대한 보안 연결을 생성합니다.

      $ vi route.yaml

      다음 샘플 코드를 추가합니다.

      apiVersion: route.openshift.io/v1
      kind: Route
      metadata:
        name: proxy
      spec:
        to:
          name: proxy
        tls:
          termination: Reencrypt
      apiVersion: v1
      kind: Service
      metadata:
        name: proxy
        annotations:
          service.alpha.openshift.io/serving-cert-secret-name: proxy-tls
      spec:
        ports:
        - name: proxy
          port: 443
          targetPort: 8443
        selector:
          app: proxy
    3. 배포 구성에 대한 YAML을 생성하여 프록시를 사이드카로 시작합니다.

      $ vi proxysidecar.yaml

      다음 샘플 코드를 추가합니다.

      apiVersion: extensions/v1beta1
      kind: Deployment
      metadata:
        name: proxy
      spec:
        replicas: 1
        selector:
          matchLabels:
            app: proxy
        template:
          metadata:
            labels:
              app: proxy
          spec:
            serviceAccountName: proxy
            containers:
            - name: oauth-proxy
              image: openshift3/oauth-proxy
              imagePullPolicy: IfNotPresent
              ports:
              - containerPort: 8443
                name: public
              args:
              - --https-address=:8443
              - --provider=openshift
              - --openshift-service-account=proxy
              - --upstream=http://localhost:8080
              - --tls-cert=/etc/tls/private/tls.crt
              - --tls-key=/etc/tls/private/tls.key
              - --cookie-secret=SECRET
              volumeMounts:
              - mountPath: /etc/tls/private
                name: proxy-tls
      
            - name: app
              image: openshift/hello-openshift:latest
            volumes:
            - name: proxy-tls
              secret:
                secretName: proxy-tls
    4. 세 개의 오브젝트를 생성합니다.

      $ oc create -f serviceaccount.yaml
      $ oc create -f route.yaml
      $ oc create -f proxysidecar.yaml
  2. oc edit sa/proxy 를 실행하여 서비스 계정을 편집하고 serviceaccounts.openshift.io/oauth-redirectreference 주석을 변경하여 존재하지 않는 경로를 가리킵니다.

    apiVersion: v1
    imagePullSecrets:
    - name: proxy-dockercfg-08d5n
    kind: ServiceAccount
    metadata:
      annotations:
        serviceaccounts.openshift.io/oauth-redirectreference.primary: '{"kind":"OAuthRedirectReference","apiVersion":"v1","reference":{"kind":"Route","name":"notexist"}}'
    ...
  3. 서비스의 OAuth 로그를 검토하여 서버 오류를 찾습니다.

    The authorization server encountered an unexpected condition that prevented it from fulfilling the request.
  4. oc get events 를 실행하여 ServiceAccount 이벤트를 확인합니다.

    $ oc get events | grep ServiceAccount

    출력 예

    23m        23m         1         proxy                    ServiceAccount                                  Warning   NoSAOAuthRedirectURIs   service-account-oauth-client-getter   [routes.route.openshift.io "notexist" not found, system:serviceaccount:myproject:proxy has no redirectURIs; set serviceaccounts.openshift.io/oauth-redirecturi.<some-value>=<redirect> or create a dynamic URI using serviceaccounts.openshift.io/oauth-redirectreference.<some-value>=<reference>]

4.1.4.4. 통합

OAuth 토큰에 대한 모든 요청에는 <master>/oauth/authorize 에 대한 요청이 포함됩니다. 대부분의 인증 통합에서는 이 끝점 앞에 인증 프록시를 배치하거나 백업 ID 공급자에 대한 자격 증명의 유효성을 검사하도록 OpenShift Container Platform을 구성합니다. <master>/oauth/authorize 에 대한 요청은 CLI와 같은 대화형 로그인 페이지를 표시할 수 없는 사용자 에이전트에서 가져올 수 있습니다. 따라서 OpenShift Container Platform은 대화형 로그인 flows 외에도 WWW-Authenticate 챌린지를 사용한 인증을 지원합니다.

인증 프록시가 <master>/oauth/authorize 끝점 앞에 배치되면 대화형 로그인 페이지를 표시하거나 대화형 로그인 flow로 리디렉션하는 대신 인증되지 않은 브라우저가 아닌 사용자 에이전트 WWW-Authenticate 챌린지 를 보내야 합니다.

참고

브라우저 클라이언트에 대한 CSV(Cross-site Request Forgery) 공격을 방지하기 위해 X-CSRF-Token 헤더가 요청에 있는 경우에만 기본 인증 챌린지를 보내야 합니다. 기본 WWW-Authenticate 챌린지를 수신해야 하는 클라이언트는 이 헤더를 비어 있지 않은 값으로 설정해야 합니다.

인증 프록시가 WWW-Authenticate 챌린지를 지원할 수 없거나 OpenShift Container Platform이 WWW-Authenticate 챌린지를 지원하지 않는 ID 공급자를 사용하도록 구성된 경우 사용자는 <master>/oauth/token/request 를 통해 수동으로 액세스 토큰을 가져올 수 있습니다.

4.1.4.5. OAuth 서버 메타데이터

OpenShift Container Platform에서 실행되는 애플리케이션은 내장 OAuth 서버에 대한 정보를 검색해야 할 수 있습니다. 예를 들어, 수동 구성 없이 <master> 서버의 주소를 검색해야 할 수 있습니다. 이러한 작업을 지원하기 위해 OpenShift Container Platform에서는 IETF OAuth 2.0 인증 서버 메타데이터 초안 사양을 구현합니다.

따라서 클러스터 내에서 실행되는 모든 애플리케이션은 https://openshift.default.svc/.well-known/oauth-authorization-serverGET 요청을 발행하여 다음 정보를 가져올 수 있습니다.

{
  "issuer": "https://<master>", 1
  "authorization_endpoint": "https://<master>/oauth/authorize", 2
  "token_endpoint": "https://<master>/oauth/token", 3
  "scopes_supported": [ 4
    "user:full",
    "user:info",
    "user:check-access",
    "user:list-scoped-projects",
    "user:list-projects"
  ],
  "response_types_supported": [ 5
    "code",
    "token"
  ],
  "grant_types_supported": [ 6
    "authorization_code",
    "implicit"
  ],
  "code_challenge_methods_supported": [ 7
    "plain",
    "S256"
  ]
}
1
https 체계를 사용하고 쿼리 또는 조각 구성 요소가 없는 URL에 해당하는 권한 부여 서버의 발행자 식별자. 권한 부여 서버에 대한 정보가 포함된 .well-known RFC 5785 리소스가 게시되는 위치입니다.
2
권한 부여 서버의 권한 부여 끝점 URL. RFC 6749를 참조하십시오.
3
권한 서버의 토큰 Endpoint URL입니다. RFC 6749를 참조하십시오.
4
이 권한 부여 서버에서 지원하는 OAuth 2.0 RFC 6749 범위 값 목록이 포함된 JSON 배열. 지원되는 모든 범위 값이 제공되는 것은 아닙니다.
5
이 권한 부여 서버에서 지원하는 OAuth 2.0 response_type 값 목록이 포함된 JSON 배열. 사용된 배열 값은 RFC 7591의 "OAuth 2.0 동적 클라이언트 등록 프로토콜"에서 정의한 response_types 매개변수에 사용된 것과 동일합니다.
6
이 권한 부여 서버에서 지원하는 OAuth 2.0 부여 유형 값 목록이 포함된 JSON 배열. 사용된 배열 값은 RFC 7591OAuth 2.0 동적 클라이언트 등록 프로토콜에서 정의한 grant_types 매개변수에 사용된 것과 동일합니다.
7
이 권한 부여 서버에서 지원하는 PKCE RFC 7636 코드 챌린지 방법 목록이 포함된 JSON 배열. 코드 챌린지 방법 값은 RFC 7636의 4.3절에 정의된 code_challenge_method 매개변수에 사용됩니다. 유효한 코드 챌린지 방법 값은 IANA PKCE 코드 챌린지 방법 레지스트리에 등록된 값입니다. IANA OAuth 매개변수를 참조하십시오.

4.1.4.6. OAuth 토큰 가져오기

OAuth 서버는 표준 인증 코드 부여암시적 부여 OAuth 인증 flows를 지원합니다.

인증 코드 부여 방법을 사용하여 OAuth 토큰을 요청하도록 다음 명령을 실행합니다.

$ curl -H "X-Remote-User: <username>" \
     --cacert /etc/origin/master/ca.crt \
     --cert /etc/origin/master/admin.crt \
     --key /etc/origin/master/admin.key \
     -I https://<master-address>/oauth/authorize?response_type=token\&client_id=openshift-challenging-client | grep -oP "access_token=\K[^&]*"

WWW-Authenticate challenges (예: openshift-challenging-client)를 요청하기 위해 구성된 client_id와 함께 암시적 부여 flow(response_type=token)를 사용하여 OAuth 토큰을 요청하는 경우, /oauth/authorize에서 제공 가능한 서버 응답 및 처리 방법은 다음과 같습니다.

상태내용클라이언트 응답

302

URL 조각에 access_token 매개변수를 포함하는 Location 헤더( RFC 4.2.2 )

access_token 값을 OAuth 토큰으로 사용하십시오.

302

error 쿼리 매개변수를 포함하는 Location 헤더(RFC 4.1.2.1)

실패, error (및 선택적 error_description) 쿼리 값을 사용자에게 선택적으로 표시합니다.

302

기타 Location 헤더

리디렉션을 따르고 해당 규칙을 사용하여 결과를 처리하십시오.

401

WWW-Authenticate 헤더 있음

유형이 인식되면(예: Basic, Negotiate) 챌린지에 응답하고 요청을 다시 제출한 후 해당 규칙을 사용하여 결과를 처리하십시오.

401

WWW-Authenticate 헤더 없음

인증할 수 있는 챌린지가 없습니다. 실패했으며 응답 본문(OAuth 토큰을 가져올 수 있는 링크 및 대체 방법에 대한 세부 사항이 포함될 수 있음)을 표시합니다.

기타

기타

실패, 사용자에게 응답 본문을 선택적으로 표시합니다.

암시적 부여 흐름을 사용하여 OAuth 토큰을 요청하려면 다음을 수행합니다.

$ curl -u <username>:<password>
'https://<master-address>:8443/oauth/authorize?client_id=openshift-challenging-client&response_type=token' -skv / 1
/ -H "X-CSRF-Token: xxx" 2

출력 예

*   Trying 10.64.33.43...
* Connected to 10.64.33.43 (10.64.33.43) port 8443 (#0)
* found 148 certificates in /etc/ssl/certs/ca-certificates.crt
* found 592 certificates in /etc/ssl/certs
* ALPN, offering http/1.1
* SSL connection using TLS1.2 / ECDHE_RSA_AES_128_GCM_SHA256
*        server certificate verification SKIPPED
*        server certificate status verification SKIPPED
*        common name: 10.64.33.43 (matched)
*        server certificate expiration date OK
*        server certificate activation date OK
*        certificate public key: RSA
*        certificate version: #3
*        subject: CN=10.64.33.43
*        start date: Thu, 09 Aug 2018 04:00:39 GMT
*        expire date: Sat, 08 Aug 2020 04:00:40 GMT
*        issuer: CN=openshift-signer@1531109367
*        compression: NULL
* ALPN, server accepted to use http/1.1
* Server auth using Basic with user 'developer'
> GET /oauth/authorize?client_id=openshift-challenging-client&response_type=token HTTP/1.1
> Host: 10.64.33.43:8443
> Authorization: Basic ZGV2ZWxvcGVyOmRzc2Zkcw==
> User-Agent: curl/7.47.0
> Accept: */*
> X-CSRF-Token: xxx
>
< HTTP/1.1 302 Found
< Cache-Control: no-cache, no-store, max-age=0, must-revalidate
< Expires: Fri, 01 Jan 1990 00:00:00 GMT
< Location:
https://10.64.33.43:8443/oauth/token/implicit#access_token=gzTwOq_mVJ7ovHliHBTgRQEEXa1aCZD9lnj7lSw3ekQ&expires_in=86400&scope=user%3Afull&token_type=Bearer 1
< Pragma: no-cache
< Set-Cookie: ssn=MTUzNTk0OTc1MnxIckVfNW5vNFlLSlF5MF9GWEF6Zm55Vl95bi1ZNE41S1NCbFJMYnN1TWVwR1hwZmlLMzFQRklzVXRkc0RnUGEzdnBEa0NZZndXV2ZUVzN1dmFPM2dHSUlzUmVXakQ3Q09rVXpxNlRoVmVkQU5DYmdLTE9SUWlyNkJJTm1mSDQ0N2pCV09La3gzMkMzckwxc1V1QXpybFlXT2ZYSmI2R2FTVEZsdDBzRjJ8vk6zrQPjQUmoJCqb8Dt5j5s0b4wZlITgKlho9wlKAZI=; Path=/; HttpOnly; Secure
< Date: Mon, 03 Sep 2018 04:42:32 GMT
< Content-Length: 0
< Content-Type: text/plain; charset=utf-8
<
* Connection #0 to host 10.64.33.43 left intact

1
client-idopenshift-challenging-client 로 설정되고 response-type토큰 으로 설정됩니다.
2
X-CSRF-Token 헤더를 비어 있지 않은 값으로 설정합니다.
1
토큰은 access_token=gzTwOq_mVJ7ovHliHBTgRQEEXa1aCZD9lnj7lSw3ekQ302 응답의 Location 헤더에 반환됩니다.

OAuth 토큰 값만 보려면 다음 명령을 실행합니다.

$ curl -u <username>:<password> /
'https://<master-address>:8443/oauth/authorize?client_id=openshift-challenging-client&response_type=token' / 1
-skv -H "X-CSRF-Token: xxx" --stderr - |  grep -oP "access_token=\K[^&]*" 2
1
client-idopenshift-challenging-client 로 설정되고 response-type토큰 으로 설정됩니다.
2
X-CSRF-Token 헤더를 비어 있지 않은 값으로 설정합니다.

출력 예

hvqxe5aMlAzvbqfM2WWw3D6tR0R2jCQGKx0viZBxwmc

코드 부여 방법을 사용하여 토큰을 요청할 수도 있습니다.

4.1.4.7. Prometheus의 인증 지표

OpenShift Container Platform은 인증 시도 중 다음과 같은 Prometheus 시스템 지표를 캡처합니다.

  • openshift_auth_basic_password_countoc login 사용자 이름 및 암호 시도 횟수를 계산합니다.
  • openshift_auth_basic_password_count_resultoc login 사용자 이름 및 암호 시도 횟수(성공 또는 오류)를 계산합니다.
  • openshift_auth_form_password_count는 웹 콘솔 로그인 시도 횟수를 계산합니다.
  • openshift_auth_form_password_count_result 는 웹 콘솔 로그인 시도 횟수(성공 또는 오류)를 계산합니다.
  • openshift_auth_password_total은 총 oc login 및 웹 콘솔 로그인 시도 횟수를 계산합니다.
Red Hat logoGithubRedditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

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

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

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

Red Hat 소개

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

© 2024 Red Hat, Inc.