AKS 구조적 인증에서 외부 ID 공급자 사용(미리 보기)

AKS(Azure Kubernetes Service)는 Kubernetes API 서버에 사용자를 인증하기 위해 외부 ID 공급자를 구성할 수 있는 구조적 인증을 지원합니다. 이 기능은 업스트림 Kubernetes 구조적 인증 구성을 기반으로 합니다. AKS는 구성에 따라 외부 ID 공급자의 토큰 유효성을 검사하는 JWT(JSON Web Token) 인증자를 통해 이 기능을 구현합니다. 조직에서는 정형 인증을 사용하여 MICROSOFT Entra ID를 넘어서 기존 ID 인프라와 AKS를 통합할 수 있습니다.

이 문서에서는 주요 개념, 보안 고려 사항 및 구성을 위한 다음 단계를 포함하여 AKS 구조적 인증을 통해 외부 ID 공급자를 사용하는 방법에 대한 개요를 제공합니다.

외부 ID 공급자 인증의 이점

구조적 인증은 업계 표준 OIDC(OpenID Connect) ID 공급자를 지원하여 AKS를 기존 Microsoft Entra ID 통합 이상으로 확장합니다. 이 기능을 사용하면 다음을 수행할 수 있습니다.

• Google, GitHub 또는 OIDC 규격 공급자와 같은 외부 ID 공급자를 사용하여 사용자를 인증합니다.
• 조직 전체에서 중앙 집중식 ID 관리를 유지 관리합니다.
• 사용자 지정 클레임 유효성 검사 및 사용자 매핑 규칙을 구현합니다.
• 단일 클러스터에서 동시에 여러 ID 공급자를 지원합니다.

외부 ID 공급자 인증 흐름

사용자가 외부 ID 공급자와 구조적 인증을 사용하여 Kubernetes API 서버에 액세스하려고 하면 인증 및 권한 부여 흐름은 다음과 같습니다.

• 인증: 다음 단계에서는 사용자 ID의 유효성을 검사합니다.
  • 토큰 프레젠테이션: 사용자가 구성된 ID 공급자로부터 JWT 토큰을 제공합니다.
  • 토큰 유효성 검사: API 서버는 토큰의 서명, 발급자, 대상 그룹 및 만료의 유효성을 검사합니다.
  • 클레임 처리: 토큰이 요구 사항을 충족하는지 확인하기 위해 사용자 지정 클레임 유효성 검사 규칙이 적용됩니다.
  • 사용자 매핑: 클레임은 Kubernetes 사용자 ID(사용자 이름, 그룹 및 추가 특성)에 매핑됩니다.
• 권한 부여: 표준 Kubernetes Role-Based RBAC(Access Control)는 인증된 사용자가 수행할 수 있는 작업을 결정합니다.

지원되는 ID 공급자

AKS 구조적 인증은 모든 OIDC 규격 ID 공급자를 허용하지만 일반적인 공급자는 다음과 같습니다.

• GitHub: GitHub ID 또는 GitHub Actions를 사용하여 인증합니다.
• Google OAuth 2.0: 인증에 Google 계정을 사용합니다.
• 제네릭 OIDC 공급자: OIDC 표준을 구현하는 모든 공급자입니다.
• 사용자 지정 ID 솔루션: 조직별 OIDC 구현.

외부 ID 공급자에 대한 요구 사항

외부 ID 공급자는 AKS 구조적 인증을 사용하려면 다음 요구 사항을 충족해야 합니다.

• OIDC 표준을 지원합니다.
• 공개적으로 액세스할 수 있는 OIDC 검색 엔드포인트를 제공합니다.
• 적절한 클레임으로 JWT 토큰을 발급합니다.
• 토큰 유효성 검사를 위해 AKS 클러스터 노드에서 액세스할 수 있습니다.

AKS 구조적 인증을 위한 JWT 인증자

JWT 인증자는 AKS가 외부 ID 공급자의 토큰의 유효성을 검사하고 처리하는 방법을 정의하는 구성 개체입니다. 예를 들어, AKS는 인증기에서 구성한 대상 값(예: aud) 또는 OAuth 클라이언트 ID와 일치하는 "my-api"(대상) 클레임을 가진 ID 토큰을 필요로 합니다. 각 JWT 인증자에는 다음 구성 요소가 포함됩니다.

• 발급자 구성: 토큰에 대한 OIDC 발급자 URL 및 예상 대상 그룹 값을 지정합니다.
• 클레임 유효성 검사 규칙: CEL(공용 식 언어) 식을 사용하여 토큰 클레임에 사용자 지정 유효성 검사 논리를 적용합니다.
• 클레임 매핑: JWT 클레임이 사용자 이름, 그룹 및 추가 필드와 같은 Kubernetes 사용자 특성에 매핑되는 방법을 정의합니다.
• 사용자 유효성 검사 규칙: 클레임 매핑 후 추가 유효성 검사 논리를 적용하여 액세스를 추가로 제한하거나 허용합니다.

클레임 유효성 검사 및 매핑에 대한 CEL 식

구조적 인증은 유연한 클레임 유효성 검사 및 매핑을 위해 CEL 식을 사용합니다. CEL은 JWT 클레임에 대한 사용자 지정 논리를 평가하기 위한 보안 샌드박스 환경을 제공합니다.

CEL 식 예제:

// Validate that the 'sub' claim exists
has(claims.sub)

// Map username with AKS prefix
'aks:jwt:' + claims.sub

// Map groups from comma-separated string
claims.groups.split(',').map(g, 'aks:jwt:' + g)

// Conditional mapping based on claim verification
'aks:jwt:' + (claims.email_verified ? claims.email : claims.sub)

보안 모범 사례

AKS 구조적 인증과 함께 외부 ID 공급자를 사용하는 경우 다음 보안 모범 사례를 염두에 두세요.

• 강력한 클레임 유효성 검사 사용: 포괄적인 유효성 검사 규칙을 구현하여 권한 있는 토큰만 허용되도록 합니다.
• 토큰 범위 제한: 필요한 클레임을 최소화하여 토큰을 발급하도록 ID 공급자를 구성합니다.
• 정기 회전: 클라이언트 비밀 및 인증서를 정기적으로 회전합니다.
• 액세스 모니터링: 리소스 로그를 사용하도록 설정하고 로그를 켜 kube-apiserver 서 구성된 JWT 인증자와 관련된 잠재적인 문제를 검사하고 인증 이벤트를 추적합니다.
• 테스트 구성: 먼저 비프로덕션 환경에서 JWT 인증자 구성의 유효성을 검사합니다.

보안 고려 사항

AKS 구조적 인증과 함께 외부 ID 공급자를 사용하는 경우 다음 보안 고려 사항을 염두에 두어야 합니다.

• 접두사 요구 사항: 다른 인증 방법 및 시스템 계정과의 충돌을 방지하려면 구조적 인증을 통해 매핑된 모든 사용자 이름 및 그룹을 접두사로 aks:jwt: 사용해야 합니다.
• 네트워크 액세스: ID 공급자 엔드포인트는 다음에서 액세스할 수 있어야 합니다.
  • 토큰 유효성 검사를 위한 AKS 클러스터 노드입니다.
  • 토큰 획득을 위한 클라이언트 시스템입니다.
  • 인증 흐름과 관련된 모든 네트워크 경로입니다.
• 유효성 검사 계층: 구조적 인증은 여러 유효성 검사 계층을 제공합니다.
  • 토큰 서명 유효성 검사는 토큰 인증을 보장합니다.
  • 표준 클레임 유효성 검사는 발급자, 대상 그룹 및 만료를 확인합니다.
  • 사용자 지정 클레임 유효성 검사는 조직의 특정 요구 사항을 적용합니다.
  • 클레임 매핑 후 사용자 유효성 검사 최종 검사

관련 콘텐츠

구조적 인증 및 관련 기능에 대한 자세한 내용은 다음 리소스를 참조하세요.

• AKS에 대한 구조적 인증 구성
• Kubernetes 구조적 인증 구성
• Kubernetes의 CEL 식
• OpenID Connect 사양