이전 버전의 GKE On-Prem 문서를 보고 있습니다. 최신 문서 보기

보안

이 페이지에서는 인프라의 각 레이어를 포함하여 GKE On-Prem에 포함된 보안 기능과 이러한 보안 기능을 필요에 맞게 구성하는 방법을 설명합니다.

개요

GKE On-Prem은 컨테이너 이미지, 컨테이너 런타임, 클러스터 네트워크, 클러스터 API 서버 액세스 등 워크로드를 보호하는 데 도움이 되는 여러 기능을 제공합니다.

클러스터와 워크로드를 보호하려면 계층화된 접근 방식을 취하는 것이 가장 좋습니다. 사용자 및 워크로드에 제공하는 액세스 수준에 최소 권한 원칙을 적용할 수 있습니다. 적절한 수준의 유연성과 보안을 위해 절충해야 할 수도 있습니다.

인증 및 승인

OpenID Connect(OIDC)(kubectl를 통함) 또는 Kubernetes Service Account 토큰(Cloud Console을 통함)을 사용하여 GKE On-Prem 클러스터에 인증합니다.

클러스터 수준 또는 Kubernetes 네임스페이스 내에서 Kubernetes 리소스에 대한 액세스 권한을 더 상세하게 구성하려면 Kubernetes 역할 기반 액세스 제어(RBAC)를 사용합니다. RBAC를 사용하면 사용자와 서비스 계정이 액세스할 수 있는 작업과 리소스를 정의하는 자세한 정책을 만들 수 있습니다. RBAC를 사용하면 제공된 확인 ID에 대한 액세스를 제어할 수 있습니다.

Kubernetes Engine의 인증 및 승인 전략을 더 단순화하고 간소화하기 위해 GKE On-Prem은 ABAC(기존 속성 기반 액세스 제어)를 사용 중지합니다.

자세한 내용은 프로덕션을 위한 Kubernetes Engine 환경 준비를 참조하세요.

제어 영역 보안

제어 영역 구성요소에는 Kubernetes API 서버, 스케줄러, 컨트롤러, 그리고 Kubernetes 구성이 유지되는 etcd 데이터베이스가 포함됩니다. Kubernetes Engine에서 Kubernetes 제어 영역 구성요소는 Google에서 관리하고 유지하지만, 로컬 관리자는 GKE On-Prem의 제어 영역 구성요소를 관리합니다.

GKE On-Prem에서 제어 영역 구성요소는 회사 네트워크 내에서 실행됩니다. 기존 회사 네트워크 정책 및 방화벽을 사용하여 GKE On-Prem의 API 서버를 보호할 수 있습니다. API 서버에 비공개 IP 주소를 할당하고 비공개 주소에 대한 액세스를 제한할 수도 있습니다.

GKE On-Prem의 모든 통신은 TLS 채널을 통해 이루어지며, etcd, 클러스터, 조직 등 세 가지 인증 기관(CA)에서 관장합니다.

  • etcd CA는 API 서버에서 etcd 복제본으로의 통신과 etcd 복제본 간 트래픽도 보호합니다. 이 CA는 자체 서명됩니다.
  • 클러스터 CA는 API 서버와 모든 내부 Kubernetes API 클라이언트 (kubelet, 컨트롤러, 스케줄러) 간의 통신을 보호합니다. 이 CA는 자체 서명됩니다.
  • 조직 CA는 외부 사용자에게 Kubernetes API를 제공하는 데 사용되는 외부 CA입니다. 이 CA를 관리합니다.

관리자 제어 영역의 경우 키는 제어 영역 노드에 저장됩니다. 사용자 클러스터의 경우 키는 관리자 제어 영역에 Kubernetes 보안 비밀로 저장됩니다. API 서버는 조직 CA에서 서명한 사용자 제공 인증서로 구성됩니다. API 서버는 SNI(서버 이름 표시)를 사용하여 클러스터 CA에서 서명한 키를 사용할지 아니면 조직 CA에서 서명한 키를 사용할지 결정합니다.

GKE On-Prem의 클러스터 인증은 인증서 및 서비스 계정 bearer 토큰에 의해 처리됩니다. 관리자는 OIDC를 사용하거나 관리 인증서(초기 역할 결합 생성 또는 긴급 목적)를 사용하여 제어 영역에 인증합니다.

인증서 순환은 다음과 같은 방식으로 처리됩니다.

  • API 서버, 제어 영역, 노드의 경우 업그레이드할 때마다 인증서가 생성되거나 순환됩니다.
  • CA는 거의 순환하지 않거나 요청 시 순환할 수 있습니다.

노드 보안

GKE On-Prem는 노드인 클러스터에 연결된 VMware 인스턴스에 워크로드를 배포합니다. 다음 섹션에서는 GKE On-Prem에서 사용할 수 있는 노드 수준 보안 기능을 활용하는 방법을 설명합니다.

Ubuntu

GKE On-Prem은 최적화된 버전의 Ubuntu를 Kubernetes 제어 영역 및 노드를 실행할 운영체제로 사용합니다. Ubuntu에는 풍부한 최신 보안 기능이 포함되어 있으며 GKE On-Prem은 다음과 같은 여러 보안 강화 기능이 구현되어 있습니다.

Ubuntu에는 다음과 같은 추가 보안 가이드가 제공됩니다.

노드 업그레이드

정기적으로 노드를 업그레이드해야 합니다. 때때로 컨테이너 런타임, Kubernetes 자체 또는 노드 운영체제의 보안 문제로 인해 노드를 급히 업그레이드해야 할 수도 있습니다. 클러스터를 업그레이드하면 각 노드의 소프트웨어는 최신 버전으로 업그레이드됩니다.

워크로드 보안

사용자는 Kubernetes를 통해 컨테이너 기반 워크로드를 신속하게 프로비저닝, 확장, 업데이트할 수 있습니다. 이 섹션에서는 관리자 및 사용자가 실행 중인 컨테이너가 클러스터의 다른 컨테이너, 실행 호스트, 프로젝트에 사용 설정된 GCP 서비스에 영향을 미치도록 기능을 제한하는 방법을 설명합니다.

pod 컨테이너 프로세스 권한 제한

컨테이너식 프로세스의 권한 제한은 클러스터 전체 보안에 중요합니다. Kubernetes Engine을 사용하면 Pod와 컨테이너 모두에서 보안 컨텍스트를 통해 보안 관련 옵션을 설정할 수 있습니다. 이 설정을 사용하면 다음과 같은 프로세스의 보안 설정을 변경할 수 있습니다.

  • 실행할 사용자와 그룹
  • 사용할 수 있는 Linux 기능
  • 권한 에스컬레이션

Pod 또는 컨테이너 수준이 아닌 클러스터 수준에서 이러한 설정을 변경하려면 PodSecurityPolicy 리소스를 만들어야 합니다. PodSecurityPolicies는 클러스터의 모든 Pod가 개발자가 정의한 최소 기준 정책을 준수하도록 할 수 있습니다.

기본 GKE On-Prem 노드 운영체제인 Ubuntu는 Kubernetes가 시작하는 모든 컨테이너에 기본 Docker AppArmor 보안 정책을 적용합니다. GitHub에서 프로필 템플릿을 확인할 수 있습니다. 무엇보다 이 프로필은 컨테이너에 대해 다음과 같은 기능을 거부합니다.

  • 프로세스 ID 디렉터리(/proc/)의 파일에 직접 쓰기
  • /proc/에 없는 파일에 쓰기
  • /proc/sys/kernel/shm*이 아니라 /proc/sys에 있는 파일에 쓰기
  • 파일 시스템 마운트

감사 로깅

Kubernetes 감사 로깅은 관리자가 GKE On-Prem 환경에서 발생하는 이벤트를 보관, 쿼리, 처리하고 알릴 수 있는 방법을 제공합니다. 관리자는 로깅된 정보를 사용하여 포렌식 분석 또는 실시간 알림을 수행하거나 Kubernetes Engine 클러스터 사용 방법과 사용자를 분류할 수 있습니다.

기본적으로 GKE On-Prem은 관리자 활동을 로깅합니다. 원하는 경우 검사하려는 작업 유형에 따라 데이터 액세스 이벤트를 로깅할 수도 있습니다.

Connect Agent는 온프레미스에서 실행하는 로컬 API 서버에만 통신하며 각 클러스터에는 자체 감사 로그 집합이 있어야 합니다. 사용자가 Connect를 통해 UI에서 수행하는 모든 작업은 해당 클러스터에서 로깅합니다.

암호화

Google Cloud Key Management Service(Cloud KMS)는 서비스의 암호화 키를 관리할 수 있는 클라우드 호스팅 키 관리 서비스입니다. AES256, RSA 2048, RSA 3072, RSA 4096, EC P256, EC P384 암호화 키를 생성, 사용, 순환, 폐기할 수 있습니다. Cloud KMS는 Cloud IAMCloud Audit Logging과 통합되어 개별 키의 권한을 관리하고 어떻게 사용되는지 모니터링할 수 있습니다. Cloud KMS를 사용하여 보안 비밀과 저장해야 할 기타 민감한 정보를 보호하세요.

Cloud VPN을 통해 GKE On-Prem 클러스터와 워크로드가 Google Cloud 서비스에 안전하게 연결되면 Cloud KMS를 키 관리에 사용할 수 있습니다. 그렇지 않으면 다음 대안 중 하나를 사용할 수 있습니다.

  • Kubernetes 보안 비밀
  • Hashicorp Vault
  • 하드웨어 보안 모듈(HSM)

Kubernetes 보안 비밀

Kubernetes 보안 비밀 리소스는 비밀번호, OAuth 토큰, SSH 키와 같은 민감한 데이터를 클러스터에 저장합니다. 민감한 데이터를 보안 비밀에 저장하는 것은 일반 텍스트로 된 ConfigMaps 또는 pod 사양에 저장하는 것보다 안전합니다. 보안 비밀을 사용하면 민감한 데이터의 사용 방식을 제어하고 승인되지 않은 사용자에게 데이터가 노출될 위험을 줄일 수 있습니다.

Hashicorp Vault

하드웨어 보안 모듈