Azure Stack HCI 및 Windows Server에서 Azure Kubernetes Service 사용하여 Windows 컨테이너에 대한 gMSA(그룹 관리 서비스 계정) 구성

적용 대상: Azure Stack HCI 22H2의 AKS, Windows Server의 AKS

AD 인증을 사용하려면 도메인에 가입되지 않은 호스트를 사용하여 Windows 컨테이너에 대해 gMSA(그룹 관리 서비스 계정)를 실행하도록 구성할 수 있습니다. 그룹 관리 서비스 계정은 여러 컴퓨터가 암호를 모르고 ID를 공유할 수 있도록 설계된 Windows Server 2012 도입된 특별한 유형의 서비스 계정입니다. Windows 컨테이너는 도메인에 가입할 수 없지만 Windows 컨테이너에서 실행되는 많은 Windows 애플리케이션에는 여전히 AD 인증이 필요합니다.

참고

Kubernetes 커뮤니티가 Windows 컨테이너에서 gMSA 사용을 지원하는 방법을 알아보려면 gMSA 구성을 참조하세요.

도메인에 가입되지 않은 호스트가 있는 컨테이너용 gMSA 아키텍처

도메인에 가입되지 않은 호스트가 있는 컨테이너의 경우 gMSA는 호스트 ID 대신 이식 가능한 사용자 ID를 사용하여 gMSA 자격 증명을 검색합니다. 따라서 Windows 작업자 노드를 도메인에 수동으로 조인할 필요가 없습니다. 사용자 ID는 Kubernetes에 비밀로 저장됩니다. 다음 다이어그램은 도메인에 가입되지 않은 호스트가 있는 컨테이너에 대해 gMSA를 구성하는 프로세스를 보여 줍니다.

도메인에 가입되지 않은 호스트가 있는 컨테이너용 gMSA는 호스트 노드를 도메인에 가입시키지 않고도 gMSA로 컨테이너를 유연하게 만들 수 있습니다. Windows Server 2019부터 플러그 인 메커니즘이 Active Directory에서 gMSA 자격 증명을 검색할 수 있도록 하는 ccg.exe 지원됩니다. 해당 ID를 사용하여 컨테이너를 시작할 수 있습니다. ccg.exe 대한 자세한 내용은 ICcgDomainAuthCredentials 인터페이스를 참조하세요.

도메인에 가입되지 않은 호스트 및 도메인에 가입된 호스트가 있는 컨테이너의 gMSA 비교

gMSA가 처음 도입되었을 때 컨테이너 호스트를 도메인에 가입해야 했으며, 이로 인해 Windows 작업자 노드를 도메인에 수동으로 조인하는 오버헤드가 많이 발생했습니다. 이 제한 사항은 도메인에 가입되지 않은 호스트가 있는 컨테이너에 대해 gMSA를 사용하여 해결되었으므로 이제 사용자는 도메인에 조인되지 않은 호스트에서 gMSA를 사용할 수 있습니다. gMSA의 다른 개선 사항에는 다음 기능이 포함됩니다.

• Windows 작업자 노드를 도메인에 수동으로 조인해야 하는 요구 사항을 제거하여 많은 오버헤드가 발생했습니다. 크기 조정 시나리오의 경우 프로세스를 간소화합니다.
• 롤링 업데이트 시나리오에서 사용자는 더 이상 노드를 도메인에 다시 가입할 필요가 없습니다.
• gMSA 서비스 계정 암호를 검색하기 위해 작업자 노드 머신 계정을 보다 쉽게 관리하는 프로세스입니다.
• Kubernetes로 gMSA를 구성하는 덜 복잡한 엔드투엔드 프로세스입니다.

시작하기 전에

그룹 관리 서비스 계정으로 Windows 컨테이너를 실행하려면 다음 필수 구성 요소가 필요합니다.

• Windows Server 2012 이상을 실행하는 하나 이상의 도메인 컨트롤러가 있는 Active Directory 도메인. gMSA를 사용하기 위한 포리스트 또는 도메인 기능 수준 요구 사항은 없지만 Windows Server 2012 이상을 실행하는 도메인 컨트롤러만 gMSA 암호를 배포할 수 있습니다. 자세한 내용은 gMSA용 Active Directory 요구 사항을 참조하세요.
• gMSA 계정을 만들 수 있는 권한. gMSA 계정을 만들려면 도메인 관리자이거나 msDS-GroupManagedServiceAccount 개체를 만들 수 있는 권한이 있는 계정을 사용해야 합니다.
• 인터넷에 액세스하여 CredentialSpec PowerShell 모듈을 다운로드합니다. 연결이 끊긴 환경에서 작업하는 경우 인터넷 액세스 권한이 있는 컴퓨터에서 모듈을 저장하고 개발 머신 또는 컨테이너 호스트에 복사할 수 있습니다.
• gMSA 및 AD 인증이 작동하도록 하려면 Azure Stack HCI 및 Windows Server 클러스터 노드가 도메인 컨트롤러 또는 다른 시간 원본과 시간을 동기화하도록 구성되어 있는지 확인합니다. 또한 Hyper-V가 가상 머신에 시간을 동기화하도록 구성되어 있는지 확인해야 합니다.

도메인 컨트롤러에서 gMSA 준비

도메인 컨트롤러에서 gMSA를 준비하려면 다음 단계를 수행합니다.

1. 도메인 컨트롤러에서 Active Directory를 준비하고gMSA 계정을 만듭니다.

2. 도메인 사용자 계정을 Create. 이 사용자 계정/암호 자격 증명은 Kubernetes 비밀로 저장되고 gMSA 암호를 검색하는 데 사용됩니다.

3. GMSA 계정을 만들고 2단계에서 만든 gMSA 계정의 암호를 읽을 수 있는 권한을 부여하려면 다음 New-ADServiceAccount PowerShell 명령을 실행합니다.

    New-ADServiceAccount -Name "<gmsa account name>" -DnsHostName "<gmsa account name>.<domain name>.com" -ServicePrincipalNames "host/<gmsa account name>", "host/<gmsa account name>.<domain name>.com" -PrincipalsAllowedToRetrieveManagedPassword <username you created earlier> 
   

   의 경우 -PrincipalsAllowedToRetrieveManagedPassword다음 예제와 같이 앞에서 만든 도메인 사용자 이름을 지정합니다.

   New-ADServiceAccount -Name "WebApp01" -DnsHostName "WebApp01.akshcitest.com" -ServicePrincipalNames "host/WebApp01", "host/WebApp01.akshcitest.com" -PrincipalsAllowedToRetrieveManagedPassword "testgmsa"
   

gMSA 자격 증명 사양 JSON 파일 준비

gMSA 자격 증명 사양 JSON 파일을 준비하려면 자격 증명 사양을 만드는 단계를 따릅니다.

클러스터에서 Windows Pod 및 컨테이너에 대한 gMSA 구성

Kubernetes 커뮤니티는 gMSA에 대한 도메인 가입 Windows 작업자 노드를 이미 지원합니다. Azure Stack HCI 및 Windows Server의 AKS에서 Windows 작업자 노드를 도메인 조인할 필요는 없지만 다른 필수 구성 단계가 있습니다. 이러한 단계에는 웹후크 설치, CRD(사용자 지정 리소스 정의) 및 자격 증명 사양 설치 및 RBAC 역할(역할 기반 액세스 제어)이 포함됩니다. 다음 단계에서는 구성 프로세스를 간소화하는 데 도움이 되도록 빌드된 PowerShell 명령을 사용합니다.

다음 단계를 완료하기 전에 AksHci PowerShell 모듈이 설치되어 있고 kubectl 클러스터에 연결할 수 있는지 확인합니다.

1. 웹후크를 설치하려면 다음 Install-AksHciGmsaWebhook PowerShell 명령을 실행합니다.

   Install-AksHciGMSAWebhook -Name <cluster name>
   

   웹후크 Pod가 성공적으로 실행되고 있는지 확인하려면 다음 명령을 실행합니다.

   kubectl get pods -n kube-system | findstr gmsa
   

   실행 중인 gmsa-webhook 접두사와 함께 하나의 Pod가 표시됩니다.

2. Active Directory 사용자 자격 증명을 저장하는 비밀 개체를 Create. 다음 구성 데이터를 완료하고 secret.yaml이라는 파일에 설정을 저장합니다.

   apiVersion: v1
   kind: Secret
   metadata:
      name: <secret-name>
      namespace: <secret under namespace other than the default>
   type: Opaque
   stringData:
      domain: <FQDN of the domain, for example: akshcitest.com>
      username: <domain user who can retrieve the gMSA password>
      password: <password>
   

   그런 다음, 다음 명령을 실행하여 비밀 개체를 만듭니다.

   kubectl apply -f secret.yaml
   

   참고

   기본값이 아닌 네임스페이스 아래에 비밀을 만드는 경우 배포의 네임스페이스를 동일한 네임스페이스로 설정해야 합니다.

3. Add-AksHciGMSACredentialSpec PowerShell cmdlet을 사용하여 gMSA CRD를 만들고 RBAC(역할 기반 액세스 제어)를 사용하도록 설정한 다음 서비스 계정에 역할을 할당하여 특정 gMSA 자격 증명 사양 파일을 사용합니다. 이러한 단계는 Windows Pod 및 컨테이너에 대한 gMSA 구성에 대한 이 Kubernetes 문서에서 자세히 설명합니다.

   다음 PowerShell 명령에 대한 입력으로 JSON 자격 증명 사양을 사용합니다(별표가 *인 매개 변수는 필수).

   Add-AksHciGMSACredentialSpec -Name <cluster name>*  
     -credSpecFilePath <path to JSON credspec>* 
     -credSpecName <name for credspec as the k8s GMSACredentialSpec object>* 
     -secretName <name of secret>* 
     -secretNamespace <namespace of secret>  
     -serviceAccount <name of service account to bind to clusterrole>  
     -clusterRoleName <name of clusterrole to use the credspec>*  
     -overwrite 
   

   예제를 보려면 다음 코드를 참조하세요.

   Add-AksHciGMSACredentialSpec -Name mynewcluster 
     -credSpecFilePath .\credspectest.json 
     -credSpecName credspec-mynewcluster 
     -secretName mysecret 
     -clusterRoleName clusterrole-mynewcluster
   

애플리케이션 배포

다음 예제 설정을 사용하여 배포 YAML 파일을 Create. 필요한 항목에는 , , gmsaCredentialSpecNamevolumeMounts및 dnsconfig가 포함 됩니다serviceAccountName.

1. 서비스 계정을 추가합니다.

   serviceAccountName: default
      securityContext: 
        windowsOptions: 
          gmsaCredentialSpecName:
   

2. 자격 증명 사양 개체를 추가합니다.

   securityContext: 
        windowsOptions: 
          gmsaCredentialSpecName: <cred spec name>
   

3. 배포에 대한 비밀을 탑재합니다.

   volumeMounts:
        - name: <volume name>
          mountPath: <vmount path>
          readOnly: true
      volumes:
        - name: <volume name>
          secret:
            secretName: <secret name>
            items:
              - key: username
                path: my-group/my-username
   

4. dnsConfig 아래에 도메인 컨트롤러 및 도메인 이름의 IP 주소를 추가합니다.

   dnsConfig: 
        nameservers:
          - <IP address for domain controller>
        searches: 
          - <domain>
   

컨테이너가 gMSA에서 작동하는지 확인합니다.

컨테이너를 배포한 후 다음 단계를 사용하여 컨테이너가 작동하는지 확인합니다.

1. 다음 명령을 실행하여 배포에 대한 컨테이너 ID를 가져옵니다.

   kubectl get pods
   

2. PowerShell을 열고 다음 명령을 실행합니다.

   kubectl exec -it <container id> powershell
   

3. 컨테이너에 있으면 다음 명령을 실행합니다.

   Nltest /parentdomain 
   Nltest /sc_verify:<domain> 
   

   Connection Status = 0 0x0 NERR_Success The command completed successfully. 
   

   이 출력은 컴퓨터가 도메인 컨트롤러에 의해 인증되었으며 클라이언트 컴퓨터와 도메인 컨트롤러 사이에 보안 채널이 있음을 보여 줍니다.

4. 컨테이너가 유효한 Kerberos TGT(티켓 부여 티켓)를 가져올 수 있는지 확인합니다.

   klist get krbtgt
   

   A ticket to krbtgt has been retrieved successfully
   

클러스터에서 gMSA 설정 정리

gMSA 설정을 클린 필요한 경우 다음 제거 단계를 사용합니다.

자격 증명 사양 제거

제거하려면 다음 Remove-AksHcigmsaCredentialSpec PowerShell 명령을 실행합니다.

Remove-AksHciGMSACredentialSpec -Name <cluster name> -credSpecName <cred spec object name> -clusterRoleName <clusterrole object name> -serviceAccount <serviceaccount object name> -secretNamespace <namespace of the secret object>

웹후크 제거

웹후크를 제거하려면 다음 Uninstall-AksHciGMSAWebhook PowerShell 명령을 실행합니다.

Uninstall-AksHciGMSAWebhook -Name <cluster name>

다음 단계

• Kubernetes 클러스터에서 영구 볼륨 사용
• Azure Stack HCI 및 Windows Server 클러스터에서 AKS 모니터링