Azure Stack HCI용 AKS에서 Kubernetes API 서버에 대한 보안 연결에 Active Directory Single Sign-On 사용

적용 대상: Azure Stack HCI, 버전 21H2 및 20H2; Windows Server 2022 Datacenter, Windows Server 2019 Datacenter

AD(Active Directory) SSO(Single Sign-On) 자격 증명을 사용하여 Kubernetes API 서버에 대한 보안 연결을 만들 수 있습니다.

Active Directory 인증이 없으면 사용자는 명령을 통해 kubectl API 서버에 연결할 때 인증서 기반 kubeconfig 파일을 사용해야 합니다. kubeconfig 파일에는 신중하게 배포해야 하는 프라이빗 키 및 인증서와 같은 비밀이 포함되어 있어 상당한 보안 위험이 될 수 있습니다.

인증서 기반 kubeconfig를 사용하는 대신 AD SSO(로그온) 자격 증명을 API 서버에 연결하는 안전한 방법으로 사용할 수 있습니다. Azure Stack HCI의 Azure Kubernetes Service AD 통합을 통해 Windows 도메인 가입 컴퓨터의 사용자는 SSO 자격 증명을 사용하여 API 서버에 kubectl연결할 수 있습니다. 이렇게 하면 프라이빗 키가 포함된 인증서 기반 kubeconfig 파일을 관리하고 배포할 필요가 없습니다.

AD 통합은 인증서 기반 kubeconfig 파일과 구별되며 비밀을 포함하지 않는 AD kubeconfig 를 사용합니다. 그러나 Active Directory 자격 증명을 사용하여 연결하는 데 문제가 있는 경우 문제 해결과 같은 백업 목적으로 인증서 기반 kubeconfig 파일을 사용할 수 있습니다.

AD 통합의 또 다른 보안 이점은 사용자 및 그룹이 SID(보안 식별자)로 저장된다는 것입니다. 그룹 이름과 달리 SID는 변경할 수 없고 고유하므로 명명 충돌이 없습니다.

참고

현재 AD SSO 연결은 워크로드 클러스터에 대해서만 지원됩니다.

이 문서에서는 Id 공급자로 Active Directory를 설정하고 다음을 통해 kubectlSSO를 사용하도록 설정하는 다음 단계를 안내합니다.

  • API 서버에 대한 AD 계정을 만든 다음 계정과 연결된 keytab 파일을 만듭니다. keytab 파일을 사용하여 AD 인증 만들기를 참조하여 AD 계정을 만들고 keytab 파일을 생성합니다.
  • Keytab 파일을 사용하여 Kubernetes 클러스터에 AD 인증을 설치합니다. 이 단계의 일부로 기본 RBAC(역할 기반 액세스 제어) 구성이 자동으로 만들어집니다.
  • RBAC 구성을 만들거나 편집할 때 그룹 이름을 SID로 변환하고 그 반대의 경우도 마찬가지입니다. 지침은 AD 그룹 역할 바인딩 만들기 및 업데이트를 참조하세요.

시작하기 전에

Active Directory SSO 자격 증명을 구성하는 프로세스를 시작하기 전에 다음 항목을 사용할 수 있는지 확인해야 합니다.

  • 최신 Aks-Hci PowerShell 모듈이 설치되어 있습니다. 설치해야 하는 경우 AksHci PowerShell 모듈 다운로드 및 설치를 참조하세요.

  • AKS 호스트가 설치되고 구성됩니다. 호스트를 설치해야 하는 경우 단계에 따라 배포를 구성합니다.

  • keytab 파일을 사용할 수 있습니다. 사용할 수 없는 경우 단계에 따라 API 서버 AD 계정 및 keytab 파일을 만듭니다.

    참고

    SPN(특정 서비스 사용자 이름)에 대한 keytab 파일을 생성해야 하며, 이 SPN은 워크로드 클러스터에 대한 API 서버 AD 계정에 해당해야 합니다. 또한 AD 인증 프로세스 전체에서 동일한 SPN이 사용되는지 확인해야 합니다. keytab 파일의 이름은 current.keytab이어야 합니다.

  • Azure Stack HCI 워크로드 클러스터의 각 AKS에 대해 하나의 API 서버 AD 계정을 사용할 수 있습니다.

  • 클라이언트 컴퓨터는 도메인에 가입된 Windows 컴퓨터여야 합니다.

keytab 파일을 사용하여 AD 인증 만들기

1단계: 워크로드 클러스터 만들기 및 AD 인증 사용

AD 인증을 설치하기 전에 먼저 Azure Stack HCI 워크로드 클러스터에서 AKS를 만들고 클러스터에서 AD 인증 추가 기능을 사용하도록 설정해야 합니다. 새 클러스터를 만들 때 AD 인증을 사용하도록 설정하지 않으면 나중에 사용하도록 설정할 수 없습니다.

관리자 권한으로 PowerShell을 열고 명령의 -enableADAuth 매개 변수를 사용하여 다음을 New-AksHciCluster 실행합니다.

New-AksHciCluster -name mynewcluster1 -enableADAuth

각 워크로드 클러스터에 대해 사용할 수 있는 API 서버 AD 계정이 하나 있는지 확인합니다.

워크로드 클러스터를 만드는 방법에 대한 자세한 내용은 Windows PowerShell 사용하여 Kubernetes 클러스터 만들기를 참조하세요.

2단계: AD 인증 설치

AD 인증을 설치하려면 먼저 워크로드 클러스터를 설치하고 클러스터에서 AD 인증을 사용하도록 설정해야 합니다. AD 인증을 설치하려면 다음 옵션 중 하나를 사용합니다.

옵션 1

도메인에 가입된 Azure Stack HCI 클러스터의 경우 관리자 권한으로 PowerShell을 열고 다음 명령을 실행합니다.

Install-AksHciAdAuth -name mynewcluster1 -keytab .\current.keytab -SPN k8s/apiserver@CONTOSO.COM -adminUser contoso\bob

참고

의 경우 SPN k8s/apiserver@CONTOSO.comSPN k8s/apiserver@<realm 이름> 형식을 사용합니다. 일반적으로 <영역 이름은> 대문자이지만 문제가 있는 경우 소문자로 SPN을 만듭니다. Kerberos는 대/소문자를 구분합니다.

옵션 2

클러스터 호스트가 도메인에 가입되지 않은 경우 아래 예제와 같이 관리자 사용자 이름 또는 그룹 이름을 SID 형식으로 사용합니다.

Install-AksHciAdAuth -name mynewcluster1 -keytab .\current.keytab -SPN k8

사용자 계정에 대한 SID를 찾으려면 사용자 또는 그룹 보안 식별자 결정을 참조하세요.

다음 단계를 진행하기 전에 다음 항목을 기록해 두어야 합니다.

  • keytab 파일의 이름이 current.keytab인지 확인합니다.
  • 사용자 환경에 해당하는 SPN을 바꿉니다.
  • -adminUser 매개 변수는 클러스터 관리자 권한이 있는 지정된 AD 그룹에 대한 해당 역할 바인딩을 만듭니다. 위의 옵션 1에 표시된 것처럼 contoso\bob 을 사용자 환경에 해당하는 AD 그룹 또는 사용자로 바꿉니다.

3단계: AD 웹후크 및 keytab 파일 테스트

AD 웹후크가 API 서버에서 실행되고 있고 keytab 파일이 Kubernetes 비밀로 저장되었는지 확인해야 합니다. 워크로드 클러스터에 대한 인증서 기반 kubeconfig 파일을 얻으려면 다음 단계를 수행합니다.

  1. 다음 명령을 사용하여 인증서 기반 kubeconfig 파일을 가져옵니다. kubeconfig 파일을 사용하여 로컬 호스트로 클러스터에 연결합니다.

    Get-AksHciCredential -name mynewcluster1
    
  2. 이전에 만든 인증서 기반 kubeconfig 파일을 사용하여 연결한 서버에서 실행 kubectl 한 다음 AD 웹후크 배포를 확인하여 ad-auth-webhook-xxxx 형식인지 확인합니다.

    kubectl get pods -n=kube-system
    
  3. 실행 kubectl 하여 keytab 파일이 비밀로 배포되고 Kubernetes 비밀로 나열되어 있는지 확인합니다.

    kubectl get secrets -n=kube-system
    

4단계: AD kubeconfig 파일 만들기

AD 웹후크와 keytab이 성공적으로 배포되면 AD kubeconfig 파일을 만듭니다. 파일을 만든 후 AD kubeconfig 파일을 클라이언트 컴퓨터에 복사하고 이를 사용하여 API 서버에 인증합니다. 인증서 기반 kubeconfig 파일과 달리 AD kubeconfig 는 비밀이 아니며 일반 텍스트로 복사해도 안전합니다.

관리자 권한으로 PowerShell을 열고 다음 명령을 실행합니다.

Get-AksHciCredential -name mynewcluster1 -outputLocation .\AdKubeconfig -adAuth

5단계: kubeconfig 및 기타 파일을 클라이언트 컴퓨터에 복사

아래에 나열된 세 개의 파일을 Azure Stack HCI 클러스터에서 클라이언트 머신으로 복사해야 합니다.

  • 이전 단계에서 만든 AD kubeconfig 파일을 $env:USERPROFILE.kube\config에 복사합니다.

  • 폴더 경로를 c:\adsso 만들고 Azure Stack HCI 클러스터에서 클라이언트 머신으로 다음 파일을 복사합니다.

    • c:\adsso에 $env:ProgramFiles\AksHci Kubectl.exe
    • c:\adsso에 $env:ProgramFiles\AksHci Kubectl-adsso.exe

6단계: 클라이언트 컴퓨터에서 API 서버로 커넥트

이전 단계를 완료한 후 SSO 자격 증명을 사용하여 Windows 도메인에 가입된 클라이언트 컴퓨터에 로그인합니다. PowerShell을 열고 다음을 사용하여 kubectlAPI 서버에 액세스하려고 시도합니다. 작업을 성공적으로 완료할 수 있는 경우 AD SSO를 올바르게 설정했습니다.

AD 그룹 역할 바인딩 만들기 및 업데이트

2단계에서 설명한 것처럼 설치 중에 제공된 사용자 및/또는 그룹에 대해 클러스터 관리자 권한이 있는 기본 역할 바인딩이 만들어집니다. Kubernetes의 역할 바인딩은 AD 그룹에 대한 액세스 정책을 정의합니다. 이 단계에서는 RBAC를 사용하여 Kubernetes에서 새 AD 그룹 역할 바인딩을 만들고 기존 역할 바인딩을 편집하는 방법을 설명합니다. 예를 들어 클러스터 관리자는 AD 그룹을 사용하여 사용자에게 추가 권한을 부여할 수 있습니다(프로세스 효율성을 높입니다). RBAC에 대한 자세한 내용은 RBAC 권한 부여 사용을 참조하세요.

더 많은 AD 그룹 RBAC 항목을 만들거나 편집할 때 주체 이름은 "microsoft:activedirectory:CONTOSO\\group name"로 미리 수정해야 합니다. 이름에는 큰따옴표로 묶인 도메인 이름과 접두사도 포함되어야 합니다.

다음 두 가지 예제를 살펴보세요.

예제 1

apiVersion: rbac.authorization.k8s.io/v1 
 kind: ClusterRoleBinding 
 metadata: 
   name: ad-user-cluster-admin 
 roleRef: 
   apiGroup: rbac.authorization.k8s.io 
   kind: ClusterRole 
   name: cluster-admin 
 subjects: 
 - apiGroup: rbac.authorization.k8s.io 
   kind: User 
   name: "microsoft:activedirectory:CONTOSO\Bob" 

예제 2

아래 예제에서는 AD 그룹이 있는 네임스페이스에 대한 사용자 지정 역할 및 역할 바인딩을 만드는 방법을 보여줍니다. 예제에서 "SREGroup"은 Contoso Active Directory의 기존 그룹입니다. 사용자가 AD 그룹에 추가되면 즉시 권한이 부여됩니다.

kind: Role 
 apiVersion: rbac.authorization.k8s.io/v1 
 metadata: 
   name: sre-user-full-access 
   namespace: sre 
 rules: 
 - apiGroups: ["", "extensions", "apps"] 
   resources: ["*"] 
   verbs: ["*"] 
 - apiGroups: ["batch"] 
   resources: 
   - jobs 
   - cronjobs 
   verbs: ["*"] 
 apiVersion: rbac.authorization.k8s.io/v1 
 kind: RoleBinding 
 namespace: sre 
 metadata: 
   name: ad-user-cluster-admin 
 roleRef: 
   apiGroup: rbac.authorization.k8s.io 
   kind: Role 
   name: sre-user-full-access 
 subjects: 
 - apiGroup: rbac.authorization.k8s.io 
   kind: User 
   name: "microsoft:activedirectory:CONTOSO\SREGroup" 

yaml 파일을 적용하기 전에 다음 명령을 사용하여 그룹 및 사용자 이름을 항상 SID로 변환해야 합니다.

kubectl-adsso nametosid <rbac.yml>

마찬가지로 기존 RBAC를 업데이트하기 위해 변경하기 전에 SID를 사용자 친화적인 그룹 이름으로 변환할 수 있습니다. SID를 변환하려면 다음 명령을 사용합니다.

kubectl-adsso sidtoname <rbac.yml>

API 서버 계정과 연결된 AD 계정 암호 변경

API 서버 계정에 대한 암호가 변경되면 AD 인증 추가 기능을 제거하고 업데이트된 현재 및 이전 키 탭을 사용하여 다시 설치해야 합니다.

암호를 변경할 때마다 현재 keytab(current.keytab)의 이름을 previous.keytab으로 바꿔야 합니다. 그런 다음, 새 암호 current.keytab의 이름을 지정해야 합니다.

중요

파일 이름은 각각 current.keytabprevious.keytab이어야 합니다. 기존 역할 바인딩의 영향을 받지 않습니다.

AD 인증 제거 및 다시 설치

API 서버의 계정이 변경되거나 암호가 업데이트되면 AD SSO를 다시 설치하거나 오류를 해결할 수 있습니다.

AD 인증을 제거하려면 관리자 권한으로 PowerShell을 열고 다음 명령을 실행합니다.

Uninstall-AksHciAdAuth -name mynewcluster1

AD 인증을 다시 설치하려면 관리자 권한으로 PowerShell을 열고 다음 명령을 실행합니다.

Install-AksHciAdAuth -name mynewcluster1 -keytab <.\current.keytab> -previousKeytab <.\previous.keytab> -SPN <service/principal@CONTOSO.COM> -adminUser CONTOSO\Bob

참고

-previousKeytab 매개 변수는 암호를 변경하는 경우에만 필요합니다. 이는 클라이언트가 티켓을 캐시한 경우 가동 중지 시간을 방지하기 위한 것입니다.

API 서버 AD 계정 및 keytab 파일 만들기

이 프로세스에는 두 단계가 관련되어 있습니다. 먼저 SPN(서비스 사용자 이름)을 사용하여 API 서버에 대한 새 AD 계정/사용자를 만들고, 둘째, AD 계정에 대한 keytab 파일을 만듭니다.

1단계: API 서버에 대한 새 AD 계정 또는 사용자 만들기

New-ADUser PowerShell 명령을 사용하여 SPN을 사용하여 새 AD 계정/사용자를 만듭니다. 예를 들면 다음과 같습니다.

New-ADUser -Name apiserver -ServicePrincipalNames k8s/apiserver -AccountPassword (ConvertTo-SecureString "password" -AsPlainText -Force) -KerberosEncryptionType AES128 -Enabled 1

2단계: AD 계정에 대한 keytab 파일 만들기

keytab 파일을 만들려면 ktpass Windows 명령을 사용합니다.

ktpass를 사용하는 예제는 다음과 같습니다.

ktpass /out current.keytab /princ k8s/apiserver@BCONTOSO.COM /mapuser contoso\apiserver_acct /crypto all /pass p@$$w0rd /ptype KRB5_NT_PRINCIPAL

참고

이 오류가 표시되면 DsCrackNames는 이름 항목에 0x2 반환하고 매개 변수 /mapuser 가 도메인이 에코%userdomain%의 출력인 형식 mapuser DOMAIN\user 인지 확인합니다.

사용자 또는 그룹 보안 식별자 확인

다음 두 가지 옵션 중 하나를 사용하여 계정 또는 다른 계정의 SID를 찾습니다.

계정과 연결된 SID를 찾으려면 홈 디렉터리의 명령 프롬프트에서 다음을 입력합니다.

whoami /user

다른 계정과 연결된 SID를 찾으려면 관리자 권한으로 PowerShell을 열고 다음을 실행합니다.

(New-Object System.Security.Principal.NTAccount(<CONTOSO\Bob>)).Translate([System.Security.Principal.SecurityIdentifier]).value

문제 해결(인증서)

웹후크와 API 서버는 인증서를 사용하여 TLS 연결의 상호 유효성을 검사합니다. 이 인증서는 500일 후에 만료됩니다. 인증서가 만료되었는지 확인하려면 컨테이너의 로그를 ad-auth-webhook 확인합니다.

kubectl logs ad-auth-webhook-xxx

인증서 유효성 검사 오류가 표시되면 웹후크를 제거하고 다시 설치하고 새 인증서를 가져오는 단계를 완료합니다.

정리 및 모범 사례

  • 각 클러스터에 대해 고유한 계정을 사용합니다.
  • 클러스터에서 API 서버 계정에 대한 암호를 다시 사용하지 마세요.
  • 클러스터를 만드는 즉시 keytab 파일의 로컬 복사본을 삭제하고 SSO 자격 증명이 작동하는지 확인합니다.
  • API 서버에 대해 만들어진 Active Directory 사용자를 삭제합니다. 자세한 내용은 Remove-ADUser를 참조하세요.

다음 단계

이 방법 가이드에서는 SSO 자격 증명을 사용하여 API 서버에 안전하게 연결하도록 AD 인증을 구성하는 방법을 알아보았습니다. 다음으로, 다음을 수행할 수 있습니다.