서비스의 감사 정책 구성
<0x0 Google Cloud 자세한 내용은 Cloud Service Mesh 개요를 참고하세요.이 튜토리얼에서는 클러스터 내 컨트롤 플레인 구현만 지원합니다.
감사 정책을 사용하면 Cloud Service Mesh에서 서비스에 대한 데이터 액세스를 감사할 수 있습니다. 서비스를 감사하면 '누가, 무엇을, 언제, 왜 했는지'라는 질문에 답하는 데 도움이 됩니다. 감사 정책을 사용하면 감사 로그가 생성되는 시점과 로그의 콘텐츠를 지정할 수 있습니다. 이 가이드에서는 감사 정책을 사용할 수 있도록 Cloud Service Mesh를 설치하는 방법을 설명합니다.
감사 로그는 Google Cloud 콘솔의 Cloud Logging 로그 탐색기에서 확인하므로 감사 정책은 다음 플랫폼에서만 지원됩니다.
- Google Cloud용 GKE
- VMware용 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 감사 로그에는 일반 액세스 로그와 동일한 신뢰성 속성이 있습니다. 예를 들어 워크로드 포드가 다시 시작되면 워크로드에 대한 일부 감사 로그가 유지되지 않는 경우 손실될 수 있습니다.
시작하기 전에
종속 도구 설치 및 클러스터 검증의 단계를 따라 다음을 수행합니다.게이트웨이 구성 준비
Cloud Service Mesh는 서비스 메시의 일부로 게이트웨이를 배포 및 관리하는 옵션을 제공합니다. 게이트웨이는 들어오거나 나가는 HTTP/TCP 연결을 수신하는 메시지의 에지에서 작동하는 부하 분산기를 설명합니다. 게이트웨이는 메시로 들어오고 나가는 트래픽을 미세하게 제어할 수 있는 Envoy 프록시입니다.
asmcli는 istio-ingressgateway를 설치하지 않습니다. 컨트롤 플레인과 게이트웨이를 개별적으로 배포하고 관리하는 것이 좋습니다. 자세한 내용은 게이트웨이 설치 및 업그레이드를 참조하세요.
Cloud Service Mesh 설치 맞춤설정
감사 정책을 사용하려면 Cloud Service Mesh 설치를 맞춤설정합니다.
설치
- 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를 구성하는 데 필요한 다른 오버레이 파일을 지정해야 합니다. 
- 워크로드에서 자동 사이드카 프록시 삽입을 사용 설정하려면 Cloud Service Mesh 설치를 완료합니다. 워크로드 배포 및 재배포를 참조하세요. 
업그레이드
- 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를 구성하는 데 필요한 다른 오버레이 파일을 지정해야 합니다. 
- 워크로드에서 자동 사이드카 프록시 삽입을 사용 설정하려면 Cloud Service Mesh 설치를 완료합니다. 자세한 내용은 새 제어 영역으로 전환을 참조하세요. 
감사 로깅 사용
이 섹션에서는 Bookinfo 샘플을 사용하여 감사 로깅을 사용하는 방법을 보여줍니다.
- Bookinfo 샘플 애플리케이션을 기본 네임스페이스에 배포합니다. 
- 인그레스 게이트웨이의 외부 IP 주소를 가져오고 샘플 애플리케이션에 요청을 전송하여 일부 트래픽을 생성합니다. 
- Google Cloud 콘솔에서 탐색 메뉴 로 이동하여 로깅 > 로그 탐색기를 선택합니다. 
- Google Cloud 프로젝트를 선택합니다. 
- 아직 감사 정책을 배포하지 않았으므로 감사 로그가 없습니다. 감사 로그는 액세스 로그와 다릅니다. - stackdriver액세스 로그를 보려면 쿼리 빌더 필드에 다음 쿼리를 입력하고 쿼리 실행을 클릭합니다.- logName="projects/PROJECT_ID/logs/server-accesslog-stackdriver"- 로그 탐색기 사용에 대한 자세한 내용은 로그 탐색기 개요를 참조하세요. 
감사 정책 구성 및 감사 로그 확인
이 섹션에서는 Bookinfo 애플리케이션을 감사하기 위한 몇 가지 옵션을 제공합니다. 감사 정책을 배포한 후에는 일부 요청을 전송한 후 로그 탐색기에서 감사 로그를 확인할 수 있습니다.
- 다음 명령어를 입력하여 사용자 인증 정보를 가져와 클러스터와 상호작용합니다. 또한 이 명령어는 - kubectl의 현재 컨텍스트를 클러스터로 설정합니다.- gcloud container clusters get-credentials CLUSTER_NAME \ --project=PROJECT_ID \ --zone=CLUSTER_LOCATION
- 다음 감사 정책을 적용하여 - /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
- Bookinfo에 일부 요청을 보냅니다. 
- 로그 탐색기에서 쿼리 빌더 필드에 다음 쿼리를 입력하고 쿼리 실행을 클릭합니다. - logName="projects/PROJECT_ID/logs/server-istio-audit-log"- 이 쿼리는 다음과 유사한 로그를 반환합니다.  
- 다음 정책을 적용하여 - 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- 새 감사 정책이 적용되기 전에 먼저 전파되어야 합니다. 
- Bookinfo에 10개 이상의 요청을 전송하여 평가 서비스에 도달한 후 로그 탐색기에서 감사 로그를 확인합니다. 감사 로그는 다음과 유사합니다.  
- 다음 정책을 적용하여 기본 네임스페이스의 모든 서비스를 감사합니다. - kubectl apply -f - << EOF apiVersion: security.istio.io/v1beta1 kind: AuthorizationPolicy metadata: namespace: default name: "audit-all" spec: action: AUDIT rules: - {} EOF
- Bookinfo에 몇 가지 요청을 더 전송한 후 로그 탐색기에서 감사 로그를 확인합니다. 이제 감사 로그에 모든 요청이 기록됩니다.  
- 감사 정책을 ProductPage 및 Rating으로 축소하여 제한하려면 - audit-all정책을 삭제하면 됩니다.- kubectl delete authorizationpolicy audit-all -n default
문제 해결
감사 정책을 사용 설정한 후 감사 로그가 표시되지 않으면 다음 몇 가지 사항을 확인합니다.
- 로그 탐색기에서 지정된 기간 동안 트래픽이 있는지 확인합니다. Bookinfo에서 테스트하는 경우 다음 명령어를 여러 번 실행하여 요청을 보낼 수 있습니다. - curl -s http://EXTERNAL_IP/productpage | grep Bookstore
- 감사 대상 서비스에 대한 요청을 차단하는 인그레스 게이트웨이에 - AuthorizationPolicy가 있는지 확인합니다.
- 로그 탐색기에서 다음 필터를 사용하여 - stackdriver액세스 로그를 확인하여 요청이 애플리케이션에 도달하였는지 확인합니다.- logName="projects/PROJECT_ID/logs/server-accesslog-stackdriver" 
- Stackdriver가 구성되어 있고 감사 로그가 사용 설정되어 있는지 확인하려면 현재 - istiod상태의 구성을 덤프합니다.- config_dump에서- enable_audit_log및 감사 정책의 이름을 검색합니다.- istioctl dashboard envoy POD_NAME.NAMESPACE     
- 요청이 감사 정책 규칙과 일치하는지 확인하려면 역할 기반 액세스 제어 (RBAC) 디버그 로그를 확인하세요. 다음 명령어를 사용하여 RBAC 디버그 로깅을 사용 설정합니다. - kubectl exec POD_NAME -n NAMESPACE -c istio-proxy -- pilot-agent request POST 'logging?rbac=debug'
- 요청을 보내고 - kubectl logs명령어를 사용하여 Pod의 로그를 확인합니다.- kubectl logs POD_NAME -n NAMESPACE -c istio-proxy