2.3. API 인증

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

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

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

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

2.3.1. OpenShift Container Platform OAuth 서버

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

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

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

2.3.1.1. OAuth 토큰 요청

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

OAuth 클라이언트사용법

openshift-browser-client

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

openshift-challenging-client

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

  1. <namespace_route>는 네임스페이스 경로를 나타냅니다. 다음 명령을 실행하여 확인할 수 있습니다. 

    $ oc get route oauth-openshift -n openshift-authentication -o json | jq .spec.host

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

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

참고

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

인증 프록시가 WWW-Authenticate 챌린지를 지원할 수 없거나 OpenShift Container Platform이 WWW-Authenticate 챌린지를 지원하지 않는 ID 공급자를 사용하도록 구성된 경우, 브라우저를 사용하여 <namespace_route>/oauth/token/request에서 수동으로 토큰을 가져와야 합니다.

2.3.1.2. API 가장

OpenShift Container Platform API에 대한 요청을 다른 사용자가 보낸 것처럼 작동하도록 구성할 수 있습니다. 자세한 내용은 쿠버네티스 설명서의 사용자 가장을 참조하십시오.

2.3.1.3. Prometheus의 인증 지표

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

  • openshift_auth_basic_password_count는 oc login 사용자 이름 및 암호 시도 횟수를 계산합니다.
  • openshift_auth_basic_password_count_result는 oc login 사용자 이름 및 암호 시도 횟수를 결과, success 또는 error별로 계산합니다.
  • openshift_auth_form_password_count는 웹 콘솔 로그인 시도 횟수를 계산합니다.
  • openshift_auth_form_password_count_result는 웹 콘솔 로그인 시도 횟수를 success 또는 error 등 결과별로 계산합니다.
  • openshift_auth_password_total은 총 oc login 및 웹 콘솔 로그인 시도 횟수를 계산합니다.