Azure Arc 지원 Kubernetes 클러스터에서 오프라인 액세스를 위해 비밀 저장소 확장을 사용하여 비밀을 가져옵니다.

아티클
11/19/2024

Kubernetes용 Azure Key Vault 비밀 저장소 확장("SSE")은 오프라인 액세스를 위해 Azure Key Vault 에서 Azure Arc 지원 Kubernetes 클러스터로 비밀을 자동으로 동기화합니다. 즉, Kubernetes 클러스터를 반 연결이 끊긴 상태로 실행하는 경우에도 Azure Key Vault를 사용하여 비밀을 저장, 유지 관리하고 회전할 수 있습니다. 동기화된 비밀은 클러스터 비밀 저장소에 저장되어 Kubernetes 비밀로 제공되어 데이터 볼륨으로 탑재하거나 Pod의 컨테이너에 환경 변수로 노출하는 등 일반적인 모든 방식으로 사용할 수 있습니다.

동기화된 비밀은 중요한 비즈니스 자산이므로 SSE는 격리된 네임스페이스 및 노드, RBAC(역할 기반 액세스 제어) 정책 및 비밀 동기화 장치에 대한 제한된 권한을 통해 비밀을 보호합니다. 추가 보호를 위해 클러스터에서 Kubernetes 비밀 저장소를 암호화 합니다.

팁

오프라인 액세스가 필요하거나 Kubernetes 비밀 저장소에 동기화된 비밀이 필요한 시나리오에는 SSE를 사용하는 것이 좋습니다. 이러한 기능이 필요하지 않으면 Azure Key Vault 비밀 공급자 확장을 사용하여 Arc 지원 Kubernetes 클러스터에서 비밀을 관리할 수 있습니다. 온라인 Azure Key Vault 비밀 공급자 확장과 오프라인 SSE를 클러스터에서 나란히 실행하는 것은 권장되지 않습니다.

이 문서에서는 SSE를 Azure Arc 지원 Kubernetes 확장으로 설치하고 구성하는 방법을 보여 줍니다.

Important

SSE는 현재 미리 보기로 제공됩니다. 베타, 미리 보기로 제공되거나 아직 일반 공급으로 릴리스되지 않은 Azure 기능에 적용되는 약관은 Microsoft Azure 미리 보기에 대한 추가 사용 약관을 참조하세요.

필수 조건

Arc 지원 클러스터입니다. 이는 사용자가 직접 연결한 것(이 가이드의 예제에서는 K3s 클러스터 사용) 또는 Azure Arc 클러스터에서 Microsoft에서 관리하는 AKS를 사용할 수 있습니다. 클러스터는 Kubernetes 버전 1.27 이상을 실행해야 하며 지원되는 지역 중 하나(미국 동부, 미국 동부2, 미국 서부, 미국 서부 2, 미국 서부3, 서유럽, 북유럽) 중 하나여야 합니다. 해당 지역은 Arc 클러스터를 만드는 데 사용된 리소스 그룹 지역에 의해 정의됩니다.
k8s-extension Azure CLI 확장의 최신 버전을 포함하여 클러스터 확장에 대한 일반 필수 구성 요소를 충족하는지 확인합니다.
cert-manager는 인트라블러스터 로그 통신을 위해 TLS를 지원해야 합니다. 이 가이드의 뒷부분에 있는 예제에서는 설치를 안내합니다. cert-manager에 대한 자세한 내용은 cert-manager.io 참조 하세요.

아직 다음을 수행 하지 않은 경우 Azure CLI 를 설치하고 로그인합니다.

az login

시작하기 전에 Azure 및 클러스터 리소스를 구성하는 데 사용할 환경 변수를 설정합니다. 여기에 나열된 관리 ID, Azure Key Vault 또는 다른 리소스가 이미 있는 경우 해당 리소스를 반영하도록 환경 변수의 이름을 업데이트합니다.

export RESOURCE_GROUP="AzureArcTest"
export CLUSTER_NAME="AzureArcTest1"
export LOCATION="EastUS"
export SUBSCRIPTION="$(az account show --query id --output tsv)"
az account set --subscription "${SUBSCRIPTION}"
export AZURE_TENANT_ID="$(az account show -s $SUBSCRIPTION --query tenantId --output tsv)"
export CURRENT_USER="$(az ad signed-in-user show --query userPrincipalName --output tsv)"
export KEYVAULT_NAME="my-kv"
export KEYVAULT_SECRET_NAME="my-secret"
export USER_ASSIGNED_IDENTITY_NAME="my-identity"
export FEDERATED_IDENTITY_CREDENTIAL_NAME="my-credential"
export KUBERNETES_NAMESPACE="my-namespace"
export SERVICE_ACCOUNT_NAME="my-service-account"

클러스터에서 워크로드 ID 페더레이션 활성화

SSE는 워크로드 ID 페더레이션이라는 기능을 사용하여 Azure Key Vault 비밀에 액세스하고 동기화합니다. 이 섹션에서는 이를 설정하는 방법을 설명합니다. 다음 섹션에서는 사용되는 방법을 자세히 설명합니다.

팁

다음 단계는 워크로드 ID 페더레이션을 사용하여 Arc 지원 Kubernetes를 구성하기 위한 방법 가이드를 기반으로 합니다. 추가 지원은 해당 설명서를 참조하세요.

클러스터가 Azure Arc 에 아직 연결되지 않은 경우 다음 단계를 수행합니다. 이 단계에서는 명령의 일부로 워크로드 ID 페더레이션을 connect 사용하도록 설정합니다.

az connectedk8s connect --name ${CLUSTER_NAME} --resource-group ${RESOURCE_GROUP} --enable-oidc-issuer --enable-workload-identity

클러스터가 이미 Azure Arc에 연결된 경우 다음 명령을 사용하여 워크로드 ID를 update 사용하도록 설정합니다.

az connectedk8s update --name ${CLUSTER_NAME} --resource-group ${RESOURCE_GROUP} --enable-oidc-issuer --enable-workload-identity

이제 Microsoft Entra ID가 이러한 토큰의 유효성을 검사하는 데 필요한 공개 키를 찾을 수 있도록 하는 새 발급자 URL(service-account-issuer)을 사용하여 서비스 계정 토큰을 발급하도록 클러스터를 구성합니다. 이러한 공개 키는 클러스터의 자체 서비스 계정 토큰 발급자를 위한 것이며 위에서 설정한 옵션의 --enable-oidc-issuer 결과로 이 URL에서 가져오고 클라우드 호스팅되었습니다.

필요에 따라 허용 컨트롤러를 구성 OwnerReferencesPermissionEnforcement 하여 컨트롤 플레인에서 실행되는 권한 있는 리소스로 SSE 자체 권한에 대한 제한을 구성할 수도 있습니다. 이 허용 컨트롤러는 SSE가 클러스터의 다른 개체를 변경할 수 있는 양을 제한합니다.

발급자 URL 필드와 권한 적용을 사용하여 kube-apiserver를 구성합니다. 다음 예에서는 k3s 클러스터에 대한 것입니다. 클러스터에는 API 서버 인수를 변경하는 데 사용할 수 있는 다양한 수단이 있을 수 있습니다. --kube-apiserver-arg="--service-account-issuer=${SERVICE_ACCOUNT_ISSUER}" and --kube-apiserver-arg="--enable-admission-plugins=OwnerReferencesPermissionEnforcement".
- 서비스 계정 발급자 URL을 가져옵니다.
```
export SERVICE_ACCOUNT_ISSUER="$(az connectedk8s show --name ${CLUSTER_NAME} --resource-group ${RESOURCE_GROUP} --query "oidcIssuerProfile.issuerUrl" --output tsv)"
echo $SERVICE_ACCOUNT_ISSUER
```
- K3s 서버 구성 파일을 엽니다.
```
sudo nano /etc/systemd/system/k3s.service
```
- 다음 예제와 같이 서버 구성을 편집합니다. SERVICE_ACCOUNT_ISSUER> 위의 출력echo $SERVICE_ACCOUNT_ISSUER으로 대체<하고 이 URL의 후행 슬래시를 포함하도록 기억합니다.
```
ExecStart=/usr/local/bin/k3s \
  server --write-kubeconfig-mode=644 \
     --kube-apiserver-arg="--service-account-issuer=<SERVICE_ACCOUNT_ISSUER>" \
     --kube-apiserver-arg="--enable-admission-plugins=OwnerReferencesPermissionEnforcement"
```

kube-apiserver를 다시 시작합니다.

sudo systemctl daemon-reload
sudo systemctl restart k3s

방법 가이드를 사용하여 및 플래그를 사용하여 Azure Local의 AKS에서 워크로드 ID 페더레이션을 --enable-oidc-issuer --enable-workload-identity 활성화합니다.

초기 활성화 후 다음 단계로 돌아갑니다. 해당 가이드의 나머지 부분을 완료할 필요가 없습니다.

클러스터의 서비스 계정 발급자 URL을 가져와서 활성화가 성공했는지 확인합니다. 다음 단계에서 이 URL을 사용합니다.

export SERVICE_ACCOUNT_ISSUER="$(az connectedk8s show --name ${CLUSTER_NAME} --resource-group ${RESOURCE_GROUP} --query "oidcIssuerProfile.issuerUrl" --output tsv)"
echo $SERVICE_ACCOUNT_ISSUER

방법 가이드를 사용하여 AKS Edge Essentials에서 워크로드 ID 페더레이션을 활성화합니다.

초기 활성화 후 다음 단계로 돌아갑니다. 해당 가이드의 나머지 부분을 완료할 필요가 없습니다.

클러스터의 서비스 계정 발급자 URL을 가져와서 활성화가 성공했는지 확인합니다. 다음 단계에서 이 URL을 사용합니다.

export SERVICE_ACCOUNT_ISSUER="$(az connectedk8s show --name ${CLUSTER_NAME} --resource-group ${RESOURCE_GROUP} --query "oidcIssuerProfile.issuerUrl" --output tsv)"
echo $SERVICE_ACCOUNT_ISSUER

비밀을 만들고 액세스하도록 ID 구성

지정된 Azure Key Vault 비밀에 액세스하고 동기화하려면 SSE는 해당 비밀에 액세스하기 위해 적절한 Azure 권한이 있는 Azure 관리 ID에 액세스해야 합니다. 관리 ID는 위에서 활성화한 워크로드 ID 기능을 사용하여 Kubernetes 서비스 계정에 연결되어야 합니다. SSE는 연결된 페더레이션된 Azure 관리 ID를 사용하여 Azure Key Vault에서 Kubernetes 비밀 저장소로 비밀을 가져옵니다. 다음 섹션에서는 이를 설정하는 방법을 설명합니다.

Azure Key Vault 만들기

Azure Key Vault 만들기 및 비밀을 추가합니다. 이미 Azure Key Vault와 비밀이 있는 경우 이 섹션을 건너뛸 수 있습니다.

Azure Key Vault를 만듭니다.

az keyvault create --resource-group "${RESOURCE_GROUP}" --location "${LOCATION}" --name "${KEYVAULT_NAME}" --enable-rbac-authorization

자격 증명 모음에 대한 '비밀 관리자' 권한을 부여하여 비밀을 만들 수 있습니다.

az role assignment create --role "Key Vault Secrets Officer" --assignee ${CURRENT_USER} --scope /subscriptions/${SUBSCRIPTION}/resourcegroups/${RESOURCE_GROUP}/providers/Microsoft.KeyVault/vaults/${KEYVAULT_NAME}

비밀을 만들고 업데이트하여 두 가지 버전을 만듭니다.

az keyvault secret set --vault-name "${KEYVAULT_NAME}" --name "${KEYVAULT_SECRET_NAME}" --value 'Hello!'
az keyvault secret set --vault-name "${KEYVAULT_NAME}" --name "${KEYVAULT_SECRET_NAME}" --value 'Hello2'

사용자 할당 관리 ID 만들기

다음으로, 사용자가 할당한 관리 ID를 만들고 Azure Key Vault에 액세스할 수 있는 권한을 부여합니다. Azure Key Vault에 대한 Key Vault 읽기 권한자 및 Key Vault 비밀 사용자 권한의 관리 ID가 이미 있는 경우 이 섹션을 건너뛸 수 있습니다. 자세한 내용은 사용자가 할당한 관리 ID 만들기 및 Key Vault를 사용하여 Azure RBAC 비밀, 키 및 인증서 권한 사용을 참조하세요.

사용자가 할당한 관리 ID 만들기:

az identity create --name "${USER_ASSIGNED_IDENTITY_NAME}" --resource-group "${RESOURCE_GROUP}" --location "${LOCATION}" --subscription "${SUBSCRIPTION}"

ID에 Key Vault 읽기 권한자 및 Key Vault 비밀 사용자 권한을 부여합니다. 이러한 명령이 성공하기 전에 ID 만들기 복제가 완료될 때까지 잠시 기다려야 할 수도 있습니다.

export USER_ASSIGNED_CLIENT_ID="$(az identity show --resource-group "${RESOURCE_GROUP}" --name "${USER_ASSIGNED_IDENTITY_NAME}" --query 'clientId' -otsv)"
az role assignment create --role "Key Vault Reader" --assignee "${USER_ASSIGNED_CLIENT_ID}" --scope /subscriptions/${SUBSCRIPTION}/resourcegroups/${RESOURCE_GROUP}/providers/Microsoft.KeyVault/vaults/${KEYVAULT_NAME}
az role assignment create --role "Key Vault Secrets User" --assignee "${USER_ASSIGNED_CLIENT_ID}" --scope /subscriptions/${SUBSCRIPTION}/resourcegroups/${RESOURCE_GROUP}/providers/Microsoft.KeyVault/vaults/${KEYVAULT_NAME}

페더레이션 ID 자격 증명 만들기

비밀에 액세스해야 하는 워크로드에 대한 Kubernetes 서비스 계정을 만듭니다. 그런 다음 관리 ID, OIDC 서비스 계정 발급자, Kubernetes 서비스 계정을 연결하는 페더레이션된 ID 자격 증명을 만듭니다.

관리 ID에 페더레이션될 Kubernetes 서비스 계정을 만듭니다. 연관된 사용자가 할당한 관리 ID에 대한 세부 정보로 주석을 추가합니다.

kubectl create ns ${KUBERNETES_NAMESPACE}

cat <<EOF | kubectl apply -f -
  apiVersion: v1
  kind: ServiceAccount
  metadata:
    name: ${SERVICE_ACCOUNT_NAME}
    namespace: ${KUBERNETES_NAMESPACE}
EOF

페더레이션 ID 자격 증명 만들기:

az identity federated-credential create --name ${FEDERATED_IDENTITY_CREDENTIAL_NAME} --identity-name ${USER_ASSIGNED_IDENTITY_NAME} --resource-group ${RESOURCE_GROUP} --issuer ${SERVICE_ACCOUNT_ISSUER} --subject system:serviceaccount:${KUBERNETES_NAMESPACE}:${SERVICE_ACCOUNT_NAME}

SSE 설치

SSE는 Azure Arc 확장으로 사용할 수 있습니다. Azure Arc 지원 Kubernetes 클러스터는 Azure Arc 지원 Kubernetes 확장으로 확장할 수 있습니다. 확장 기능은 연결된 클러스터에서 Azure 기능을 사용하도록 설정하고 확장 기능 설치 및 수명 주기 관리를 위한 Azure Resource Manager 기반 환경을 제공합니다.

cert-manager 및 trust-manager 는 클러스터 서비스 간의 로그 보안 통신에도 필요하며 Arc 확장 전에 설치해야 합니다.

cert-manager를 설치합니다.

helm repo add jetstack https://charts.jetstack.io/ --force-update
helm install cert-manager jetstack/cert-manager --namespace cert-manager --create-namespace --version v1.16.2 --set crds.enabled=true

trust-manager를 설치합니다.

helm upgrade trust-manager jetstack/trust-manager --install --namespace cert-manager --wait

다음 명령을 사용하여 Arc 지원 클러스터에 SSE를 설치합니다.
```
az k8s-extension create \
  --cluster-name ${CLUSTER_NAME} \
  --cluster-type connectedClusters \
  --extension-type microsoft.azure.secretstore \
  --resource-group ${RESOURCE_GROUP} \
  --release-train preview \
  --name ssarcextension \
  --scope cluster 
```
원하는 경우 --configuration-settings rotationPollIntervalInSeconds=<time_in_seconds>를 추가하여 기본 회전 폴 간격을 선택적으로 수정할 수 있습니다.

매개 변수 이름 설명 기본값

rotationPollIntervalInSeconds SSE가 관리하는 비밀을 확인하거나 업데이트하는 빈도를 지정합니다. 3600(1시간)

매개 변수 이름	설명	기본값
`rotationPollIntervalInSeconds`	SSE가 관리하는 비밀을 확인하거나 업데이트하는 빈도를 지정합니다.	`3600`(1시간)

SSE 구성

Kubernetes 사용자 지정 리소스 인스턴스를 정의하여 Azure Key Vault에 대한 정보와 클러스터에 동기화할 비밀로 설치된 확장을 구성합니다. 두 가지 형식의 사용자 지정 리소스를 만듭니다.

Key Vault에 대한 연결을 정의하는 SecretProviderClass 개체입니다.
동기화할 각 비밀에 대한 SecretSync 개체입니다.

`SecretProviderClass` 리소스를 만들기

SecretProviderClass 리소스는 Azure Key Vault에 대한 연결, 자격 증명 모음에 액세스하는 데 사용할 ID, 동기화할 비밀, 로컬로 보존할 각 비밀의 버전 수를 정의하는 데 사용됩니다.

동기화하려는 각 Azure Key Vault, Azure Key Vault에 액세스하는 데 사용되는 각 ID 및 각 대상 Kubernetes 네임스페이스에 대해 별도의 SecretProviderClass가 필요합니다.

다음 예에 따라 Key Vault 및 비밀에 적절한 값으로 하나 이상의 SecretProviderClass YAML 파일을 만듭니다.

cat <<EOF > spc.yaml
apiVersion: secrets-store.csi.x-k8s.io/v1
kind: SecretProviderClass
metadata:
  name: secret-provider-class-name                      # Name of the class; must be unique per Kubernetes namespace
  namespace: ${KUBERNETES_NAMESPACE}                    # Kubernetes namespace to make the secrets accessible in
spec:
  provider: azure
  parameters:
    clientID: "${USER_ASSIGNED_CLIENT_ID}"               # Managed Identity Client ID for accessing the Azure Key Vault with.
    keyvaultName: ${KEYVAULT_NAME}                       # The name of the Azure Key Vault to synchronize secrets from.
    objects: |
      array:
        - |
          objectName: ${KEYVAULT_SECRET_NAME}            # The name of the secret to sychronize.
          objectType: secret
          objectVersionHistory: 2                       # [optional] The number of versions to synchronize, starting from latest.
    tenantID: "${AZURE_TENANT_ID}"                       # The tenant ID of the Key Vault 
EOF

`SecretSync` 개체 만들기

각 동기화된 비밀에는 클러스터별 정보를 정의하기 위한 SecretSync 개체도 필요합니다. 여기에서 클러스터에 있는 비밀의 이름 및 클러스터에 저장된 각 비밀 버전의 이름과 같은 정보를 지정합니다.

이 템플릿에 따라 각 비밀에 대해 하나의 SecretSync 개체 YAML 파일을 만듭니다. Kubernetes 네임스페이스는 일치하는 SecretProviderClass의 네임스페이스와 일치해야 합니다.

cat <<EOF > ss.yaml
apiVersion: secret-sync.x-k8s.io/v1alpha1
kind: SecretSync
metadata:
  name: secret-sync-name                                  # Name of the object; must be unique per Kubernetes namespace
  namespace: ${KUBERNETES_NAMESPACE}                      # Kubernetes namespace
spec:
  serviceAccountName: ${SERVICE_ACCOUNT_NAME}             # The Kubernetes service account to be given permissions to access the secret.
  secretProviderClassName: secret-provider-class-name     # The name of the matching SecretProviderClass with the configuration to access the AKV storing this secret
  secretObject:
    type: Opaque
    data:
    - sourcePath: ${KEYVAULT_SECRET_NAME}/0                # Name of the secret in Azure Key Vault with an optional version number (defaults to latest)
      targetKey: ${KEYVAULT_SECRET_NAME}-data-key0         # Target name of the secret in the Kubernetes secret store (must be unique)
    - sourcePath: ${KEYVAULT_SECRET_NAME}/1                # [optional] Next version of the AKV secret. Note that versions of the secret must match the configured objectVersionHistory in the secrets provider class 
      targetKey: ${KEYVAULT_SECRET_NAME}-data-key1         # [optional] Next target name of the secret in the K8s secret store
EOF

구성 CR 적용

kubectl apply 명령을 사용하여 구성 CR(사용자 지정 리소스)을 적용합니다.

kubectl apply -f ./spc.yaml
kubectl apply -f ./ss.yaml

SSE는 자동으로 비밀을 찾고 클러스터에 동기화를 시작합니다.

구성 옵션 보기

이 두 가지 사용자 지정 리소스 종류에 대한 추가 구성 옵션을 보려면 kubectl describe 명령을 사용하여 클러스터의 CRD를 검사합니다.

# Get the name of any applied CRD(s)
kubectl get crds -o custom-columns=NAME:.metadata.name

# View the full configuration options and field parameters for a given CRD
kubectl describe crd secretproviderclass
kubectl describe crd secretsync

클러스터와 동기화되는 비밀 관찰

구성이 적용되면 SSE를 설치할 때 지정된 주기에 따라 비밀이 클러스터에 자동으로 동기화되기 시작합니다.

동기화된 비밀 보기

다음 명령을 실행하여 클러스터에 동기화된 비밀을 확인합니다.

# View a list of all secrets in the namespace
kubectl get secrets -n ${KUBERNETES_NAMESPACE}

# View details of all secrets in the namespace
kubectl get secrets -n ${KUBERNETES_NAMESPACE} -o yaml

마지막 동기화 상태 보기

지정된 비밀에 대한 가장 최근의 동기화 상태를 보려면 SecretSync 개체에 대해 kubectl describe 명령을 사용합니다. 출력에는 비밀 만들기 타임스탬프, 비밀 버전 및 각 동기화 이벤트에 대한 자세한 상태 메시지가 포함됩니다. 이 출력은 연결 또는 구성 오류를 진단하고 비밀 값이 변경되는 시점을 관찰하는 데 사용할 수 있습니다.

kubectl describe secretsync secret-sync-name -n ${KUBERNETES_NAMESPACE}

비밀 값 보기

Kubernetes 비밀 저장소에 저장된 동기화된 비밀 값을 보려면 다음 명령을 사용합니다.

kubectl get secret secret-sync-name -n ${KUBERNETES_NAMESPACE} -o jsonpath="{.data.${KEYVAULT_SECRET_NAME}-data-key0}" | base64 -d
kubectl get secret secret-sync-name -n ${KUBERNETES_NAMESPACE} -o jsonpath="{.data.${KEYVAULT_SECRET_NAME}-data-key1}" | base64 -d

문제 해결

SSE는 두 개의 컨테이너가 있는 Pod를 포함하는 Kubernetes 배포입니다. 즉, 클러스터에 비밀 저장을 관리하는 컨트롤러와 Azure Key Vault에 대한 액세스를 관리하고 비밀을 끌어와야 하는 공급자입니다. 동기화된 각 비밀에는 Azure Key Vault에서 클러스터 비밀 저장소로의 해당 비밀 동기화 상태를 포함하는 SecretSync 개체가 있습니다.

문제를 해결하려면 먼저 마지막 동기화 상태 보기에 설명된 대로 SecretSync 개체의 상태를 살펴봅니다. 다음 표에는 일반적인 상태 형식, 의미, 오류를 해결하기 위한 잠재적인 문제 해결 단계가 나열되어 있습니다.

SecretSync 상태 형식	세부 정보	추가 수정/조사 단계
`CreateSucceeded`	비밀이 성공적으로 만들어졌습니다.	해당 없음
`CreateFailedProviderError`	공급자(Azure Key Vault에 대한 연결)에 문제가 있어 비밀을 만들지 못했습니다. 이 실패는 인터넷 연결, ID 동기화 비밀에 대한 권한 부족, `SecretProviderClass`의 구성 오류 또는 기타 문제로 인해 발생할 수 있습니다.	다음 명령을 사용하여 공급자의 로그를 살펴보면서 더 자세히 조사해 보세요. `kubectl get pods -n azure-secret-store` `kubectl logs <secret-sync-controller-pod-name> -n azure-secret-store --container='provider-azure-installer'`
`CreateFailedInvalidLabel`	SSE가 비밀을 관리하는 데 사용하는 올바른 Kubernetes 레이블이 없는 비밀이 이미 있기 때문에 비밀 만들기에 실패했습니다.	기존 레이블 및 비밀을 제거하고 SSE가 비밀을 다시 만들 수 있도록 허용합니다. `kubectl delete secret <secret-name>` SSE가 구성된 회전 폴링 간격보다 더 빠르게 비밀을 다시 만들도록 하려면 개체(`kubectl delete secretsync <secret-name>`)를 삭제 `SecretSync` 하고 비밀 동기화 클래스(`kubectl apply -f <path_to_secret_sync>`)를 다시 적용합니다.
`CreateFailedInvalidAnnotation`	SSE가 비밀을 관리하는 데 사용하는 올바른 Kubernetes 주석이 없는 비밀이 이미 있으므로 비밀 만들기에 실패했습니다.	기존 주석 및 비밀을 제거하고 SSE가 비밀을 다시 만들 수 있도록 허용합니다. `kubectl delete secret <secret-name>` SSE가 구성된 회전 폴링 간격보다 더 빠르게 비밀을 다시 만들도록 하려면 개체(`kubectl delete secretsync <secret-name>`)를 삭제 `SecretSync` 하고 비밀 동기화 클래스(`kubectl apply -f <path_to_secret_sync>`)를 다시 적용합니다.
`UpdateNoValueChangeSucceeded`	SSE는 구성된 폴링 간격이 끝날 때 Azure Key Vault에서 업데이트를 확인했지만 동기화할 변경 내용은 없었습니다.	해당 없음
`UpdateValueChangeOrForceUpdateSucceeded`	SSE는 Azure Key Vault에서 업데이트를 확인하고 값을 성공적으로 업데이트했습니다.	해당 없음
`UpdateFailedInvalidLabel`	SSE가 비밀을 관리하는 데 사용하는 비밀의 레이블이 수정되었기 때문에 비밀 업데이트에 실패했습니다.	기존 레이블 및 비밀을 제거하고 SSE에서 비밀을 다시 만들 수 있도록 합니다. `kubectl delete secret <secret-name>` SSE가 구성된 회전 폴링 간격보다 더 빠르게 비밀을 다시 만들도록 하려면 개체(`kubectl delete secretsync <secret-name>`)를 삭제 `SecretSync` 하고 비밀 동기화 클래스(`kubectl apply -f <path_to_secret_sync>`)를 다시 적용합니다.
`UpdateFailedInvalidAnnotation`	SSE가 비밀을 관리하는 데 사용하는 비밀에 대한 주석이 수정되었기 때문에 비밀 업데이트에 실패했습니다.	기존 주석 및 비밀을 제거하고 SSE가 비밀을 다시 만들 수 있도록 허용합니다. `kubectl delete secret <secret-name>` SSE가 구성된 회전 폴링 간격보다 더 빠르게 비밀을 다시 만들도록 하려면 개체(`kubectl delete secretsync <secret-name>`)를 삭제 `SecretSync` 하고 비밀 동기화 클래스(`kubectl apply -f <path_to_secret_sync>`)를 다시 적용합니다.
`UpdateFailedProviderError`	공급자(Azure Key Vault에 대한 연결)에 문제가 있어 비밀 업데이트에 실패했습니다. 이 실패는 인터넷 연결, ID 동기화 비밀에 대한 권한 부족, `SecretProviderClass` 구성 또는 기타 문제로 인해 발생할 수 있습니다.	다음 명령을 사용하여 공급자의 로그를 살펴보면서 더 자세히 조사해 보세요. `kubectl get pods -n azure-secret-store` `kubectl logs <secret-sync-controller-pod-name> -n azure-secret-store --container='provider-azure-installer'`
`UserInputValidationFailed`	비밀 동기화 클래스가 잘못 구성되었기 때문에(잘못된 비밀 형식 등) 비밀 업데이트에 실패했습니다.	비밀 동기화 클래스 정의를 검토하고 오류를 수정합니다. 그런 다음 `SecretSync` 개체(`kubectl delete secretsync <secret-name>`)를 삭제하고 비밀 동기화 클래스(`kubectl delete -f <path_to_secret_sync>`)를 삭제한 다음 비밀 동기화 클래스(`kubectl apply -f <path_to_secret_sync>`)를 다시 적용합니다.
`ControllerSpcError`	SSE가 공급자 클래스를 얻지 못했거나 공급자 클래스가 잘못 구성되었으므로 비밀 업데이트에 실패했습니다.	공급자 클래스를 검토하고 오류를 수정합니다. 그런 다음 `SecretSync` 개체(`kubectl delete secretsync <secret-name>`)를 삭제하고 공급자 클래스(`kubectl delete -f <path_to_provider>`)를 삭제한 다음 공급자 클래스(`kubectl apply -f <path_to_provider>`)를 다시 적용합니다.
`ControllerInternalError`	SSE의 내부 오류로 인해 비밀 업데이트에 실패했습니다.	자세한 내용은 SSE 로그 또는 이벤트를 확인합니다. `kubectl get pods -n azure-secret-store` `kubectl logs <secret-sync-controller-pod-name> -n azure-secret-store --container='manager'`
`SecretPatchFailedUnknownError`	Kubernetes 비밀 값을 패치하는 동안 비밀 업데이트에 실패했습니다. 이 오류는 SSE가 아닌 다른 사용자가 비밀을 수정했거나 SSE를 업데이트하는 동안 문제가 발생한 경우에 발생할 수 있습니다.	비밀 및 `SecretSync` 개체를 삭제한 다음, 비밀 동기화 CR을 다시 적용하여 SSE에서 비밀을 다시 만들도록 합니다. `kubectl delete secret <secret-name>` `kubectl delete secretsync <secret-name>` `kubectl apply -f <path_to_secret_sync>`

SSE 제거

SSE를 제거하고 비밀 동기화를 중지하려면 다음 명령을 사용하여 az k8s-extension delete 제거합니다.

az k8s-extension delete --name ssarcextension --cluster-name $CLUSTER_NAME  --resource-group $RESOURCE_GROUP  --cluster-type connectedClusters

확장을 제거해도 클러스터에서 비밀, SecretSync 개체 또는 CRD는 제거되지 않습니다. 이러한 개체는 kubectl을 사용하여 직접 제거해야 합니다.

SecretSync CRD를 삭제하면 모든 SecretSync 개체가 제거되고 기본적으로 소유한 모든 비밀이 제거되지만 다음과 같은 경우 비밀이 지속될 수 있습니다.

비밀의 소유권을 수정했습니다.
클러스터에서 가비지 수집 설정을 변경했으며 여기에는 다른 종료자 설정도 포함됩니다.

위의 경우에는 kubectl을 사용하여 비밀을 직접 삭제해야 합니다.

다음 단계

Azure Arc 확장에 대해 자세히 알아봅니다.
Azure Key Vault에 대해 자세히 알아보세요.

다음을 통해 공유

Azure Arc 지원 Kubernetes 클러스터에서 오프라인 액세스를 위해 비밀 저장소 확장을 사용하여 비밀을 가져옵니다.

필수 조건

클러스터에서 워크로드 ID 페더레이션 활성화

비밀을 만들고 액세스하도록 ID 구성

Azure Key Vault 만들기

사용자 할당 관리 ID 만들기

페더레이션 ID 자격 증명 만들기

SSE 설치

SSE 구성

`SecretProviderClass` 리소스를 만들기

`SecretSync` 개체 만들기

구성 CR 적용

구성 옵션 보기

클러스터와 동기화되는 비밀 관찰

동기화된 비밀 보기

마지막 동기화 상태 보기

비밀 값 보기

문제 해결

SSE 제거

다음 단계

피드백

추가 리소스

다음을 통해 공유

Azure Arc 지원 Kubernetes 클러스터에서 오프라인 액세스를 위해 비밀 저장소 확장을 사용하여 비밀을 가져옵니다.

필수 조건

클러스터에서 워크로드 ID 페더레이션 활성화

비밀을 만들고 액세스하도록 ID 구성

Azure Key Vault 만들기

사용자 할당 관리 ID 만들기

페더레이션 ID 자격 증명 만들기

SSE 설치

SSE 구성

SecretProviderClass 리소스를 만들기

SecretSync 개체 만들기

구성 CR 적용

구성 옵션 보기

클러스터와 동기화되는 비밀 관찰

동기화된 비밀 보기

마지막 동기화 상태 보기

비밀 값 보기

문제 해결

SSE 제거

다음 단계

피드백

추가 리소스

`SecretProviderClass` 리소스를 만들기

`SecretSync` 개체 만들기