Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

권한이 있는 Autopilot 워크로드 및 허용 목록 문제 해결

Autopilot

Google Kubernetes Engine(GKE) Autopilot 클러스터의 권한이 있는 워크로드는 문제가 방지되도록 올바르게 구성해야 합니다. 잘못된 구성으로 인해 허용 목록과의 동기화가 실패하거나 워크로드가 거부될 수 있습니다. 이러한 문제로 인해 필수 에이전트나 서비스가 필요한 권한으로 실행되지 않을 수 있습니다.

이 문서를 사용하여 Autopilot에 권한이 있는 워크로드 배포와 관련된 문제를 해결합니다. 허용 목록 동기화 오류를 해결하고 권한이 있는 워크로드가 거부되는 이유를 진단하는 방법을 알아봅니다.

이 정보는 Autopilot 클러스터에 승격된 권한으로 워크로드를 배포하는 플랫폼 관리자, 운영자, 보안팀에 중요합니다. Google Cloud 콘텐츠에서 참조하는 일반적인 역할과 예시 태스크에 대한 자세한 내용은 일반 GKE 사용자 역할 및 태스크를 참조하세요.

허용 목록 동기화 문제

AllowlistSynchronizer를 배포하면 GKE는 지정한 허용 목록 파일을 설치하고 동기화하려고 합니다. 이 동기화가 실패하면 AllowlistSynchronizer의 status 필드에 오류가 보고됩니다.

AllowlistSynchronizer 객체 상태를 가져옵니다.

kubectl get allowlistsynchronizer ALLOWLIST_SYNCHRONIZER_NAME -o yaml

ALLOWLIST_SYNCHRONIZER_NAME을 AllowlistSynchronizer의 이름으로 바꿉니다.

출력은 다음과 비슷합니다.

...
status:
  conditions:
  - type: Ready
    status: "False"
    reason: "SyncError"
    message: "some allowlists failed to sync: example-allowlist-1.yaml"
    lastTransitionTime: "2024-10-12T10:00:00Z"
    observedGeneration: 2
  managedAllowlistStatus:
    - filePath: "gs://path/to/allowlist1.yaml"
      generation: 1
      phase: Installed
      lastSuccessfulSync: "2024-10-10T10:00:00Z"
    - filePath: "gs://path/to/allowlist2.yaml"
      phase: Failed
      lastError: "Initial install failed: invalid contents"
      lastSuccessfulSync: "2024-10-08T10:00:00Z"

conditions.message 필드와 managedAllowlistStatus.lastError 필드는 오류에 대한 자세한 정보를 제공합니다. 이 정보를 사용하여 문제를 해결합니다.

여러 AllowlistSynchronizer

1.33.4-gke.1035000 이전 버전의 GKE 클러스터에서는 AllowlistSynchronizer기 두 개 이상 있으면 WorkloadAllowlists가 설치되지 않을 수 있습니다.

이 문제를 해결하려면 allowlistPaths 여러 개가 포함된 단일 AllowlistSynchronizer만 사용합니다.

또는 클러스터를 최신 버전으로 업그레이드하면 됩니다.

워크로드 컨테이너 정렬

1.34.0-gke.0000000 이전 버전의 GKE 클러스터에서 워크로드 컨테이너 이미지 하나 이상이 클러스터 내 WorkloadAllowlist에 지정한 컨테이너 이미지와 일치하면 워크로드 컨테이너가 생성되어 알파벳의 역순으로 정렬될 수 있습니다.

이 문제를 해결하려면 다음 옵션을 시도해 보세요.

클러스터를 버전 1.34.0-gke.0000000 이상으로 업그레이드합니다.
워크로드 컨테이너가 올바른 순서로 정렬되도록 워크로드 컨테이너 이름을 바꿉니다.

권한이 있는 워크로드 배포 문제

허용 목록을 성공적으로 설치한 후 클러스터에 해당 권한이 있는 워크로드를 배포합니다. 경우에 따라 GKE에서 워크로드를 거부할 수 있습니다.

다음 해결 방법을 시도해 보세요.

클러스터의 GKE 버전이 워크로드의 버전 요구사항을 충족하는지 확인합니다.
배포하는 워크로드가 허용 목록 파일이 적용되는 워크로드인지 확인합니다.

권한이 있는 워크로드가 거부된 이유를 확인하려면 허용 목록 위반에 대한 자세한 정보를 GKE에 요청합니다.

클러스터에 설치된 허용 목록의 목록을 가져옵니다.
```
kubectl get workloadallowlist
```
권한이 있는 워크로드에 적용해야 하는 허용 목록의 이름을 찾습니다.
텍스트 편집기에서 권한이 있는 워크로드의 YAML 매니페스트를 엽니다. 워크로드 배포 프로세스에서 다른 도구를 사용하는 등 YAML 매니페스트에 액세스할 수 없으면 워크로드 제공업체에 연락하여 문제를 신고합니다. 나머지 단계는 건너뛰세요.
권한이 있는 워크로드 포드 사양의 spec.metadata.labels 섹션에 다음 라벨을 추가합니다.
```
labels:
  cloud.google.com/matching-allowlist: ALLOWLIST_NAME
```
ALLOWLIST_NAME을 이전 단계에서 가져온 허용 목록의 이름으로 바꿉니다. 허용 목록 파일의 경로가 아닌 kubectl get workloadallowlist 명령어 출력의 이름을 사용합니다.
매니페스트를 저장하고 클러스터에 워크로드를 적용합니다.
```
kubectl apply -f WORKLOAD_MANIFEST_FILE
```
WORKLOAD_MANIFEST_FILE을 매니페스트 파일의 경로로 바꿉니다.

출력에는 다음 예시와 같이 워크로드의 어떤 필드가 지정된 허용 목록과 일치하지 않는지에 대한 자세한 정보가 제공됩니다.
```
Error from server (GKE Warden constraints violations): error when creating "STDIN": admission webhook "warden-validating.common-webhooks.networking.gke.io" denied the request:

===========================================================================
Workload Mismatches Found for Allowlist (example-allowlist-1):
===========================================================================
HostNetwork Mismatch: Workload=true, Allowlist=false
HostPID Mismatch: Workload=true, Allowlist=false
Volume[0]: data
         - data not found in allowlist. Verify volume with matching name exists in allowlist.
Container[0]:
- Envs Mismatch:
        - env[0]: 'ENV_VAR1' has no matching string or regex pattern in allowlist.
        - env[1]: 'ENV_VAR2' has no matching string or regex pattern in allowlist.
- Image Mismatch: Workload=k8s.gcr.io/diff/image, Allowlist=k8s.gcr.io/pause2. Verify that image string or regex match.
- SecurityContext:
        - Capabilities.Add Mismatch: the following added capabilities are not permitted by the allowlist: [SYS_ADMIN SYS_PTRACE]
- VolumeMount[0]: data
        - data not found in allowlist. Verify volumeMount with matching name exists in allowlist.
```
이 예시에서는 다음과 같은 위반이 발생합니다.
- 워크로드에서 hostNetwork: true를 지정하지만 허용 목록에서는 hostNetwork: true를 지정하지 않습니다.
- 워크로드에서 hostPID: true를 지정하지만 허용 목록에서는 hostPID: true를 지정하지 않습니다.
- 워크로드에서 data 볼륨을 지정하지만 허용 목록에서는 data 볼륨을 지정하지 않습니다.
- 컨테이너에서 ENV_VAR1 및 ENV_VAR2 환경 변수를 지정하지만 허용 목록에서는 이러한 환경 변수를 지정하지 않습니다.
- 컨테이너에서 이미지 k8s.gcr.io/diff/image를 지정하지만 허용 목록에서는 k8s.gcr.io/pause2를 지정합니다.
- 컨테이너에서 SYS_ADMIN 및 SYS_PTRACE 기능을 추가하지만 허용 목록에서는 이러한 기능 추가를 허용하지 않습니다.
- 컨테이너에서 data 볼륨 마운트를 지정하지만 허용 목록에서는 data 볼륨 마운트를 지정하지 않습니다.

서드 파티 제공업체 소유의 워크로드를 배포하는 경우 해당 제공업체에 문제를 신고하여 위반사항을 해결합니다. 문제에 이전 단계의 출력을 제공합니다.

호환되지 않는 GKE 버전

허용 목록에 클러스터 GKE 버전보다 최신인 최소 GKE 버전이 지정된 경우 GKE에서 워크로드를 거부할 수 있습니다.

허용 목록에 최소 GKE 버전이 지정되어 있는지 확인합니다.
```
kubectl describe workloadallowlist ALLOWLIST_NAME | grep "minGKEVersion"
```
ALLOWLIST_NAME을 허용 목록 이름으로 바꿉니다.

출력이 비어 있으면 허용 목록에 최소 GKE 버전이 지정되지 않은 것입니다. 이 섹션을 건너뛰세요. 출력이 값인 경우 허용 목록은 최소 GKE 버전을 지정합니다.
클러스터 GKE 버전을 확인합니다.
```
gcloud container clusters describe CLUSTER_NAME \
    --location=CLUSTER_LOCATION \
    --format="value(currentMasterVersion)"
```
다음을 바꿉니다.
- CLUSTER_NAME: 클러스터의 이름입니다.
- CLUSTER_LOCATION: 클러스터의 Google Cloud 위치입니다.
출력은 다음과 비슷합니다.
```
1.32.3-gke.1006000
```
클러스터의 GKE 버전이 허용 목록의 최소 GKE 버전보다 이전이면 클러스터를 허용 목록의 최소 GKE 버전 이상으로 업그레이드합니다. 자세한 내용은 클러스터 업그레이드를 참고하세요.

업그레이드가 완료되면 클러스터에 워크로드를 배포해 보세요.

문자열 불일치

WorkloadAllowlist 사양의 특정 필드는 워크로드 사양의 해당 필드와 정확히 일치하는 문자열이어야 합니다.

WorkloadAllowlist CustomResourceDefinition (CRD) 참조 페이지를 엽니다.
WorkloadAllowlist 사양의 각 필드에 대해 CRD에 정확한 문자열 일치가 필요한지 확인합니다.
정확한 문자열 일치가 필요한 각 필드의 경우 WorkloadAllowlist 사양의 값이 워크로드 사양의 해당 값과 일치하는지 확인합니다.

예를 들어 컨테이너가 실행하는 모든 명령어는 허용 목록의 명령어와 정확히 일치해야 합니다. 정확한 명령어에서 벗어나면 거부됩니다.

불일치가 있으면 워크로드 사양과 일치하도록 WorkloadAllowlist 사양을 업데이트합니다.

정규 표현식 불일치

WorkloadAllowlist 사양의 특정 필드는 정규식 일치를 지원합니다.

WorkloadAllowlist 사양에서 정규식을 지정하는 필드를 찾습니다.
정규 표현식 구문이 올바른지 확인합니다. WorkloadAllowlist CRD는 Google RE2 정규 표현식 구문을 지원합니다. 표현식에 다음 속성이 있는지 확인합니다.
- 정규 표현식은 ^ 문자로 시작하고 $ 문자로 끝납니다. 예를 들면 ^example-auth\.google\.com\/go_[a-z0-9]+\/google\/path$입니다.
- 모든 특수 문자는 \ 이스케이프 문자로 이스케이프 처리됩니다. 추가되거나 누락된 \ 문자가 있는지 확인합니다.
- 허용 목록의 이미지 경로에는 태그나 다이제스트가 포함되지 않습니다. 예를 들어 k8s.gcr.io/pause:3.1 또는 k8s.gcr.io/pause@sha256:1234567890 대신 k8s.gcr.io/pause를 사용합니다.

정규 표현식 문제를 해결한 후 워크로드를 클러스터에 배포해 보세요.

명령어 및 인수에서 문자 이스케이프 처리

특수문자를 이스케이프하지 않으면 GKE에서 명령어와 인수를 일치시킬 수 없습니다. 문자 이스케이프 요구사항은 허용 목록을 적용하는 방법에 따라 다릅니다. 예를 들어 허용 목록을 YAML 또는 JSON 파일로 적용하는 것은 명령줄 도구를 사용하여 허용 목록 사양을 만드는 것과 이스케이프 요구사항이 다릅니다. 이 섹션에서는 YAML 파일의 이스케이프 요구사항을 설명합니다.

정규 표현식을 사용하지 않더라도 워크로드 허용 목록 사양의 commands 및 args 필드에 있는 모든 특수문자를 이스케이프 처리합니다. 특수 문자를 이스케이프 처리하려면 다음 예와 같이 \ 문자를 사용합니다.

명령어: kubectl describe \$\{POD_NAME\}
인수: hostname \$NODE_NAME; dcgm-exporter --remote-hostengine-info \$$NODE_IP$ --collectors /etc/dcgm-exporter/counters.csv

허용 목록에 있는 워크로드에 대한 웹훅 간섭

경우에 따라 워크로드가 허용 목록과 일치하도록 올바르게 구성되어 있어도 GKE에서 거부될 수 있습니다. 이 상황은 클러스터의 다른 승인 컨트롤러 (웹훅)가 허용 목록에 의해 허용된 후 워크로드 컨트롤러에 의해 생성된 포드를 수정하는 경우 발생할 수 있습니다. 이러한 수정으로 인해 포드 사양이 더 이상 허용 목록과 일치하지 않아 GKE Warden 허용 웹훅에서 거부될 수 있습니다.

이 문제는 사이드카 컨테이너나 환경 변수를 포드에 삽입하는 서드 파티 모니터링 및 보안 에이전트에서 흔히 발생합니다.

가장 일반적인 증상은 워크로드 컨트롤러 (예: DaemonSet 또는 Deployment)가 생성되었지만 포드를 만들지 못하는 것입니다. 컨트롤러의 이벤트를 검사하면 허용 웹훅에 의해 포드가 거부되었음을 나타내는 메시지가 표시됩니다.

권한이 있는 워크로드 배포 문제 섹션의 단계에 따라 워크로드에 cloud.google.com/matching-allowlist 라벨을 추가합니다.
워크로드의 YAML 매니페스트에서 spec.template을 복사합니다.
새 Pod 매니페스트를 만들고 복사한 사양을 spec 필드에 붙여넣습니다.
포드 매니페스트에서 apiVersion, kind, metadata.name 필드를 설정합니다.
```
apiVersion: v1
kind: Pod
metadata:
  name: POD_NAME
  labels:
    cloud.google.com/matching-allowlist: ALLOWLIST_NAME
spec:
  # Paste the content of spec.template here
```
다음을 바꿉니다.
- POD_NAME: 테스트 포드의 이름입니다.
- ALLOWLIST_NAME: 허용 목록의 이름입니다.
포드 매니페스트를 적용합니다.
```
kubectl apply -f YOUR_POD_MANIFEST_FILE
```
YOUR_POD_MANIFEST_FILE을 포드 매니페스트 파일의 경로로 바꿉니다.
이전 단계의 출력을 검사합니다. '워크로드 불일치' 섹션에 예기치 않은 필드(예: 추가 환경 변수(DD_AGENT_HOST), 컨테이너 또는 볼륨)가 표시되면 다른 웹훅이 포드를 수정하고 있다는 강력한 신호입니다.

이 문제를 해결하려면 허용 목록에 추가된 워크로드의 포드를 수정하지 않도록 충돌하는 웹훅을 구성해야 합니다. 이는 일반적으로 워크로드 또는 해당 네임스페이스에 라벨이나 주석을 추가하여 변형에서 제외해야 함을 웹훅에 알리는 방식으로 이루어집니다. 예를 들어 Datadog를 사용하는 경우 워크로드의 네임스페이스에 admission.datadoghq.com/enabled: "false" 라벨을 추가합니다.

사용 중인 특정 서드 파티 소프트웨어의 문서를 참고하여 승인 컨트롤러에서 워크로드를 제외하는 방법을 알아보세요.

다른 웹훅이 포드를 수정하지 못하도록 하면 포드가 허용 목록과 계속 일치하고 Autopilot 클러스터에 성공적으로 배포되도록 할 수 있습니다.

권한이 있는 워크로드 및 허용 목록의 버그 및 기능 요청

GKE 파트너 또는 서드 파티 제공업체에서 제공하는 권한이 있는 워크로드를 실행하는 경우 해당 제공업체는 권한이 있는 워크로드와 허용 목록을 만들고 개발하고 유지보수해야 합니다. 파트너 또는 서드 파티 권한이 있는 워크로드 또는 허용 목록에 버그가 발생하거나 기능 요청이 있는 경우 제공업체에 문의하세요.

다음 단계

문서에서 문제 해결 방법을 찾을 수 없으면 지원 받기를 참조하여 다음 주제에 대한 조언을 포함한 추가 도움을 요청하세요.
- Cloud Customer Care에 문의하여 지원 케이스를 엽니다.
- StackOverflow에서 질문하고 google-kubernetes-engine 태그를 사용하여 유사한 문제를 검색해 커뮤니티의 지원을 받습니다. #kubernetes-engine Slack 채널에 가입하여 더 많은 커뮤니티 지원을 받을 수도 있습니다.
- 공개 Issue Tracker를 사용하여 문제나 기능 요청을 엽니다.

권한이 있는 Autopilot 워크로드 및 허용 목록 문제 해결 컬렉션을 사용해 정리하기 내 환경설정을 기준으로 콘텐츠를 저장하고 분류하세요.