12장. 서비스 계정을 OAuth 클라이언트로 사용
12.1. OAuth 클라이언트로서의 서비스 계정
서비스 계정을 제한된 형태의 OAuth 클라이언트로 사용할 수 있습니다. 서비스 계정에서는 서비스 계정의 자체 네임스페이스 내에 있는 일부 기본 사용자 정보 및 역할 기반 권한에 액세스할 수 있는 부분적인 범위만 요청할 수 있습니다.
-
user:info
-
user:check-access
-
role:<any_role>:<service_account_namespace>
-
role:<any_role>:<service_account_namespace>:!
서비스 계정을 OAuth 클라이언트로 사용하는 경우에는 다음과 같습니다.
-
client_id
는system:serviceaccount:<service_account_namespace>:<service_account_name>
입니다. client_secret
은 해당 서비스 계정의 API 토큰 중 하나일 수 있습니다. 예를 들면 다음과 같습니다.$ oc sa get-token <service_account_name>
-
WWW-Authenticate
챌린지를 가져오려면 서비스 계정의serviceaccounts.openshift.io/oauth-want-challenges
주석을true
로 설정합니다. -
redirect_uri
는 서비스 계정의 주석과 일치해야 합니다.
12.1.1. 서비스 계정의 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"
위 예에서 first
및 second
라는 접미사는 두 개의 유효한 리디렉션 URI를 구분하는 데 사용됩니다.
복잡한 구성에서는 정적 리디렉션 URI로는 충분하지 않을 수 있습니다. 예를 들면 특정 경로의 모든 Ingress를 유효한 것으로 간주해야 할 수 있습니다. 이 경우 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
라는 경로를 참조할 수 있음을 확인할 수 있습니다. 따라서 해당 경로의 모든 Ingress가 이제 유효한 것으로 간주됩니다. 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
의 Ingress가 있다고 가정하면 이제 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
Ingress가 있다고 가정하면 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"