9장. 서비스 계정을 OAuth 클라이언트로 사용
9.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는 서비스 계정의 주석과 일치해야 합니다.
9.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"