Azure Arc에서 사용하도록 설정된 AKS에서 Kubernetes API 서버에 대한 보안 연결을 위해 Active Directory Single Sign-On 사용

  • 아티클

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

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

AKS 하이브리드의 AD 개요

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

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

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

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

참고

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

이 문서에서는 Active Directory를 ID 공급자로 설정하고 를 통해 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이어야 합니다.

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

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

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

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

AD 인증을 설치하기 전에 먼저 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 또는 Windows Server 클러스터의 경우 관리자 권한으로 PowerShell을 열고 다음 명령을 실행합니다.

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

참고

의 경우 SPN k8s/apiserver@CONTOSO.com형식 SPN k8s/apiserver@<realm name>을 사용합니다. 첫 번째 시도에서 대문자로 를 지정 <realm name> 합니다. 그러나 대문자에 문제가 있는 경우 소문자로 SPN을 만듭니다. Kerberos는 대/소문자를 구분합니다.

옵션 2

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

관리 사용자를 사용하는 경우:

Install-AksHciAdAuth -name mynewcluster1 -keytab .\current.keytab -SPN k8s/apiserver@CONTOSO.COM -adminUserSID <User SID>

관리 그룹을 사용하는 경우:

Install-AksHciAdAuth -name mynewcluster1 -keytab .\current.keytab -SPN k8s/apiserver@CONTOSO.COM -adminGroupSID <Group SID>

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

다음 단계를 진행하기 전에 다음 항목을 기록해 둡다.

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

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 -configPath .\AdKubeconfig -adAuth

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

AKS 워크로드 클러스터에서 클라이언트 컴퓨터로 다음 세 개의 파일을 복사해야 합니다.

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

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

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

    참고

    adsso.exe 파일은 cmdlet을 실행할 때 서버에서 Get-AksHciCredential 생성됩니다.

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
metadata:
  name: ad-user-cluster-admin
  namespace: sre
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: sre-user-full-access
subjects:
  - apiGroup: rbac.authorization.k8s.io
    kind: Group
    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.keytab 및 previous.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 파일 만들기

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@CONTOSO.COM /mapuser contoso\apiserver_acct /crypto all /pass p@$$w0rd /ptype KRB5_NT_PRINCIPAL

참고

이름 항목에 0x2 반환된 DsCrackNames 오류가 표시되는 경우 에 대한 /mapuser 매개 변수가 형식mapuser DOMAIN\user인지 확인합니다. 여기서 DOMAIN은 에코 %userdomain%의 출력입니다.

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

다음 두 가지 옵션 중 하나를 사용하여 계정 또는 다른 계정에 대한 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 인증을 구성하는 방법을 알아보았습니다. 다음으로, 다음을 수행할 수 있습니다.