서비스의 감사 정책 구성

감사 정책을 사용하면 Cloud Service Mesh에서 서비스에 대한 데이터 액세스를 감사할 수 있습니다. 서비스를 감사하면 '누가, 무엇을, 언제, 왜 했는지'라는 질문에 답하는 데 도움이 됩니다. 감사 정책을 사용하면 감사 로그가 생성되는 시점과 로그의 콘텐츠를 지정할 수 있습니다. 이 가이드에서는 감사 정책을 사용할 수 있도록 Cloud Service Mesh를 설치하는 방법을 설명합니다.

감사 로그는 Google Cloud 콘솔의 Cloud Logging 로그 탐색기에서 확인하므로 감사 정책은 다음 플랫폼에서만 지원됩니다.

  • Google Cloud 기반 GKE
  • Google Distributed Cloud
  • Google Distributed Cloud

감사 정책은 AUDIT 작업을 추가하여 AuthorizationPolicy를 확장합니다. 대상 정책 범위(워크로드, 네임스페이스 또는 전체 메시일 수 있음)에만 영향을 미칩니다. 정책은 ORed로 결합됩니다. 즉, 정책이 다음과 같이 표시되면 요청이 로깅됩니다. 지정된 워크로드에 감사 정책이 없으면 해당 워크로드에 대한 감사 로그가 생성되지 않습니다.

다음은 myapi/user/profile/* 경로에 대한 모든 WRITE 액세스를 감사하는 감사 정책의 예시입니다.

  apiVersion: security.istio.io/v1beta1
  kind: AuthorizationPolicy
  metadata:
    namespace: ns1
    name: anyname
  spec:
    selector:
      matchLabels:
        app: myapi
    action: AUDIT
    rules:
    - to:
      - operation:
          methods: ["POST", "UPDATE", "DELETE"]
          paths: ["/user/profile/*"]

제한사항

  • 인그레스 게이트웨이에는 감사 로그가 없습니다.
  • 감사 콘텐츠는 구성할 수 없습니다.
  • 현재 Cloud Service Mesh 감사 로그에는 일반 액세스 로그와 동일한 신뢰성 속성이 있습니다. 예를 들어 워크로드 Pod가 다시 시작되면 워크로드에 대한 일부 감사 로그가 유지되지 않는다면 손실될 수 있습니다.

시작하기 전에

종속 도구 설치 및 클러스터 검증의 단계를 따라 다음을 수행합니다.

게이트웨이 구성 준비

Cloud Service Mesh는 서비스 메시의 일부로 게이트웨이를 배포 및 관리하는 옵션을 제공합니다. 게이트웨이는 들어오거나 나가는 HTTP/TCP 연결을 수신하는 메시지의 에지에서 작동하는 부하 분산기를 설명합니다. 게이트웨이는 메시로 들어오고 나가는 트래픽을 미세하게 제어할 수 있는 Envoy 프록시입니다.

asmcliistio-ingressgateway를 설치하지 않습니다. 컨트롤 플레인과 게이트웨이를 개별적으로 배포하고 관리하는 것이 좋습니다. 자세한 내용은 게이트웨이 설치 및 업그레이드를 참조하세요.

Anthos Service Mesh 설치 맞춤설정

감사 정책을 사용하려면 Cloud Service Mesh 설치를 맞춤설정합니다.

설치

  1. Cloud Service Mesh 설치 단계를 수행합니다. asmcli install을 실행할 때 다음 옵션을 포함합니다.

    --option audit-authorizationpolicy
    

    예를 들면 다음과 같습니다.

    ./asmcli install \
      --project_id PROJECT_ID \
      --cluster_name CLUSTER_NAME \
      --cluster_location CLUSTER_LOCATION \
      --ca mesh_ca \
      --output_dir DIR_PATH  \
      --enable_all \
      --option audit-authorizationpolicy
    

    Cloud Service Mesh를 구성하는 데 필요한 다른 오버레이 파일을 지정해야 합니다.

  2. 워크로드에서 자동 사이드카 프록시 삽입을 사용 설정하려면 Cloud Service Mesh 설치를 완료합니다. 워크로드 배포 및 재배포를 참조하세요.

업그레이드

  1. Cloud Service Mesh 업그레이드 단계를 수행합니다. asmcli install을 실행할 때 다음 옵션을 포함합니다.

    --option audit-authorizationpolicy
    

    예를 들면 다음과 같습니다.

    ./asmcli install \
      --project_id PROJECT_ID \
      --cluster_name CLUSTER_NAME \
      --cluster_location CLUSTER_LOCATION \
      --ca mesh_ca \
      --output_dir DIR_PATH  \
      --enable_all \
      --option audit-authorizationpolicy
    

    Cloud Service Mesh를 구성하는 데 필요한 다른 오버레이 파일을 지정해야 합니다.

  2. 워크로드에서 자동 사이드카 프록시 삽입을 사용 설정하려면 Cloud Service Mesh 설치를 완료합니다. 자세한 내용은 새 제어 영역으로 전환을 참조하세요.

감사 로깅 사용

이 섹션에서는 Bookinfo 샘플을 사용하여 감사 로깅을 사용하는 방법을 보여줍니다.

  1. Bookinfo 샘플 애플리케이션을 기본 네임스페이스에 배포합니다.

  2. 인그레스 게이트웨이의 외부 IP 주소를 가져오고 샘플 애플리케이션에 요청을 전송하여 일부 트래픽을 생성합니다.

  3. Google Cloud console에서 탐색 메뉴 로 이동하고 Logging > 로그 탐색기를 선택합니다.

    로그 탐색기로 이동

  4. Google Cloud 프로젝트를 선택합니다.

  5. 아직 감사 정책을 배포하지 않았으므로 감사 로그가 없습니다. 감사 로그는 액세스 로그와 다릅니다. stackdriver 액세스 로그를 보려면 쿼리 빌더 필드에 다음 쿼리를 입력하고 쿼리 실행을 클릭합니다.

    logName="projects/PROJECT_ID/logs/server-accesslog-stackdriver"
    

    로그 탐색기 사용에 대한 자세한 내용은 로그 탐색기 개요를 참조하세요.

감사 정책 구성 및 감사 로그 확인

이 섹션에서는 Bookinfo 애플리케이션을 감사하기 위한 몇 가지 옵션을 제공합니다. 감사 정책을 배포한 후에는 일부 요청을 전송한 후 로그 탐색기에서 감사 로그를 확인할 수 있습니다.

  1. 다음 명령어를 입력하여 사용자 인증 정보를 가져와 클러스터와 상호작용합니다. 또한 이 명령어는 kubectl의 현재 컨텍스트를 클러스터로 설정합니다.

    gcloud container clusters get-credentials CLUSTER_NAME \
        --project=PROJECT_ID \
        --zone=CLUSTER_LOCATION
    
  2. 다음 감사 정책을 적용하여 /productpage 경로에 대한 GET 요청을 감사합니다.

    kubectl apply -f - << EOF
    apiVersion: "security.istio.io/v1beta1"
    kind: "AuthorizationPolicy"
    metadata:
      name: "audit-productpage"
      namespace: default
    spec:
      action: AUDIT
      rules:
      - to:
        - operation:
            methods: ["GET"]
            paths: ["/productpage"]
    EOF
    
  3. Bookinfo에 일부 요청을 보냅니다.

  4. 로그 탐색기에서 쿼리 빌더 필드에 다음 쿼리를 입력하고 쿼리 실행을 클릭합니다.

    logName="projects/PROJECT_ID/logs/server-istio-audit-log"
    

    이 쿼리는 다음과 유사한 로그를 반환합니다.

    이미지

  5. 다음 정책을 적용하여 bookinfo-ratings 서비스에 대한 요청을 감사합니다. 감사 정책은 추가됩니다. 다음 정책을 적용하면 ProductPage 및 Ratings 요청에 대한 감사 로그가 표시됩니다.

    kubectl apply -f - << EOF
    apiVersion: "security.istio.io/v1beta1"
    kind: "AuthorizationPolicy"
    metadata:
      name: "audit-ratings"
      namespace: default
    spec:
      action: AUDIT
      rules:
      - from:
        - source:
            principals: ["cluster.local/ns/default/sa/bookinfo-ratings"]
        to:
        - operation:
            methods: ["GET"]
    EOF
    

    새 감사 정책이 적용되기 전에 먼저 전파되어야 합니다.

  6. Bookinfo에 10개 이상의 요청을 전송하여 평가 서비스에 도달한 후 로그 탐색기에서 감사 로그를 확인합니다. 감사 로그는 다음과 유사합니다.

    이미지

  7. 다음 정책을 적용하여 기본 네임스페이스의 모든 서비스를 감사합니다.

    kubectl apply -f - << EOF
    apiVersion: security.istio.io/v1beta1
    kind: AuthorizationPolicy
    metadata:
      namespace: default
      name: "audit-all"
    spec:
      action: AUDIT
      rules:
        - {}
    EOF
    
  8. Bookinfo에 몇 가지 요청을 더 전송한 후 로그 탐색기에서 감사 로그를 확인합니다. 이제 감사 로그에 모든 요청이 기록됩니다.

    이미지

  9. 감사 정책을 ProductPage 및 Rating으로 축소하여 제한하려면 audit-all 정책을 삭제하면 됩니다.

    kubectl delete authorizationpolicy audit-all -n default
    

문제해결

감사 정책을 사용 설정한 후 감사 로그가 표시되지 않으면 다음 몇 가지 사항을 확인합니다.

  1. 로그 탐색기에서 지정된 기간 동안 트래픽이 있는지 확인합니다. Bookinfo에서 테스트하는 경우 다음 명령어를 여러 번 실행하여 요청을 보낼 수 있습니다.

    curl -s http://EXTERNAL_IP/productpage | grep Bookstore
    
  2. 감사 대상 서비스에 대한 요청을 차단하는 인그레스 게이트웨이에 AuthorizationPolicy가 있는지 확인합니다.

  3. 로그 탐색기에서 다음 필터를 사용하여 stackdriver 액세스 로그를 확인하여 요청이 애플리케이션에 도달하였는지 확인합니다.

    logName="projects/PROJECT_ID/logs/server-accesslog-stackdriver"
    

    이미지

  4. Stackdriver가 구성되어 있고 감사 로그가 사용 설정되어 있는지 확인하려면 현재 istiod 상태의 구성을 덤프합니다. config_dump에서 enable_audit_log 및 감사 정책의 이름을 검색합니다.

    istioctl dashboard envoy POD_NAME.NAMESPACE
    

    이미지 이미지 이미지

  5. 요청이 감사 정책 규칙과 일치하는지 확인하려면 역할 기반 액세스 제어 (RBAC) 디버그 로그를 확인하세요. 다음 명령어를 사용하여 RBAC 디버그 로깅을 사용 설정합니다.

    kubectl exec POD_NAME -n NAMESPACE -c istio-proxy -- pilot-agent request POST 'logging?rbac=debug'
    
  6. 요청을 보내고 kubectl logs 명령어를 사용하여 Pod의 로그를 확인합니다.

    kubectl logs POD_NAME -n NAMESPACE -c istio-proxy
    

다음 단계