Kubernetes Authentication

- https://kubernetes.io/docs/reference/access-authn-authz/authentication/ 를 참고/번역/재정리합니다 -

*작성기준일: 2022/08/04

 

*Users in Kubernetes

1. 모든 쿠베 클러스터는 두 종류의 User로 나뉜다.

• Service Account (쿠베 관리O -> API로 만듦)
  • 특정 Namespace에 Binding
  • API Server에 의해 자동 생성 or API call을 통해 수동으로 생성
  • Secret으로 Credential을 저장
• Normal User (쿠베가 관리X -> API로 만들 수 없음)
  • Private Key
    • 클러스터의 인증 기관(CA)이 서명한 유효한 인증서를 제시
    • CommonName(Hostname)에서 Username을 결정
    • RBAC System이 접근하는 대상 (Certificate Signing Requests: https://kubernetes.io/docs/reference/access-authn-authz/certificate-signing-requests/#normal-user)
  • User store (Keystone, Google Accounts)
  • username/password file/list

2. API Call은 Sevice Account, Normal User, Anonymous 로 요청을 처리한다. 즉, kubectl과 같은 kubernetes API를 요청하는 모든 클러스터 내/외부 프로세스는 요청 당시 Authentication을 거치거나, Anonymous로 처리되어야 한다.

 

 

*Authentication Strategies

1. Kubernetes가 API Request를 인증하는 Authentication Plugin

• Client Certificates
• Bearer Tokens
• Authenticating Proxy

2. Authentication Plugin이 확인하는 attributes (Authorizer:https://kubernetes.io/docs/reference/access-authn-authz/authorization/ 가 참조하는 값)

• Username
• UID
• Groups
  • User's Membership을 의미
• Extra Fields
  • Additional Informations in String

3. 여러 Authentication을 동시에 설정할 수 있고, 첫 번째 Authentication이 성공하면 API 처리가 가장 빠르지만, Authentication 순서(여러 Authentication 중)는 K8S API에서 보장하지 않음

• 일반적으로 최소한 Service Account Token은 포함하여야 함

4. 모든 authenticated user는 system:authenticated 그룹에 포함

5. 다른 authentication protocol (LDAP, SAML, Kerberos, alternate X509 Schemes, etc) 과의 통합은 authenticating proxy 또는 authenticating webhook을 통함