앰비언트 네트워킹 보안 및 승인 정책

이 페이지에서는 앰비언트 네트워킹에서 승인 정책을 만드는 방법을 보여줍니다.

기본 요건

이 문서의 단계를 완료하려면 다음 조건을 충족해야 합니다.

  • Cloud Service Mesh 앰비언트 네트워킹이 사용 설정된 실행 중인 GKE 클러스터
  • 샘플 클라이언트 및 서버 워크로드가 배포된 앰비언트 네트워킹에 등록된 네임스페이스(예: ambient-test)
  • GCPServerTLSPolicy (mtlsMode: Strict 포함) 및 GCPClientTLSPolicy를 사용하여 클라이언트와 서버 워크로드 간에 상호 TLS (mTLS) 사용 설정 CLIENT_CERT_URI_SAN와 일치하는 ID 기반 GCPAuthzPolicy 규칙에는 클라이언트의 SPIFFE ID를 추출하기 위해 활성 mTLS가 필요합니다.

자세한 환경 설정은 GKE 앰비언트 네트워킹 준비를 참고하세요.

기본적으로 거부 정책

기본적으로 GKE Ambient Authorization Policy API는 표준 Kubernetes NetworkPolicy 동작과 일치하는 정책에 의해 제한되지 않는 한 모든 트래픽을 허용합니다.

DENY_BY_DEFAULT 작업을 사용하면 이 기본 동작을 변경할 수 있습니다. 네임스페이스에 적용되면 이 정책은 ALLOW 정책에 의해 명시적으로 허용되지 않는 한 해당 네임스페이스의 워크로드로 향하는 모든 트래픽을 차단합니다.

이 페이지에서는 Cloud Service Mesh에서 DENY_BY_DEFAULT를 구성하고 사용하여 워크로드의 기본 보안 태세를 설정하는 방법을 보여줍니다.

제한사항

DENY_BY_DEFAULT 정책을 적용하기 전에 다음 제한사항에 유의하세요.

  • 네임스페이스당 하나의 DENY_BY_DEFAULT 정책만 만들 수 있습니다.
  • DENY_BY_DEFAULT 작업이 있는 정책에는 정의된 규칙이 있을 수 없습니다.
  • 이 작업을 사용하여 모든 포드를 타겟팅하는 네임스페이스 전체 기준 matchLabels: {}를 설정합니다. 포드별 제한에는 DENY_BY_DEFAULT를 사용할 수 없습니다.

기본적으로 거부되는 승인 정책 설정

네임스페이스 전반에서 기본적으로 거부 기준을 설정하고 특정 워크로드에 대한 액세스를 선택적으로 허용하려면 다음 단계를 따르세요.

  1. 작업이 DENY_BY_DEFAULT으로 설정된 GCPAuthzPolicy를 만들어 네임스페이스에 적용합니다.

    cat <<EOF > deny-by-default-policy.yaml && kubectl apply -f deny-by-default-policy.yaml
    apiVersion: networking.gke.io/v1
    kind: GCPAuthzPolicy
    metadata:
      name: deny-by-default-authz
      namespace: ambient-test
    spec:
      action: DENY_BY_DEFAULT
      enforcementLevel: L4
      targetRefs:
      - group: ""
        kind: Pod
        selector:
          matchLabels: {}
    EOF
    

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

     gcpauthzpolicy.networking.gke.io/deny-by-default-authz created
    

    이 정책은 기본적으로 ambient-test 네임스페이스의 워크로드에 대한 모든 인바운드 (East-West 및 인그레스) 트래픽을 차단합니다. 네임스페이스의 워크로드에서 시작되는 아웃바운드 트래픽은 제한하지 않습니다.

  2. 트래픽을 선택적으로 허용하려면 ALLOW 정책을 만들어 적용하세요.

    cat <<EOF > allow-policy.yaml && kubectl apply -f allow-policy.yaml
    apiVersion: networking.gke.io/v1
    kind: GCPAuthzPolicy
    metadata:
      name: allow-client-to-server
      namespace: ambient-test
    spec:
      action: ALLOW
      enforcementLevel: L4
      targetRefs:
      - group: ""
        kind: Pod
        selector:
          matchLabels:
            app: server
      rules:
      - from:
          sources:
          - principals:
          - principalSelector: CLIENT_CERT_URI_SAN
            principal:
              type: Exact
              value: spiffe://PROJECT_ID.s3ns.svc.id.goog/ns/ambient-test/sa/client
    EOF
    

    PROJECT_ID를 프로젝트 ID로 바꿉니다.

    정책 전파는 컨트롤러 수락 후 최대 3분이 걸릴 수 있습니다. 3분 정도 기다린 후 진행합니다.

  3. 클라이언트에서 서버로의 연결을 테스트합니다. ALLOW 정책과 일치하므로 성공해야 합니다.

    kubectl exec -it deploy/client -n ambient-test -- /bin/curl -fsLS server.ambient-test.svc.cluster.local
    
  4. 서버에서 자체 (또는 명시적 허용 정책이 없는 다른 워크로드)로의 연결을 테스트합니다. DENY_BY_DEFAULT 정책으로 인해 실패해야 합니다.

    kubectl exec -it deploy/server -n ambient-test -- /bin/curl -fsLS server.ambient-test.svc.cluster.local
    

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

    curl: (52) Empty reply from server.
    

로깅

승인 정책에 의해 요청이 거부되면 GKE Ambient Proxy 액세스 로그의 JSON 페이로드에 다음 필드가 포함됩니다.

  • jsonPayload.error_details: - rbac_access_denied_matched_policy[none]로 설정

Cloud de Confiance 콘솔의 로그 탐색기를 사용하여 거부된 연결의 액세스 로그 항목을 볼 수 있습니다. 트래픽이 인증되고 승인되었는지 확인을 참고하세요.

이그레스 보안 정책

앰비언트 네트워킹 워크로드에서 외부 엔드포인트 또는 인터넷으로 전송되는 아웃바운드 트래픽을 검사하고 제어하려면 Secure Web Proxy (SWP)를 통해 이그레스 트래픽을 라우팅하면 됩니다.

GCPBackend 및 GCPEgressRouting 리소스 구성에 관한 안내는 Secure Web Proxy를 통해 앰비언트 이그레스 트래픽 라우팅을 참고하세요.