타사 테넌트용 GKE 클러스터 준비

이 문서에서는 타사 테넌트에서 배포한 커스텀 앱을 호스팅하는 Google Kubernetes Engine(GKE) 클러스터의 구성 및 보안 유지에 사용할 수 있는 제어 기능에 대해 설명합니다. 이 문서는 다음 요소로 구성된 청사진 솔루션을 구성합니다.

  • 구현한 제어를 설명하는 가이드(이 문서)
  • 다음 디렉터리가 포함된 GitHub 저장소:
    • terraform: 프로젝트 수준의 인프라와 리소스를 만드는 데 사용하는 Terraform 코드를 포함합니다. 이 코드는 클러스터에 Anthos 구성요소도 설치합니다.
    • configsync: GKE 클러스터에 적용되는 클러스터 수준 리소스 및 구성을 포함합니다.
    • tenant-config-pkg: GKE 클러스터에서 새 테넌트를 구성하는 템플릿으로 사용할 수 있는 kpt 패키지입니다.

이 문서의 대상자는 GKE 클러스터를 관리하는 팀이며, 사용자가 GKE 및 Kubernetes에 익숙하다고 가정하고 작성되었습니다.

이 문서에서는 Google Cloud 보안 기반 가이드에서 설명하는 제어와 같이 클라우드 인프라를 보호하기 위한 일련의 기본적인 보안 제어가 이미 구성되었다고 가정합니다. 청사진을 사용하면 기존 보안 제어에 추가 제어를 계층화하여 GKE 클러스터를 보호할 수 있습니다.

건축물

다음 다이어그램은 이 청사진을 사용하여 생성한 아키텍처를 설명합니다.

청사진의 인프라 구성요소

앞의 다이어그램에서 볼 수 있듯이 청사진을 사용하면 다음 인프라 구성요소를 만들고 구성할 수 있습니다.

  • Virtual Private Cloud(VPC) 네트워크와 서브넷
  • 비공개 GKE 클러스터. 클러스터 노드는 인터넷에서 격리됩니다.
  • 두 개의 GKE 노드 풀. 테넌트 앱 및 리소스만 호스팅하는 전용 노드 풀을 만듭니다. 다른 클러스터 리소스는 기본 노드 풀에서 호스팅됩니다.
  • VPC 방화벽 규칙. 클러스터의 모든 노드에 적용되는 기준 규칙을 만듭니다. 테넌트 노드 풀의 노드에만 적용되는 추가 규칙을 만들 수 있습니다. 이러한 방화벽 규칙은 테넌트 노드에서 이그레스를 제한합니다.
  • 클러스터 노드에서 인터넷으로 이그레스를 허용하는 Cloud NAT.
  • 클러스터 내의 앱이 인터넷을 거치지 않고 Google API에 액세스할 수 있도록 비공개 Google 액세스를 사용 설정하도록 구성된 Cloud DNS 규칙.
  • 클러스터 노드 및 앱에서 사용되는 서비스 계정.

애플리케이션

다음은 청사진으로 만들고 구성하는 클러스터 수준 리소스를 보여주는 다이어그램입니다.

클러스터 수준의 리소스

앞의 다이어그램에 표시된 것처럼 청사진에서 다음을 사용하여 클러스터 수준 리소스를 만들고 구성합니다.

  • Anthos Config Management 구성 동기화를 사용하여 Git 저장소의 클러스터 구성 및 정책을 동기화합니다.
  • Anthos Config Management 정책 컨트롤러는 클러스터의 리소스에 정책을 적용합니다.
  • Anthos Service Mesh를 사용하여 네트워크 트래픽을 제어하고 보호합니다.
  • 테넌트 앱 및 리소스 전용 네임스페이스입니다.
  • 네트워크 정책 및 서비스 메시 정책을 포함하여 테넌트 네임스페이스에 적용되는 정책 및 제어입니다.

필요한 보안 제어 이해

이 섹션에서는 청사진에 적용하여 GKE 클러스터를 보호하는 데 도움이 되는 제어에 대해 설명합니다.

GKE 클러스터의 보안 강화

보안 권장사항에 따라 클러스터를 만드세요.

청사진을 사용하면 다음 보안 설정을 구현하는 GKE 클러스터를 만들 수 있습니다.

GKE 보안 설정에 대한 상세 설명은 클러스터 보안 강화를 참조하세요.

VPC 방화벽 규칙

가상 머신 간 트래픽 제한

Virtual Private Cloud(VPC) 방화벽 규칙은 Compute Engine VM에서 송수신이 허용된 트래픽에 적용됩니다. 이 규칙을 사용하면 레이어 4 속성에 따라 VM 단위로 트래픽을 필터링할 수 있습니다.

기본 GKE 클러스터 방화벽 규칙으로 GKE 클러스터를 만듭니다. 이러한 방화벽 규칙은 클러스터 노드와 GKE 제어 영역 간, 클러스터의 노드와 포드 간의 통신을 사용 설정합니다.

테넌트 노드 풀의 노드에 방화벽 규칙을 추가로 적용합니다. 이러한 방화벽 규칙은 테넌트 노드의 이그레스 트래픽을 제한합니다. 이렇게 하면 테넌트 노드의 격리를 늘릴 수 있습니다. 기본적으로 테넌트 노드의 모든 이그레스 트래픽은 거부됩니다. 모든 필수 이그레스는 명시적으로 구성되어야 합니다. 예를 들어 청사진을 사용해, 테넌트 노드에서 GKE 제어 영역으로의 이그레스를 허용하고, 비공개 Google 액세스를 사용하여 Google API로의 이그레스를 허용하는 방화벽 규칙을 만듭니다. 방화벽 규칙은 테넌트 노드 풀 서비스 계정을 사용하는 테넌트 노드를 대상으로 합니다.

네임스페이스

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

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

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

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

청사진을 사용하면 제휴 학습 앱을 호스팅할 전용 네임스페이스를 만들 수 있습니다. 네임스페이스 및 해당 리소스는 클러스터 내에서 테넌트로 취급됩니다. 네임스페이스에 정책 및 제어를 적용하여 네임스페이스의 리소스 범위를 제한합니다.

네트워크 정책

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

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

청사진에서는 타사 앱을 호스팅하는 테넌트 네임스페이스에 네트워크 정책을 적용합니다. 기본적으로 네트워크 정책은 네임스페이스의 포드와 주고 받는 모든 트래픽을 거부합니다. 필요한 트래픽은 명시적으로 허용되어야 합니다. 예를 들어 청사진의 네트워크 정책은 클러스터 내부 DNS 및 Anthos Service Mesh 제어 영역과 같은 필수 클러스터 서비스에 대한 트래픽을 명시적으로 허용합니다.

구성 동기화

GKE 클러스터에 구성 적용

구성 동기화는 GKE 클러스터를 Git 저장소에 저장된 구성과 동기화된 상태로 유지합니다. Git 저장소는 클러스터 구성 및 정책에 대한 단일 신뢰 소스로 작동합니다. 구성 동기화는 선언적입니다. 구성 동기화는 클러스터 상태를 지속적으로 확인하고 구성 파일에 선언된 상태를 적용하여 정책을 시행하는데, 이는 구성 드리프트를 방지하는 데 도움이 됩니다.

GKE 클러스터에 구성 동기화를 설치합니다. 청사진과 연결된 GitHub 저장소에서 클러스터 구성 및 정책을 동기화하도록 구성 동기화를 구성합니다. 동기화된 리소스에는 다음이 포함됩니다.

  • 클러스터 수준 Anthos Service Mesh 구성
  • 클러스터 수준 보안 정책
  • 네트워크 정책, 서비스 계정, RBAC 규칙, Anthos Service Mesh 구성을 포함한 테넌트 네임스페이스 수준 구성 및 정책

정책 컨트롤러

정책 준수 시행

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

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

GKE 클러스터에 정책 컨트롤러를 설치합니다. 청사진에는 클러스터 보안을 지원하는 정책 예시가 포함되어 있습니다. 구성 동기화를 사용하여 클러스터에 정책을 자동으로 적용합니다. 다음 정책을 적용합니다.

Anthos Service Mesh

서비스 간 보안 통신 관리

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

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

  • 트래픽 인증 및 암호화 관리(상호 전송 계층 보안(mTLS)을 사용하여 클러스터 내에서 지원되는 프로토콜). Anthos Service Mesh는 통신을 중단하지 않고 Anthos 워크로드의 mTLS 키 및 인증서의 프로비저닝 및 순환을 관리합니다. 정기적인 mTLS 키 순환은 공격 시 노출을 줄이는 데 도움이 되는 보안 권장사항입니다.
  • 네트워크에서 피어의 IP 주소가 아닌 서비스 ID를 기반으로 네트워크 보안 정책을 구성할 수 있습니다. Anthos Service Mesh는 워크로드의 네트워크 위치와 관계없이 보안 정책을 만들 수 있는 ID 인식 액세스 제어(방화벽) 정책을 구성하는 데 사용됩니다. 이 접근 방식은 서비스 간 통신 정책을 설정하는 프로세스를 단순화합니다.
  • 특정 클라이언트의 액세스를 허용하는 정책을 구성할 수 있습니다.

청사진은 클러스터에 Anthos Service Mesh를 설치하는 방법을 안내합니다. 사용자는 자동 사이드카 프록시 주입의 테넌트 네임스페이스를 구성하면 됩니다. 이 방법을 사용하면 테넌트 네임스페이스의 앱이 메시에 포함됩니다. 구성 동기화를 사용하여 Anthos Service Mesh를 자동으로 구성할 수 있습니다. 다음 작업을 수행하도록 메시를 구성하세요.

  • 메시의 서비스 간에 mTLS 통신을 적용합니다.
  • 메시에서 아웃바운드 트래픽을 알려진 호스트로만 제한하세요.
  • 메시에서 서비스 간 승인된 통신을 제한합니다. 예를 들어 테넌트 네임스페이스의 앱은 동일한 네임스페이스의 앱 또는 일련의 알려진 외부 호스트와만 통신할 수 있습니다.
  • 추가 트래픽 제어를 적용할 수 있는 메시 게이트웨이를 통해 모든 아웃바운드 트래픽을 라우팅합니다.

노드 taint 및 어피니티

워크로드 예약 제어

노드 taint노드 어피니티는 포드가 클러스터 노드에 예약되는 방식에 영향을 줄 수 있는 Kubernetes 메커니즘입니다.

taint된 노드는 포드를 삭제합니다. 포드는 taint에 대한 내결함성이 없는 한 taint된 노드에 포드를 예약하지 않습니다. 노드 taint를 사용하면 특정 워크로드나 테넌트만 사용할 수 있도록 노드를 예약할 수 있습니다. taint 및 내결함성은 종종 멀티 테넌트 클러스터에서 사용됩니다. 자세한 내용은 taint 및 내결함성이 있는 전용 노드 문서를 참조하세요.

노드 어피니티를 사용하면 포드를 특정 라벨이 있는 노드로 제한할 수 있습니다. 포드에 노드 어피니티 요구사항이 있는 경우 Kubernetes는 노드에 어피니티 요구사항과 일치하는 라벨이 없는 한 포드를 노드에 예약하지 않습니다. 노드 어피니티를 사용하여 포드가 적절한 노드에 예약되도록 할 수 있습니다.

노드 taint 및 노드 어피니티를 함께 사용하여 테넌트 워크로드가 테넌트용으로 예약된 노드에만 예약되도록 할 수 있습니다.

청사진을 사용하면 다음과 같은 방법으로 테넌트 앱의 예약을 제어할 수 있습니다.

  • 테넌트 전용 GKE 노드 풀 만들기 풀의 각 노드에는 테넌트 이름과 관련된 taint가 있습니다.
  • 테넌트 네임스페이스를 타겟팅하는 모든 포드에 적절한 내결함성 및 노드 어피니티를 자동으로 적용합니다. PolicyController 변형을 사용하여 내결함성과 어피니티를 적용하세요.

최소 권한

클러스터 및 프로젝트 리소스에 대한 액세스 제한

GKE 클러스터와 같은 Google Cloud 프로젝트 및 리소스에 대해 최소 권한 원칙을 채택하는 것이 보안 권장사항입니다. 이렇게 하면 클러스터 내에서 실행되는 앱과 클러스터를 사용하는 개발자 및 운영자에게 필요한 최소 권한 집합만 있게 됩니다.

청사진을 사용하면 다음과 같은 방식으로 최소 권한 서비스 계정을 사용할 수 있습니다.

  • 각 GKE 노드 풀이 자체 서비스 계정을 수신합니다. 예를 들어 테넌트 노드 풀의 노드는 이러한 노드 전용 서비스 계정을 사용합니다. 노드 서비스 계정은 최소 필수 권한으로 구성됩니다.
  • 클러스터는 워크로드 아이덴티티를 사용하여 Kubernetes 서비스 계정을 Google 서비스 계정과 연결합니다. 이렇게 하면 테넌트 앱은 서비스 계정 키를 다운로드하여 저장하지 않아도 모든 필요한 Google API에 대한 제한된 액세스 권한을 부여 받을 수 있습니다. 예를 들어 Cloud Storage 버킷에서 데이터를 읽을 수 있는 권한을 서비스 계정에 부여할 수 있습니다.

청사진을 사용하면 다음과 같은 방식으로 클러스터 리소스에 대한 액세스를 제한할 수 있습니다.

  • 앱 관리 권한이 제한된 샘플 Kubernetes RBAC 역할을 만듭니다. 테넌트 네임스페이스에서 앱을 운영하는 사용자 및 그룹에 이 역할을 부여할 수 있습니다. 이렇게 하면 해당 사용자는 테넌트 네임스페이스의 앱 리소스만 수정할 수 있는 권한을 갖게 됩니다. 그러나 Anthos Service Mesh 정책과 같은 클러스터 수준 리소스 또는 민감한 보안 설정을 수정할 권한은 없습니다.

총정리

이 문서에 설명된 아키텍처를 구현하려면 다음을 수행하세요.

  1. 청사진을 보안 기반 청사진과 함께 배포할지, 아니면 보안 기반 청사진 없이 배포할지 결정합니다. 보안 기반 청사진을 배포하지 않기로 한 경우에는 해당 환경에 비슷한 보안 기준이 설정되어 있어야 합니다.
  2. 청사진의 Readme를 검토하고 모든 기본 요건을 충족해야 합니다.
  3. 테스트 환경에서 이 아키텍처의 인스턴스 하나를 배포합니다. 테스트 프로세스 중 다음을 실행합니다.
    1. 테넌트 서비스 예시를 배포하고 클러스터 구성을 확인하세요.
    2. 클러스터에 다른 테넌트를 추가합니다.
  4. 프로덕션 환경에 청사진을 배포합니다.
  5. 클러스터에 테넌트를 추가합니다.

다음 단계