Anthos 보안 세부 계획: 정책 시행

이 문서에서는 Anthos 클러스터에 대해 보안 정책을 시행하는 방법을 설명합니다. 여기에서는 정책을 시행하는 방법과 이유를 간단히 살펴보고 이 작업에 사용되는 Google Cloud 제어를 설명합니다.

이 문서는 Anthos 사용에 관한 처방적 안내를 제공하는 보안 세부 계획 시리즈 중 하나입니다.

소개

클러스터에 정책을 적용하여 보안 가이드레일 및 규정 준수 요구사항을 충족하는지 확인합니다. 정책을 적용한 후에는 정책이 시행되고 Anthos 클러스터의 설정이 지정된 정책 구성을 준수하는지 확인해야 합니다.

정책 시행은 클러스터 감사를 보완합니다. 감사를 수행하면 클러스터의 과거 및 현재 상태를 알 수 있지만 정책을 우회하는 다른 작업들을 방지하지는 못합니다. 반면에 정책 시행을 통해서는 이를 예방적으로 제어할 수 있습니다. 요구사항을 충족하려면 클러스터 및 네임스페이스 수준에서 정책을 적용해야 합니다.

다음 요구사항을 적용하는 방법을 고려해야 합니다.

  • 리소스 소비 제한
  • 클러스터 내 네트워크 트래픽 제한
  • pod를 실행할 수 있는 기능 제한
  • 필수 라벨 시행과 같은 커스텀 정책 정의

필요한 보안 제어 이해

이 섹션에서는 보안 및 규정 준수 요구사항을 충족하는 데 도움이 되는 정책을 시행하기 위해 필요한 제어를 설명합니다.

네임스페이스

동일한 정책을 사용하는 리소스 라벨 지정

네임스페이스를 사용하면 pod, 서비스, 복제 컨트롤러와 같이 클러스터 내의 관련 리소스에 범위를 제공할 수 있습니다. 네임스페이스를 사용하면 관련 리소스에 대한 관리 책임을 하나의 단위로 위임할 수 있습니다. 따라서 네임스페이스는 대부분의 보안 패턴에 필수적입니다.

네임스페이스는 제어 영역 격리를 위한 중요한 기능입니다. 하지만 노드 격리, 데이터 영역 격리, 네트워크 격리를 제공하지 않습니다.

일반적인 방법은 개별 애플리케이션에 대해 네임스페이스를 만드는 것입니다. 예를 들어 애플리케이션의 UI 구성요소에 대해 myapp-frontend 네임스페이스를 만들 수 있습니다.

리소스 할당량

리소스 소비 관리

GKE는 여러 팀에서 관리하는 동일한 클러스터에서 실행되는 여러 애플리케이션을 지원하도록 설계되었습니다. 클러스터에서 리소스 사용량을 관리하는 단일 팀이 없는 경우 클러스터에서 실행되는 애플리케이션이 필요한 것보다 많은 리소스를 소비할 수 있습니다. 이러한 상황을 방지하려면 관리자는 네임스페이스 내에 정의된 리소스의 집계된 리소스 소비를 제한하기 위해 리소스 할당량을 구성해야 합니다.

Anthos Config Management

Anthos 클러스터에 구성 적용

Anthos 클러스터를 관리할 때 권장사항은 등록된 클러스터를 구성과 동기화된 상태로 유지하는 Anthos Config Management를 사용하는 것입니다. 구성저장소에 저장된 YAML 또는 JSON 파일이며 kubectl apply 명령어를 사용하여 클러스터에 수동으로 적용할 수 있는 동일한 유형의 구성 세부정보를 포함합니다. Anthos Config Management를 사용하면 코드형 정책 방식을 채택하여 앱을 관리하듯이 정책 및 인프라 배포를 관리할 수 있습니다.

Anthos Config Management는 선언된 정책에 대해 단일 신뢰 소스로 사용되는 Git 저장소와 함께 사용합니다. Anthos Config Management는 RBAC, 리소스 할당량, 플랫폼 수준 인프라 배포와 같은 액세스 제어 정책을 관리할 수 있습니다. Anthos Config Management는 선언적입니다. 클러스터 상태를 지속적으로 확인하고, 정책 시행을 위해 구성에 선언된 상태를 적용합니다.

네트워크 정책

클러스터 내 네트워크 트래픽 흐름 시행

네트워크 정책은 pod 수준의 방화벽 규칙을 사용하여 레이어 4 네트워크 트래픽 흐름을 시행합니다. 네트워크 정책은 네임스페이스로 범위가 지정됩니다.

기본적으로 해당 네임스페이스에 네트워크 정책이 사용 설정되어 있어도 클러스터의 pod에 대한 액세스는 제한되지 않습니다. 하나 이상의 NetworkPolicy 객체가 pod를 선택하면 시행이 적용됩니다.

가장 좋은 방법은 최소 권한 접근 방식을 사용하는 것입니다. 네트워크 정책을 구현할 때는 모든 pod와 일치하도록 네임스페이스에 기본 거부 규칙을 만드는 것이 좋습니다. 이렇게 하면 네임스페이스가 액세스를 차단합니다(즉, Fail Closed 시스템 역할을 함). 네트워크 트래픽 흐름을 허용하려면 각 네임스페이스에 대해 명시적으로 네트워크 정책을 설정해야 합니다.

다음 다이어그램은 각 네임스페이스에 대한 네트워크 정책을 구성하여 네임스페이스 간의 트래픽 흐름을 관리하는 정책을 구현할 수 있음을 보여줍니다.

네트워크 정책을 사용하여 네임스페이스 간의 트래픽 흐름 관리

이 예시에서는 네임스페이스 트랜잭션과 네임스페이스 홈페이지 간에 양방향으로 트래픽이 전달될 수 있습니다. 그러나 트래픽은 네임스페이스 홈페이지에서 로깅 앱으로만 전달될 수 있습니다.

Anthos Config Management를 사용하여 적용할 수 있는 NetworkPolicy 구성의 예시는 Kubernetes 객체 구성의 'NetworkPolicy config' 섹션을 참조하세요.

Anthos Policy Controller

정책 규정 준수 시행

Anthos Policy ControllerOpen Policy Agent(OPA)로 실행되는 CustomResourceDefinition 기반(CRD 기반) 정책을 시행하는 Kubernetes용 동적 허용 컨트롤러입니다.

허용 컨트롤러는 객체가 유지되기 전에, 하지만 요청이 승인되고 허용된 이후에 Kubernetes API 서버로의 요청을 가로채는 Kubernetes 플러그인입니다. 허용 컨트롤러를 사용하면 클러스터 사용 방법을 제한할 수 있습니다.

Policy Controller를 사용하려면 제약조건 템플릿에서 제약조건 집합을 선언합니다. 제약조건 템플릿이 클러스터에 배포되었으면 제약조건 템플릿으로 정의되는 개별 제약조건 CRD를 만들 수 있습니다.

다음 다이어그램은 Policy Controller가 OPA 제약조건 프레임워크를 사용하여 정책을 정의하고 시행하는 방법을 보여줍니다.

OPA 제약조건 프레임워크는 요청을 수신하고 다른 리소스에 대해 액세스 정책을 시행합니다.

다이어그램에 표시된 항목은 다음과 같습니다.

  1. 제약조건은 제약조건 템플릿에서 생성됩니다.
  2. 정책은 제약조건을 적용하여 클러스터에서 사용 설정됩니다.
  3. 요청이 들어오고 허용 검토가 트리거되어 허용 또는 거부가 결정됩니다.
  4. 지속적인 감사로 정책에 대해 클러스터의 모든 활성 객체를 평가합니다.

Policy Controller를 사용하여 라벨 시행과 같이 커스텀 정책을 시행할 수 있습니다. Policy Controller를 사용하면 PodSecurityPolicies를 사용하여 적용할 수 있는 제약조건을 대부분 적용할 수 있습니다. 하지만 일반적으로는 다음 이유로 인해 더 적은 운영 오버헤드가 필요합니다.

  • Policy Controller에는 제약조건 템플릿이 포함된 기본 템플릿 라이브러리가 있습니다. 따라서 PodSecurityPolicies에서와 같이 일반 사례에 대해 고유 정책을 작성할 필요가 없습니다.
  • PodSecurityPolicies를 사용할 때와 같이 RoleBindings를 관리할 필요가 없습니다.
  • Policy Controller에는 연습 실행 모드가 지원됩니다. 따라서 제약조건을 적용하기 전에 제약조건 효과를 검사할 수 있습니다.
  • 정책 범위를 네임스페이스로 지정하여 보다 제한적인 정책을 보다 느리게 적용할 수 있습니다. 이것은 예상치 않은 효과가 발생할 수 있는 정책 출시의 노출을 관리하는 카나리아 릴리스 전략과 비슷합니다. 예를 들어 출시했을 때 Pod에서 볼륨으로의 액세스가 제한되었지만 Pod에 볼륨 액세스가 필요하다는 것이 밝혀질 수 있습니다.
  • Policy Controller는 커스텀 제약조건 또는 Gatekeeper 저장소에 저장된 PodSecurityPolicies 제약조건인지 여부에 관계없이 정책을 적용하기 위한 단일 방법을 제공합니다.

Policy Controller를 사용하여 사용자가 정의하는 정책을 시행하는 방법에 대한 자세한 내용은 Anthos Config Management Policy Controller를 참조하세요.

Anthos Service Mesh

서비스 간 보안 통신 관리

Anthos Service Mesh를 사용하면 Istio 기반 서비스 메시를 모니터링하고 관리할 수 있습니다. 서비스 메시는 서비스 전반에서 관측 가능하고 안전한 관리형 통신을 지원하는 인프라 레이어입니다.

Anthos Service Mesh는 다음과 같은 방식으로 서비스 간 보안 통신 관리를 간소화합니다.

  • 트래픽 인증 및 암호화 관리(상호 전송 계층 보안(mTLS)을 사용하여 클러스터 내에서 지원되는 프로토콜). Anthos Service Mesh는 통신을 중단하지 않고 Anthos 워크로드의 mTLS 키 및 인증서의 프로비저닝 및 순환을 관리합니다. 정기적인 mTLS 키 순환은 공격 시 노출을 줄이는 데 도움이 되는 보안 권장사항입니다.
  • 피어 IP 주소가 아닌 서비스 ID를 기반으로 네트워크 보안 정책을 구성할 수 있습니다. Anthos Service Mesh는 워크로드의 네트워크 위치와 관계없이 정책을 만들 수 있는 ID 인식 액세스 제어(방화벽) 정책을 구성하는 데 사용됩니다. 따라서 서비스 간 통신을 설정하는 과정이 간소화됩니다.
  • 특정 클라이언트의 액세스를 허용하는 정책을 구성할 수 있습니다.
  • IAP(Identity-Aware Proxy) 또는 커스텀 정책 엔진을 사용하여 사용자 인증을 관리합니다. 이를 통해 사용자 ID 및 요청의 컨텍스트를 확인하여 사용자가 액세스를 허용해야 하는지 여부를 결정함으로써 Anthos GKE 클러스터에 배포한 애플리케이션에 대한 액세스를 제어할 수 있습니다.

Anthos Service Mesh는 서비스 간 보안 통신을 관리할 뿐만 아니라 구성 가능한 각 기간에 성공한 액세스를 한 번만 로깅하여 액세스 로그의 노이즈를 줄여줍니다. 보안 정책에서 거부되거나 오류가 발생하는 요청은 항상 로깅됩니다. 액세스 로그 및 측정항목은 Google Cloud의 작업 제품군에서 사용할 수 있습니다.

Anthos Service Mesh 보안 기능에 대한 자세한 내용은 Anthos Service Mesh 보안 개요를 참조하세요.

총정리

앞부분에서 설명한 제어는 Anthos GKE 및 Anthos GKE On-Prem 모두에 적용됩니다.

제어를 통합하려면 이어지는 단계에 설명된 대로 이 가이드에 설명된 제어 범위와 이를 구성할 단계를 배치합니다.

  1. 적용 가능한 클러스터 강화 가이드(GKE 또는 Anthos GKE On-Prem)의 안내에 따라 클러스터를 만듭니다. 클러스터를 만들 때는 강화 가이드를 따르고 --enable-network-policy 플래그를 사용해야 합니다. 네트워크 정책이 필요하며 이 단계에서는 이후에 클러스터의 pod 간에 전송되는 트래픽을 제한하는 방화벽 규칙을 구현할 수 있습니다.
  2. pod에 필요한 네임스페이스 및 라벨을 정의합니다. 여기에서 정책 및 Kubernetes 서비스 계정에 사용할 수 있는 이름 범위를 제공합니다.
  3. Anthos Config Management를 사용하여 Policy Controller를 설치합니다.
  4. Anthos Config Management를 사용하여 네트워크 정책을 적용합니다.
  5. 사용할 사전 빌드된 Policy Controller 제약조건 템플릿을 수집하고 제약조건을 정의하여 리소스에 매핑합니다.
  6. Anthos Config Management를 사용하여 제약조건 템플릿과 제약조건을 적용합니다.

애플리케이션 레이어(레이어 7)에 초점을 맞춘 추가 제어를 적용하여 다음과 같이 Anthos Service Mesh를 통해 추가로 정책을 시행할 수 있습니다.

  • 클러스터를 만들 때 Istio 정책 시행을 사용 설정하지 않았다면 지금 사용 설정합니다.
  • 애플리케이션 레이어에서 시행할 정책을 정의합니다. 정책은 YAML로 표현됩니다.
  • Anthos Config Management를 사용하여 정책을 적용합니다.