4장. 추가 개념

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

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

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

$ 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
')

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

서비스 계정을 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"

위 예에서 first 및 second라는 접미사는 두 개의 유효한 리디렉션 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
  }
}

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

"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 은 유효한 것으로 간주되지 않습니다. 데이터 덮어쓰기를 부분적으로 제공하는 형식은 다음과 같습니다.

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

<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:8000 및 https://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"

$ 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/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>

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>]

Reason                  Message
NoSAOAuthTokens         system:serviceaccount:myproject:proxy has no tokens

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

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

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

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

{
  "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"
  ]
}

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에서 제공 가능한 서버 응답 및 처리 방법은 다음과 같습니다.

암시적 부여 흐름을 사용하여 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

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

hvqxe5aMlAzvbqfM2WWw3D6tR0R2jCQGKx0viZBxwmc

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

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