Azure Key Vault Provider for Secrets Store CSI 드라이버 문제 해결
이 문서에서는 AKS(Azure Kubernetes Service)에서 Microsoft Azure Key Vault Provider for Secrets Store CSI(Container Storage Interface) 드라이버를 사용할 때 발생할 수 있는 일반적인 문제에 대해 설명합니다. 이 문서에서는 이러한 문제를 해결하기 위한 문제 해결 팁을 제공합니다.
필수 구성 요소
Kubernetes kubectl 도구(Azure CLI를 사용하여 kubectl을 설치하려면 az aks install-cli 명령을 실행합니다.)
AKS 클러스터에서 사용하도록 설정된 Kubernetes 비밀 저장소 CSI 드라이버 추가 기능
클라이언트 URL(curl) 도구
TCP 연결을 위한 Netcat (
nc) 명령줄 도구
문제 해결 검사 목록
Azure Key Vault 로그는 공급자 및 드라이버 Pod에서 사용할 수 있습니다. 공급자 또는 드라이버에 영향을 주는 문제를 해결하려면 애플리케이션 Pod가 실행되는 동일한 노드에서 실행되는 공급자 또는 드라이버 Pod의 로그를 검사합니다.
문제 해결 1단계: 비밀 저장소 공급자 로그 확인
애플리케이션 Pod가 실행되는 동일한 노드에서 실행되는 Pod를 찾으 secrets-store-provider-azure 려면 애플리케이션을 선택하는 secrets-store-provider-azure 다음 kubectl get 및 kubectl 로그 명령을 실행합니다.
kubectl get pods --selector 'app in (csi-secrets-store-provider-azure, secrets-store-provider-azure)' \
--all-namespaces \
--output wide
kubectl logs <provider-pod-name> --since=1h | grep ^E
문제 해결 2단계: 비밀 저장소 CSI 드라이버 로그 확인
비밀 저장소 CSI 드라이버 로그에 액세스하려면 1단계와 동일한 명령을 실행하지만 대신 애플리케이션을 secrets-store-csi-driver 선택하고 컨테이너를 secrets-store 지정합니다.
kubectl get pods --selector app=secrets-store-csi-driver --all-namespaces --output wide
kubectl logs <driver-pod-name> --container secrets-store --since=1h | grep ^E
참고
지원 요청을 여는 경우 Azure Key Vault 공급자 및 비밀 저장소 CSI 드라이버의 관련 로그를 포함하는 것이 좋습니다.
원인 1: 키 자격 증명 모음 토큰을 검색할 수 없습니다.
로그 또는 이벤트 메시지에 다음 오류 항목이 표시될 수 있습니다.
경고 FailedMount 74s kubelet MountVolume.SetUp이 볼륨 "secrets-store-inline" : kubernetes.io/csi: 탑재자에 대해 실패했습니다. SetupAt 실패: rpc 오류: 코드 = 알 수 없는 desc = Pod 기본/테스트에 대한 비밀 저장소 개체를 탑재하지 못했습니다. 오류: rpc 오류: 코드 = 알 수 없는 desc = 개체를 탑재하지 못했습니다. 오류: keyvault 클라이언트를 얻지 못했습니다. 키 자격 증명 모음 토큰을 얻지 못했습니다. 상태 코드로 nmi 응답 실패: 404, err: <nil>
이 오류는 aad-pod-identity 의 NMI(노드 관리 ID) 구성 요소가 토큰 요청에 대한 오류 메시지를 반환했기 때문에 발생합니다.
해결 방법 1: NMI Pod 로그 확인
이 오류 및 resolve 방법에 대한 자세한 내용은 NMI Pod 로그를 검사 Microsoft Entra Pod ID 문제 해결 가이드를 참조하세요.
원인 2: 공급자 Pod가 키 자격 증명 모음에 액세스할 수 instance
로그 또는 이벤트 메시지에 다음 오류 항목이 표시될 수 있습니다.
E1029 17:37:42.461313 1 server.go:54]에서 탑재 요청, 오류: keyvault를 처리하지 못했습니다. BaseClient#GetSecret: 요청 전송 실패: StatusCode=0 -- 원래 오류: 컨텍스트 최종 기한 초과
이 오류는 공급자 Pod가 instance 키 자격 증명 모음에 액세스할 수 없기 때문에 발생합니다. 다음과 같은 이유로 액세스가 차단될 수 있습니다.
방화벽 규칙은 공급자의 송신 트래픽을 차단합니다.
AKS 클러스터에 구성된 네트워크 정책은 송신 트래픽을 차단하고 있습니다.
공급자 Pod는 호스트 네트워크에서 실행됩니다. 정책이 이 트래픽을 차단하거나 노드에서 네트워크 지터가 발생하는 경우 오류가 발생할 수 있습니다.
해결 방법 2: 네트워크 정책, 허용 목록 및 노드 연결 확인
이 문제를 해결하려면 다음 작업을 수행합니다.
허용 목록에 공급자 Pod를 배치합니다.
트래픽을 차단하도록 구성된 정책을 확인합니다.
노드가 Microsoft Entra ID 및 키 자격 증명 모음에 연결되어 있는지 확인합니다.
호스트 네트워크에서 실행되는 Pod에서 Azure Key Vault에 대한 연결을 테스트하려면 다음 단계를 수행합니다.
Pod를 만듭니다.
cat <<EOF | kubectl apply --filename - apiVersion: v1 kind: Pod metadata: name: curl spec: hostNetwork: true containers: - args: - tail - -f - /dev/null image: curlimages/curl:7.75.0 name: curl dnsPolicy: ClusterFirst restartPolicy: Always EOFkubectl exec를 실행하여 만든 Pod에서 명령을 실행합니다.
kubectl exec --stdin --tty curl -- shAzure Key Vault를 사용하여 인증:
curl -X POST 'https://login.microsoftonline.com/<aad-tenant-id>/oauth2/v2.0/token' \ -d 'grant_type=client_credentials&client_id=<azure-client-id>&client_secret=<azure-client-secret>&scope=https://vault.azure.net/.default'Azure 키 자격 증명 모음에 이미 만들어진 비밀을 가져옵니다.
curl -X GET 'https://<key-vault-name>.vault.azure.net/secrets/<secret-name>?api-version=7.2' \ -H "Authorization: Bearer <access-token-acquired-above>"
원인 3: SecretProviderClass 사용자 지정 리소스에서 사용자 할당 관리 ID가 잘못되었습니다.
"ID를 찾을 수 없음" 오류 설명과 함께 HTTP 오류 코드 "400" instance 발생하는 경우 사용자 지정 리소스에서 SecretProviderClass 사용자 할당 관리 ID가 올바르지 않습니다. 전체 응답은 다음 텍스트와 유사합니다.
MountVolume.SetUp failed for volume "<volume-name>" :
rpc error:
code = Unknown desc = failed to mount secrets store objects for pod <namespace>/<pod>,
err: rpc error: code = Unknown desc = failed to mount objects,
error: failed to get objectType:secret, objectName:<key-vault-secret-name>, objectVersion:: azure.BearerAuthorizer#WithAuthorization:
Failed to refresh the Token for request to https://<key-vault-name>.vault.azure.net/secrets/<key-vault-secret-name>/?api-version=2016-10-01:
StatusCode=400 -- Original Error: adal: Refresh request failed.
Status Code = '400'.
Response body: {"error":"invalid_request","error_description":"Identity not found"}
Endpoint http://169.254.169.254/metadata/identity/oauth2/token?api-version=2018-02-01&client_id=<userAssignedIdentityID>&resource=https%!!(MISSING)A(MISSING)%!!(MISSING)F(MISSING)%!!(MISSING)F(MISSING)vault.azure.net
해결 방법 3: 올바른 userAssignedIdentityID 값을 사용하여 SecretProviderClass 업데이트
올바른 사용자 할당 관리 ID를 찾은 다음 사용자 지정 리소스를 SecretProviderClass 업데이트하여 매개 변수에 userAssignedIdentityID 올바른 값을 지정합니다. 올바른 사용자 할당 관리 ID를 찾으려면 Azure CLI에서 다음 az aks show 명령을 실행합니다.
az aks show --resource-group <resource-group-name> \
--name <cluster-name> \
--query addonProfiles.azureKeyvaultSecretsProvider.identity.clientId \
--output tsv
YAML 형식으로 SecretProviderClass 사용자 지정 리소스를 설정하는 방법에 대한 자세한 내용은 Azure Key Vault Provider for Secrets Store CSI 드라이버에 액세스하기 위해 ID 제공 문서의 사용자 할당 관리 ID 사용 섹션을 참조하세요.
원인 4: Key Vault 프라이빗 엔드포인트가 AKS 노드와 다른 가상 네트워크에 있습니다.
공용 네트워크 액세스는 Azure Key Vault 수준에서 허용되지 않으며 AKS와 Key Vault 간의 연결은 프라이빗 링크를 통해 이루어집니다. 그러나 AKS 노드와 Key Vault 프라이빗 엔드포인트는 서로 다른 가상 네트워크에 있습니다. 이 시나리오에서는 다음 텍스트와 유사한 메시지를 생성합니다.
MountVolume.SetUp failed for volume "<volume>" :
rpc error:
code = Unknown desc = failed to mount secrets store objects for pod <namespace>/<pod>,
err: rpc error: code = Unknown desc = failed to mount objects,
error: failed to get objectType:secret, objectName: :<key-vault-secret-name>, objectVersion:: keyvault.BaseClient#GetSecret:
Failure responding to request:
StatusCode=403 -- Original Error: autorest/azure: Service returned an error.
Status=403 Code="Forbidden"
Message="Public network access is disabled and request is not from a trusted service nor via an approved private link.\r\n
Caller: appid=<application-id>;oid=<object-id>;iss=https://sts.windows.net/<id>/;xms_mirid=/subscriptions/<subscription-id>/resourcegroups/<aks-infrastructure-resource-group>/providers/Microsoft.Compute/virtualMachineScaleSets/aks-<nodepool-name>-<nodepool-id>-vmss;xms_az_rid=/subscriptions/<subscription-id>/resourcegroups/<aks-infrastructure-resource-group>/providers/Microsoft.Compute/virtualMachineScaleSets/aks-<nodepool-name>-<nodepool-id>-vmss \r\n
Vault: <keyvaultname>;location=<location>" InnerError={"code":"ForbiddenByConnection"}
해결 방법 4a: 가상 네트워크를 연결하도록 가상 네트워크 링크 및 가상 네트워크 피어링 설정
연결 문제 해결은 일반적으로 2단계 프로세스입니다.
프라이빗 Azure DNS 영역 수준에서 AKS 클러스터의 가상 네트워크에 대한 가상 네트워크 링크를 만듭니다.
AKS 클러스터의 가상 네트워크와 Key Vault 프라이빗 엔드포인트의 가상 네트워크 간에 가상 네트워크 피어링을 추가합니다.
이러한 단계는 다음 섹션에서 자세히 설명합니다.
1단계: 가상 네트워크 링크 만들기
AKS 클러스터 노드에 연결하여 Key Vault FQDN(정규화된 도메인 이름)이 공용 IP 주소 또는 개인 IP 주소를 통해 확인되는지 여부를 확인합니다. "공용 네트워크 액세스가 사용하지 않도록 설정되어 있고 요청이 신뢰할 수 있는 서비스나 승인된 프라이빗 링크를 통해서가 아닙니다" 오류 메시지가 표시되면 Key Vault 엔드포인트는 공용 IP 주소를 통해 해결될 수 있습니다. 이 시나리오를 검사 nslookup 명령을 실행합니다.
nslookup <key-vault-name>.vault.azure.net
공용 IP 주소를 통해 FQDN을 확인하는 경우 명령 출력은 다음 텍스트와 유사합니다.
root@aks-<nodepool-name>-<nodepool-id>-vmss<scale-set-instance>:/# nslookup <key-vault-name>.vault.azure.net
Server: 168.63.129.16
Address: 168.63.129.16#53
Non-authoritative answer:
<key-vault-name>.vault.azure.net canonical name = <key-vault-name>.privatelink.vaultcore.azure.net.
<key-vault-name>.privatelink.vaultcore.azure.net canonical name = data-prod.weu.vaultcore.azure.net.
data-prod-weu.vaultcore.azure.net canonical name = data-prod-weu-region.vaultcore.azure.net.
data-prod-weu-region.vaultcore.azure.net canonical name = azkms-prod-weu-b.westeurope.cloudapp.azure.com.
Name: azkms-prod-weu-b.westeurope.cloudapp.azure.com
Address: 20.1.2.3
이 경우 프라이빗 DNS 영역 수준에서 AKS 클러스터의 가상 네트워크에 대한 가상 네트워크 링크를 만듭니다. (가상 네트워크 링크는 이미 Key Vault 프라이빗 엔드포인트의 가상 네트워크에 대해 자동으로 만들어집니다.)
가상 네트워크 링크를 만들려면 다음 단계를 수행합니다.
Azure Portal프라이빗 DNS 영역을 검색하여 선택합니다.
프라이빗 DNS 영역 목록에서 프라이빗 DNS 영역의 이름을 선택합니다. 이 예제에서는 프라이빗 DNS 영역이 privatelink.vaultcore.azure.net.
프라이빗 DNS 영역의 탐색 창에서 설정 제목을 찾은 다음 가상 네트워크 링크를 선택합니다.
가상 네트워크 링크 목록에서 추가를 선택합니다.
가상 네트워크 추가 링크 페이지에서 다음 필드를 완료합니다.
필드 이름 작업 링크 이름 가상 네트워크 링크에 사용할 이름을 입력합니다. 구독. 가상 네트워크 링크를 포함할 구독의 이름을 선택합니다. 가상 네트워크 AKS 클러스터의 가상 네트워크 이름을 선택합니다. 시작 단추를 선택합니다.
링크 만들기 프로시저를 완료한 후 명령을 실행합니다 nslookup . 이제 출력은 보다 직접적인 DNS 확인을 보여 주는 다음 텍스트와 유사합니다.
root@aks-<nodepool-name>-<nodepool-id>-vmss<scale-set-instance>:/# nslookup <key-vault-name>.vault.azure.net
Server: 168.63.129.16
Address: 168.63.129.16#53
Non-authoritative answer:
<key-vault-name>.vault.azure.net canonical name = <key-vault-name>.privatelink.vaultcore.azure.net.
Name: <key-vault-name>.privatelink.vaultcore.azure.net
Address: 172.20.0.4
가상 네트워크 링크가 추가되면 개인 IP 주소를 통해 FQDN을 확인할 수 있어야 합니다.
2단계: 가상 네트워크 간에 가상 네트워크 피어링 추가
프라이빗 엔드포인트를 사용하는 경우 Key Vault 수준에서 공용 액세스를 사용하지 않도록 설정했을 수 있습니다. 따라서 AKS와 Key Vault 간에 연결이 없습니다. 다음 Netcat(nc) 명령을 사용하여 해당 구성을 테스트할 수 있습니다.
nc -v -w 2 <key-vault-name>.vault.azure.net 443
AKS와 Key Vault 간에 연결을 사용할 수 없는 경우 다음 텍스트와 유사한 출력이 표시됩니다.
nc: connect to <key-vault-name>.vault.azure.net port 443 (tcp) timed out: Operation now in progress
AKS와 Key Vault 간의 연결을 설정하려면 다음 단계에 따라 가상 네트워크 간에 가상 네트워크 피어링을 추가합니다.
Azure Portal로 이동합니다.
다음 옵션 중 하나를 사용하여 자습서: 가상 네트워크 피어링에 가상 네트워크 연결 문서의 지침에 따라 Azure Portal 문서를 사용하여 가상 네트워크를 피어링하고 가상 네트워크가 연결되어 있는지 확인합니다(한쪽 끝에서).
AKS 가상 네트워크로 이동하여 Key Vault 프라이빗 엔드포인트의 가상 네트워크에 피어링합니다.
Key Vault 프라이빗 엔드포인트의 가상 네트워크로 이동하여 AKS 가상 네트워크에 피어링합니다.
Azure Portal 다른 가상 네트워크(이전 단계에서 피어링한 가상 네트워크)의 이름을 검색하여 선택합니다.
가상 네트워크 탐색 창에서 설정 제목을 찾은 다음 피어링을 선택합니다.
가상 네트워크 피어링 페이지에서 이름 열에 2단계에서 지정한 원격 가상 네트워크의피어링 링크 이름이 포함되어 있는지 확인합니다. 또한 해당 피어링 링크의 피어링 상태 열에 연결된 값이 있는지 확인합니다.
이 절차를 완료한 후 Netcat 명령을 다시 실행할 수 있습니다. 이제 AKS와 Key Vault 간의 DNS 확인 및 연결이 성공해야 합니다. 또한 다음 출력과 같이 Key Vault 비밀이 성공적으로 탑재되고 예상대로 작동하는지 확인합니다.
Connection to <key-vault-name>.vault.azure.net 443 port [tcp/https] succeeded!
해결 방법 4b: 오류 코드 403 문제 해결
Azure Key Vault REST API 오류 코드 참조 문서의 HTTP 403: 권한 부족 섹션을 검토하여 오류 코드 "403"을 해결합니다.
원인 5: 등록된 CSI 드라이버 목록에서 secrets-store.csi.k8s.io 드라이버가 없습니다.
Pod 이벤트에서 누락된 secrets-store.csi.k8s.io 드라이버에 대한 다음 오류 메시지가 표시되면 비밀 저장소 CSI 드라이버 Pod가 애플리케이션이 실행 중인 노드에서 실행되지 않습니다.
경고 FailedMount 42s(x12 over 8m56s) kubelet, akswin000000 MountVolume.SetUp이 볼륨 "secrets-store01-inline" : kubernetes.io/csi: 탑재자에 대해 실패했습니다. SetUpAt에서 CSI 클라이언트를 얻지 못했습니다. 등록된 CSI 드라이버 목록에서 드라이버 이름 secrets-store.csi.k8s.io 찾을 수 없습니다.
해결 방법 5a: 비밀 저장소 CSI 드라이버 설치
배포 매니페스트를 사용하여 Key Vault 공급자를 설치한 경우 지침에 따라 비밀 저장소 CSI 드라이버를 설치합니다.
해결 방법 5b: taint toleration을 추가하여 비밀 저장소 CSI 드라이버 및 Key Vault 공급자 다시 배포
비밀 저장소 CSI 드라이버를 이미 배포한 경우 노드가 오염되었는지 여부를 검사. 노드가 오염된 경우 taint에 대한 관용을 추가하여 비밀 저장소 CSI 드라이버 및 Key Vault 공급자를 다시 배포합니다.
해결 방법 5c: (Windows에만 해당) 비밀 저장소 CSI 드라이버 및 Key Vault 공급자를 설치할 때 Helm 구성 값 사용
애플리케이션이 Windows 노드에서 실행되는 경우 Helm 구성 값을 사용하여 Windows 노드에 비밀 저장소 CSI 드라이버 및 Key Vault 공급자를 설치합니다.
원인 6: 드라이버가 공급자와 통신할 수 없습니다.
로그 또는 이벤트에서 다음 오류 메시지가 표시되면 드라이버는 공급자와 통신할 수 없습니다.
경고 FailedMount 85s(x10 over 5m35s) kubelet, aks-default-28951543-vmss000000 MountVolume.SetUp이 볼륨 "secrets-store01-inline" : kubernetes.io/csi: 탑재자에 대해 실패했습니다. SetupAt 실패: rpc 오류: code = Unknown desc = Pod default/nginx-secrets-store-inline-user-msi에 대한 비밀 저장소 개체를 탑재하지 못했습니다. err: 공급자 이진 azure를 찾지 못했습니다. err: stat /etc/kubernetes/secrets-store-csi-providers/azure/provider-azure: 이러한 파일 또는 디렉터리가 없습니다.
해결 방법 6a: (버전 0.0.9 이전의 공급자 버전) 공급자 Pod가 모든 노드에서 실행되는지 확인합니다.
설치된 Key Vault 공급자 버전이 버전 0.0.9보다 이전인 경우 공급자 Pod가 모든 노드에서 실행되고 있는지 확인합니다.
해결 방법 6b: (공급자 버전 0.0.9 이상) 공급자 통신에 gRPC 사용
Key Vault 공급자 버전 0.0.9 이상을 설치한 경우 gRPC를 사용하여 공급자와 통신하도록 드라이버를 구성합니다.
원인 7: CSI 드라이버가 Kubernetes 비밀을 만들 수 없습니다.
CSI 드라이버의 비밀 저장소 컨테이너에서 다음 오류 메시지가 표시되는 경우 RBAC(역할 기반 액세스 제어) 클러스터 역할 및 클러스터 역할 바인딩을 설치하지 않은 것입니다. CSI 드라이버가 탑재된 콘텐츠를 Kubernetes 비밀로 동기화하려면 클러스터 역할 및 클러스터 역할 바인딩이 필요합니다.
E0610 22:27:02.283100 1 secretproviderclasspodstatus_controller.go:325] "Kubernetes 비밀을 만들지 못했습니다." err="비밀은 사용할 수 없습니다. 사용자 \"system:serviceaccount:default:secrets-store-csi-driver\"는 API 그룹 \"\"에서 리소스 \"secrets\"을(를) 만들 수 없습니다. namespace \"default\"" spc="default/azure-linux" pod="default/busybox-linux-5f479855f7-jvfw4" secret="default/dockerconfig" spcps="default/busybox-linux-5f479855f7-jvfw4-default-azure-linux"
해결 방법 7: 필요한 클러스터 역할 및 클러스터 역할 바인딩 설치
secrets-store-csi-driver-provider-azure GitHub 리포지토리에서 Helm 차트를 사용하여 CSI 드라이버 및 Key Vault 공급자를 설치하거나 업그레이드하는 경우 Helm 매개 변수를 로 true설정합니다secrets-store-csi-driver.syncSecret.enabled. 이 구성 변경은 필요한 클러스터 역할 및 클러스터 역할 바인딩을 설치합니다.
클러스터 역할 및 클러스터 역할 바인딩이 설치되어 있는지 확인하려면 다음 kubectl get 명령을 실행합니다.
# Synchronize as Kubernetes secret cluster role.
kubectl get clusterrole/secretprovidersyncing-role
# Synchronize as Kubernetes secret cluster role binding.
kubectl get clusterrolebinding/secretprovidersyncing-rolebinding
원인 8: 요청이 인증되지 않음
요청은 "401" 오류 코드로 표시된 대로 Key Vault 대해 인증되지 않습니다.
해결 방법 8: 오류 코드 401 문제 해결
Azure Key Vault REST API 오류 코드 참조 문서의 "HTTP 401: 인증되지 않은 요청" 섹션을 검토하여 오류 코드 "401"을 해결합니다.
원인 9: 요청 수가 명시된 최대값을 초과합니다.
요청 수가 "429" 오류 코드에 표시된 대로 시간 프레임에 대해 명시된 최대값을 초과합니다.
해결 방법 9: 오류 코드 429 문제 해결
Azure Key Vault REST API 오류 코드 참조 문서의 "HTTP 429: 너무 많은 요청" 섹션을 검토하여 오류 코드 "429"를 해결합니다.
타사 정보 고지 사항
이 문서에 나와 있는 다른 공급업체 제품은 Microsoft와 무관한 회사에서 제조한 것입니다. Microsoft는 이들 제품의 성능이나 안정성에 관하여 명시적이든 묵시적이든 어떠한 보증도 하지 않습니다.
도움을 요청하십시오.
질문이 있거나 도움이 필요한 경우 지원 요청을 생성하거나Azure 커뮤니티 지원에 문의하세요. Azure 피드백 커뮤니티에 제품 피드백을 제출할 수도 있습니다.
피드백
출시 예정: 2024년 내내 콘텐츠에 대한 피드백 메커니즘으로 GitHub 문제를 단계적으로 폐지하고 이를 새로운 피드백 시스템으로 바꿀 예정입니다. 자세한 내용은 다음을 참조하세요. https://aka.ms/ContentUserFeedback
다음에 대한 사용자 의견 제출 및 보기