이 문서에서는 Azure 로컬 배포를 위해 Azure Key Vault에서 로컬 ID를 사용하는 방법을 설명합니다.
중요함
이 기능은 현재 미리 보기로 제공됩니다. 베타, 미리 보기 또는 아직 일반 공급으로 릴리스되지 않은 Azure 기능에 적용되는 법적 용어는 Microsoft Azure 미리 보기에 대한 추가 사용 약관 을 참조하세요.
개요
Azure Local은 AD(Active Directory) 기반 배포 외에도 이전에 AD 없는 배포라고도 하는 Azure Key Vault를 사용하여 로컬 ID를 통한 배포를 지원합니다.
로컬 관리자 계정을 사용하는 로컬 ID를 사용하여 배포 프로세스는 인증서 기반 인증과 클러스터 수준 통합을 구성합니다. 이 설정은 배포 및 진행 중인 작업 중에 보안 통신을 보장합니다.
이 구성의 일부로 Azure Cloud의 Azure Key Vault는 배포 중에 BitLocker 키 및 기타 중요한 구성 데이터를 포함하여 Azure 로컬 비밀에 대한 보안 백업 역할을 하도록 프로비전됩니다.
이점
Azure Local에서 Key Vault와 함께 로컬 ID를 사용하면 특히 AD에 의존하지 않는 환경에 대해 몇 가지 이점이 있습니다. 다음은 몇 가지 주요 이점입니다.
최소화된 엣지 인프라. AD를 사용하지 않는 환경의 경우 Key Vault를 사용하는 로컬 ID는 사용자 ID 및 비밀을 관리하는 안전하고 효율적인 방법을 제공합니다.
비밀 저장소 Key Vault는 BitLocker 키, 노드 암호 및 기타 중요한 정보와 같은 비밀을 안전하게 관리하고 저장합니다. 이렇게 하면 무단 액세스의 위험이 줄어들고 전반적인 보안 태세가 향상됩니다.
간소화된 관리를 유지 관리합니다. 조직은 Key Vault와 통합하여 비밀 및 자격 증명 관리를 간소화할 수 있습니다. 여기에는 배포 및 로컬 ID 비밀을 단일 금고에 저장하여 이러한 비밀을 보다 쉽게 관리하고 접근할 수 있도록 하는 것이 포함됩니다.
간소화된 배포. Azure Portal을 통해 시스템을 배포하는 동안 Key Vault와 통합된 로컬 ID 공급자를 선택할 수 있습니다. 이 옵션은 필요한 모든 비밀이 Key Vault 내에 안전하게 저장되도록 하여 배포 프로세스를 간소화합니다. 지속적인 유지 관리가 필요한 기존 AD 시스템 또는 AD를 실행하는 다른 시스템에 대한 종속성을 줄이면 배포의 효율성이 높아집니다. 또한 이 방법은 운영 기술 네트워크에 대한 방화벽 구성을 간소화하여 이러한 환경을 보다 쉽게 관리하고 보호할 수 있도록 합니다.
필수 조건
필수 구성 요소를 충족하고 배포 검사 목록을 완료합니다. AD 관련 사전 요구 사항을 건너뜁니다.
모든 노드에서 동일한 자격 증명을 사용하여 로컬 사용자 계정을 만들고 기본 제공 관리자 계정을 사용하는 대신 로컬 관리자 그룹에 추가합니다.
클러스터의 모든 노드에서 동일한 자격 증명을 사용하여 로컬 관리자 계정을 만듭니다. 이 요구 사항은 노드 추가 및 복구 작업이 모든 노드에서 성공적으로 인증 및 실행되도록 보장합니다. 지침은 노드 추가 및 노드 복구를 참조하세요.
Azure 로컬 소프트웨어를 다운로드합니다. Azure 로컬 배포에 대한 운영 체제 다운로드를 참조하세요.
노드에는 고정 IP 주소가 필요하며 DHCP를 지원하지 않습니다. OS가 설치되면 SConfig를 사용하여 고정 IP 주소, 서브넷, 게이트웨이 및 DNS를 설정합니다.
제대로 구성된 영역이 있는 DNS 서버가 있어야 합니다. 이 설정은 네트워크가 올바르게 작동하는 데 중요합니다. Azure Local에 대한 DNS 서버 구성을 참조하세요.
Azure Local에 대한 DNS 서버 구성
다음 단계에 따라 Azure Local에 대한 DNS를 구성합니다.
DNS 서버를 만들고 구성합니다.
DNS 서버가 아직 없는 경우 설정합니다. 이 작업은 Windows Server DNS 또는 다른 DNS 솔루션을 사용하여 수행할 수 있습니다.
DNS 호스트 A 레코드를 만듭니다.
Azure 로컬 인스턴스의 각 노드에 대해 DNS 호스트 A 레코드를 만듭니다. 이 레코드는 노드의 호스트 이름을 IP 주소에 매핑하여 네트워크의 다른 디바이스가 노드를 찾아서 통신할 수 있도록 합니다.
또한 시스템 자체에 대한 DNS 호스트 A 레코드를 만듭니다. 이 레코드는 시스템에 할당한 네트워크 범위의 첫 번째 IP 주소를 사용해야 합니다.
DNS 레코드를 확인합니다.
특정 컴퓨터에 대한 DNS 레코드가 올바르게 설정되었는지 확인하려면 다음 명령을 실행합니다.
nslookup "machine name"DNS 전달을 설정합니다.
필요에 따라 DNS 쿼리를 Azure DNS 또는 다른 외부 DNS 공급자로 전달하도록 DNS 서버에서 DNS 전달을 구성합니다.
네트워크 설정을 업데이트합니다.
구성한 DNS 서버를 사용하도록 Azure 로컬 노드의 네트워크 설정을 업데이트합니다. 네트워크 어댑터 설정을 통해 또는 PowerShell 명령을 사용하여 이 작업을 수행할 수 있습니다.
DNS 구성을 확인합니다.
DNS 구성을 테스트하여 DNS 쿼리가 올바르게 확인되었는지 확인합니다.
nslookup또는 dig와 같은 도구를 사용하여 DNS 해상도를 확인할 수 있습니다.다음 명령을 사용하여 로컬 및 원격 컴퓨터에서 운영 체제를 다시 시작합니다.
Restart-Computer
Key Vault에서 로컬 ID를 사용하여 포털을 통해 Azure 로컬 배포
Azure Portal을 통해 배포하는 동안 Key Vault와 통합된 로컬 ID 공급자를 선택할 수 있습니다. 이렇게 하면 인증을 위해 AD를 사용하는 대신 Key Vault에서 로컬 ID를 사용하여 비밀을 안전하게 관리하고 저장할 수 있습니다.
일반 배포 단계는 Azure Portal을 사용하여 Azure 로컬 시스템 배포에 설명된 단계와 동일합니다. 그러나 Key Vault에서 로컬 ID를 사용하는 경우 네트워킹 및 관리 탭에서 특정 단계를 수행해야 합니다.
네트워킹 탭
유효한 영역 이름 (도메인)을 제공하여 클러스터에 대한 신뢰할 수 있는 프라이빗 DNS 네임스페이스를 설정합니다. 이 도메인은 내부적으로(내부 전용 호스트 및 워크로드의 경우) 또는 클러스터의 가시성 요구 사항에 따라 외부에서(공개적으로 사용 가능한 호스트 및 워크로드의 경우) 확인할 수 있어야 합니다.
Azure 로컬에 대한 DNS 구성 섹션에 구성된 DNS 서버 세부 정보를 제공합니다.
관리 탭
Azure Key Vault를 사용하여 로컬 ID 옵션을 선택합니다.
새 Key Vault를 만들려면 새 Key Vault 만들기를 선택합니다. 올바른 컨텍스트 창에 필요한 세부 정보를 입력한 다음 만들기를 선택합니다.
Key Vault 이름에 새 Key Vault 이름을 입력합니다. 클러스터당 하나의 Key Vault를 만들어야 합니다.
배포 후 단계
시스템을 배포한 후 배포가 AD가 없는지 확인하고 비밀이 Key Vault에 백업되고 있는지 확인합니다.
Active Directory 없이 시스템이 배포되었는지 확인
시스템을 배포한 후 AD 없이 배포되었는지 확인합니다.
다음 명령을 실행하여 노드가 AD 도메인에 조인되지 않는지 확인합니다.
WORKGROUP가 출력되면, 노드가 도메인에 가입되지 않았습니다.Get-WmiObject Win32_ComputerSystem.Domain샘플 출력은 다음과 같습니다.
[host]: PS C:\Users\LocalAdmin\Documents> (Get-WmiObject Win32_ComputerSystem).Domain WORKGROUP클러스터가 AD 없이 작동하는 작업 그룹 클러스터인지 확인합니다. 다음 명령을 실행하고 매개 변수 값을
ADAware확인합니다.Get-ClusterResource "Cluster Name" | Get-ClusterParameter ADAware Object Name Value Type ------ ---- ----- ---- ClusterName ADAware 2 UInt32 For ADAware property, 0 = None, 1 = AD, 2 = Local Identity
비밀이 Key Vault에 백업되는지 확인
BitLocker 키 및 복구 관리자 암호는 Azure에 안전하게 백업되고 최대 보안을 보장하기 위해 회전됩니다.
AD를 사용할 수 없는 시나리오에서는 전용 복구 관리자 사용자를 활용하여 시스템을 복원할 수 있습니다. 이 용도로 지정된 사용자 이름은 .입니다 RecoveryAdmin. Azure Key Vault에서 해당 암호를 안전하게 검색하여 시스템 복구 작업을 효과적으로 수행하는 데 필요한 자격 증명이 있는지 확인할 수 있습니다.
이렇게 하면 모든 중요한 정보가 안전하게 저장되고 필요할 때 쉽게 검색할 수 있으므로 인프라에 대한 추가 보안 및 안정성 계층을 제공합니다.
Azure 로컬의 Key Vault 확장에 대한 경고
Azure Local은 Key Vault 확장을 사용하여 비밀을 안전하게 저장하고 관리합니다. 안정성과 보안을 보장하기 위해 시스템은 Key Vault 통합의 상태를 지속적으로 모니터링합니다. 문제가 감지되면 경고가 자동으로 생성되어 가시성과 대응을 위해 Azure Monitor를 통해 표시됩니다.
경고는 Azure Alerts 게이트웨이를 통해 전송되며 모니터> 경고 아래의 Azure Portal에서 볼 수있습니다. 이메일, SMS 또는 웹후크를 통해 알림을 받도록 작업 그룹을 구성할 수 있습니다. 자세한 내용은 Azure Monitor 경고란?을 참조하세요.
다음 표에서는 사용 가능한 경고, 해당 영향 및 해결하기 위한 권장 작업에 대해 설명합니다.
| 경고 | Description | Impact | 권장 작업 |
|---|---|---|---|
| KeyVault존재하지 않습니다 | 지정된 Key Vault가 없습니다. | 비밀을 안전하게 백업하고 저장하려면 Key Vault가 필요합니다. 이 작업이 없으면 비밀 백업 작업이 실패합니다. | - Key Vault 리소스가 Azure 구독에 있는지 확인합니다. - Key Vault 이름 및 리소스 그룹이 배포의 구성과 일치하는지 확인합니다. - Key Vault가 삭제된 경우 다시 만들고 구성을 업데이트합니다. |
| KeyVaultAccess | 하나 이상의 클러스터 노드가 Key Vault에 액세스할 수 없습니다. | 노드가 Key Vault에 액세스할 수 없는 경우 비밀 검색 또는 백업이 필요한 작업이 실패할 수 있습니다. | - 클러스터 노드와 Key Vault 엔드포인트 간의 네트워크 연결을 확인합니다. - Key Vault 방화벽 및 액세스 정책에서 클러스터 노드를 연결할 수 있는지 확인합니다. - 클러스터에서 사용하는 관리 ID 또는 서비스 주체에 필요한 권한(예: 가져오기, 목록 및 백업)이 있는지 확인합니다. 또한 노드와 연결된 관리 ID(서버 리소스용 Arc)에는 Key Vault의 Key Vault 비밀 책임자 역할이 할당되어야 합니다. |
Azure 로컬에서 Key Vault 업데이트
다음 단계에 따라 새 Key Vault를 사용하도록 백업 구성을 업데이트합니다.
Azure Portal에서 새 Key Vault를 만듭니다. 백업 비밀을 저장하도록 구성합니다.
새 Key Vault에 대한 액세스 제어를 설정합니다. 여기에는 노드 ID에 필요한 권한을 부여하는 것이 포함됩니다. Key Vault에 Key Vault 비밀 책임자 역할이 할당되었는지 확인합니다. 지침은 Azure 역할 기반 액세스 제어를 사용하여 Key Vault 키, 인증서 및 비밀에 대한 액세스 제공을 참조하세요.
시스템 구성을 업데이트합니다. POST 요청을 사용하여 새 Key Vault 세부 정보로 클러스터 구성을 업데이트합니다. POST API를 실행하려면 Azure Stack HCI 관리자 역할이 할당되어 있어야 합니다. 자세한 내용은 역할 기반 액세스 제어를 사용하여 Azure Arc에 의해 활성화된 Azure 로컬 VM을 관리하세요.
다음 명령을 실행하여 Azure 구독에 로그인합니다.
Connect-AzAccount다음 명령을 실행하여 구독 컨텍스트를 확인합니다.
Get-AzContext인증되면 cmdlet을
Invoke-AzRestMethod사용하여 POST 요청을 보냅니다. 그러면 클러스터가 새 Key Vault 위치로 업데이트됩니다.
샘플 출력은 다음과 같습니다.
Invoke-AzRestMethod -Path "/subscriptions/<subscriptionId>/resourceGroups/<resourceGroupName>/providers/Microsoft.AzureStackHCI/clusters/<clusterName>/updateSecretsLocations" -Method POST -Payload { "properties": { "secretsType": "BackupSecrets", "secretsLocation": "https://hcikeyvaulttestingnew.vault.azure.net/" } } # Response: 200 OK구성의 유효성을 검사합니다. Azure Portal에서 시스템 리소스를 열고 Resource JSON 에 업데이트된 Key Vault 세부 정보가 포함되어 있는지 확인합니다.
Key Vault를 업데이트할 수 있는 Resource JSON 의 샘플 스크린샷은 다음과 같습니다.
새 Key Vault에서 비밀을 확인합니다. 모든 백업 비밀이 새 Key Vault에 제대로 저장되어 있는지 확인합니다.
이전 Key Vault를 정리합니다. 이전 Key Vault 및 해당 비밀은 자동으로 삭제되지 않습니다. 새 Key Vault가 올바르게 구성되었는지 확인한 후 필요한 경우 이전 Key Vault를 삭제할 수 있습니다.
삭제된 Key Vault 복구 및 백업 다시 시작
Key Vault를 삭제한 후 복구하는 경우 이전에 Key Vault에 액세스할 수 있었던 관리 ID는 다음과 같은 방법으로 영향을 받습니다.
- 관리 ID 액세스 해지 삭제 프로세스 중에 Key Vault에 대한 관리 ID의 액세스 권한이 취소됩니다. 즉, ID에 더 이상 Key Vault에 액세스할 수 있는 권한이 없습니다.
- 확장 작업의 실패입니다. 비밀 백업 관리를 담당하는 백업 키 자격 증명 모음 확장은 액세스에 대한 관리 ID에 의존합니다. 액세스 권한이 취소되면 확장에서 백업 작업을 수행할 수 없습니다.
- Azure Portal의 확장 상태입니다. Azure Portal에서 확장 상태는 필요한 권한 손실로 인해 확장을 백업할 수 없음을 나타내는 실패 로 표시됩니다.
실패한 확장 문제를 해결하고 해결하고 정상적인 백업 작업을 복원하려면 다음 단계를 수행합니다.
관리 ID 액세스를 다시 할당합니다.
- Key Vault에 액세스해야 하는 관리 ID를 결정합니다.
- Key Vault 비밀 책임자 역할을 관리 ID에 다시 할당합니다.
확장 기능을 확인합니다.
- 다시 할당한 후 Azure Portal에서 확장 상태를 모니터링하여 실패 에서 성공으로 변경되었는지 확인합니다. 이는 확장이 필요한 권한을 되찾았으며 이제 제대로 작동하고 있음을 나타냅니다.
- 백업 작업을 테스트하여 비밀이 올바르게 백업되고 백업 프로세스가 예상대로 작동하는지 확인합니다.
Azure Key Vault로 구성된 Azure 로컬 환경의 도구 호환성
ID 관리를 위해 Azure Key Vault로 구성된 Azure 로컬 환경의 도구 지원은 에코시스템에 따라 다릅니다. 다음 지침을 사용하여 이러한 구성에서 효과적으로 계획하고 작동합니다.
지원되는 도구
PowerShell을 사용합니다. AD 및 Azure Key Vault 기반 ID 환경 모두에 대해 완벽하게 지원됩니다. PowerShell은 ID 구성에서 Azure 로컬 클러스터를 관리하고 자동화하기 위한 기본 인터페이스입니다.
Azure Monitor. 호스트 및 가상 머신의 상태 및 성능을 모니터링하는 데 지원됩니다. Azure Monitor와 통합하면 시스템 상태, 경고 및 원격 분석을 볼 수 있습니다.
Azure Portal. Azure 로컬 클러스터 관리에 지원됩니다.
지원되지 않거나 제한된 지원 도구
- Windows Admin Center. Azure Key Vault 기반 ID 환경에서 지원되지 않습니다. PowerShell 또는 기타 지원되는 도구를 관리 작업에 사용해야 합니다.
- System Center Virtual Machine Manager(SCVMM). Azure Key Vault 기반 ID 환경에서 제한되거나 지원되지 않을 것으로 예상됩니다. SCVMM을 사용하기 전에 특정 사용 사례의 유효성을 검사합니다.
혼합 호환성
- MICROSOFT MMC(관리 콘솔). 호환성은 다양합니다. Hyper-V Manager 및 장애 조치(failover) 클러스터 관리자와 같은 도구는 모든 시나리오에서 작동하지 않을 수 있습니다. 프로덕션 사용을 위해 MMC를 사용하기 전에 중요한 워크플로를 테스트합니다.
자주 묻는 질문(FAQ)
이 섹션에서는 Key Vault에서 로컬 ID를 사용하는 방법에 대한 몇 가지 질문과 대답을 제공합니다.
배포 중에 Azure Key Vault 백업 비밀 확장이 설치되지 않은 경우 수행할 작업
배포 중에 확장이 설치되지 않은 경우 다음 단계에 따라 Arc 지원 서버에 수동으로 설치할 수 있습니다.
아직 없는 경우 새 Azure Key Vault를 만듭니다. Azure 포털을 사용하여 키 자격 증명 모음을 생성하려면 빠른 시작: 자격 증명 모음 만들기의 지침을 참조하세요.
Key Vault 페이지에서 액세스 제어(IAM)>역할 할당 추가로 이동합니다.
- 역할 탭에서 Key Vault 비밀 책임자를 선택합니다.
- 구성원 탭에서 관리 ID를 선택하고 Azure 로컬 클러스터를 멤버로 추가합니다.
- 검토 + 할당을 선택하여 역할 할당을 완료합니다.
역할 할당 탭 아래에 역할 할당 이 표시되는지 확인합니다.
Azure 로컬 클러스터로 이동하여 Arc 컴퓨터 이름을 기록해 둡니다.
다음 PowerShell 스크립트를 실행하여 Arc 머신에 확장을 설치합니다.
# Login to Azure Connect-AzAccount $ResourceGroup = "<Resource Group>" $ResourceLocation = "<Location>" $KeyVaultUri = "<URL of Azure Key Vault>" $ArcMachines = @("v-host1", "v-host2", "v-host3", "v-host4") foreach ($MachineName in $ArcMachines) { New-AzConnectedMachineExtension ` -Name AzureEdgeAKVBackupForWindows ` -ResourceGroupName $ResourceGroup ` -Location $ResourceLocation ` -MachineName $MachineName ` -Publisher Microsoft.Edge.Backup ` -ExtensionType AKVBackupForWindows ` -Setting @{KeyVaultUrl = $KeyVaultUri; UseClusterIdentity = $true} }Azure Portal에서 확장 상태를 확인하여 성공적으로 설치되었는지 확인합니다.
다음 단계
- 배포 중에 워크로드 볼륨을 만들지 않은 경우 각 볼륨에 대한 워크로드 볼륨 및 스토리지 경로를 만듭니다. 자세한 내용은 Azure 로컬 및 Windows Server 클러스터에서 볼륨 만들기 및 Azure Local에 대한 스토리지 경로 만들기를 참조하세요.
- Azure 로컬 배포 문제에 대한 지원 받기
이 기능은 Azure Local 2411 이상에서만 사용할 수 있습니다.