보안

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

개요

GKE on AWS는 컨테이너 이미지 콘텐츠, 컨테이너 런타임, 클러스터 네트워크, 클러스터 API 서버 액세스를 포함한 워크로드를 보호하는 데 유용한 여러 가지 기능을 제공합니다.

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

공동 책임

GKE on AWS를 사용하는 경우 클러스터에 대한 특정 책임을 질 것에 동의하는 것으로 간주됩니다. 자세한 내용은 GKE 클러스터 공동 책임을 참조하세요.

인증 및 승인

다음 방법 중 하나를 사용하여 GKE on AWS 사용자 클러스터에 인증합니다.

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

Kubernetes Engine의 인증 및 승인 전략을 더욱 단순화하고 간소화하도록 GKE on AWS는 기존 속성 기반 액세스 제어(ABAC)를 중지합니다.

암호화

기본적으로 GKE on AWS는 AWS 키 관리 서비스(KMS)를 사용하여 etcd의 저장 데이터, EBS 볼륨, Kubernetes 보안 비밀, 제어 영역 구성요소를 암호화합니다.

사용자 클러스터에서 민감한 정보를 암호화하려면 다음 중 하나를 사용하세요.

Kubernetes 보안 비밀

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

Hashicorp Vault

GKE on AWS는 Hashicorp Vault를 사용하여 사용자 클러스터의 보안 비밀을 보호할 수 있습니다. 자세한 내용은 GKE on AWS에서 HashiCorp Vault 사용을 참조하세요.

제어 영역 보안

제어 영역 구성요소에는 관리 서비스와 사용자 클러스터의 Kubernetes API 서버, 스케줄러, 컨트롤러, etcd 데이터베이스가 포함되어 있습니다. GKE on AWS에서 로컬 관리자는 제어 영역 구성요소를 관리합니다.

GKE on AWS에서 제어 영역 구성요소는 AWS에서 실행됩니다. AWS 보안 그룹과 네트워크 ACL을 사용하여 GKE on AWS의 API 서버를 보호할 수 있습니다.

GKE on AWS의 모든 통신은 다음 인증 기관(CA)에서 관장하는 전송 계층 보안(TLS) 채널을 통해 이루어집니다.

  • etcd CA는 API 서버에서 etcd 복제본으로의 통신과 etcd 복제본 간 트래픽도 보호합니다. 이 CA는 자체 서명됩니다.
  • 사용자 클러스터 CA는 API 서버와 모든 내부 Kubernetes API 클라이언트(kubelet, 컨트롤러, 스케줄러) 간의 통신을 보호합니다. 이 CA는 KMS로 암호화됩니다.
  • 관리 서비스 CA는 AWS KMS로 암호화됩니다. anthos-gke init를 실행하고 Terraform 작업공간에 저장하면 생성됩니다. terraform apply를 사용하여 관리 서비스를 만들면 CA 키가 AWS EC2 사용자 데이터로 전달되고 클러스터가 시작될 때 AWS KMS에서 복호화됩니다.

관리형 서비스의 경우 제어 영역 키는 제어 영역 [nodes]{:.external}에 저장됩니다. 사용자 클러스터의 경우 키는 관리 서비스의 제어 영역에 Kubernetes 보안 비밀로 저장됩니다.

GKE on AWS의 클러스터 인증은 인증서와 서비스 계정 Bearer 토큰에 의해 처리됩니다. 관리자는 관리 서비스에 대한 관리자 인증서를 사용하여 제어 영역에 인증합니다(초기 역할 binding 생성 또는 긴급 목적).

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

  • API 서버, 제어 영역, 노드의 경우 GKE on AWS는 업그레이드할 때마다 TLS 인증서를 순환합니다.
  • 수동으로 보안 사용자 인증 정보를 순환할 수도 있습니다.

노드 보안

GKE on AWS는 AWS EC2 인스턴스의 노드 풀에 워크로드를 배포합니다. 다음 섹션에서는 GKE on AWS에서 노드 수준 보안 기능을 사용하는 방법을 설명합니다.

Ubuntu

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

  • 최적화된 패키지 세트
  • Google Cloud 맞춤형 Linux 커널
  • 제한된 사용자 계정 및 중지된 루트 로그인

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

노드 업그레이드

정기적으로 노드를 업그레이드해야 합니다. 때때로 컨테이너 런타임, Kubernetes 자체 또는 노드 운영체제의 보안 문제로 인해 노드를 긴급히 업그레이드해야 하는 경우가 있습니다. 사용자 클러스터를 업그레이드하면 각 노드의 소프트웨어가 최신 버전으로 업그레이드됩니다. 또한 노드를 업그레이드하면 암호화 사용자 인증 정보가 순환됩니다.

워크로드 보안

사용자는 Kubernetes를 통해 컨테이너 기반 워크로드를 신속하게 프로비저닝, 확장, 업데이트할 수 있습니다. 이 섹션에서는 클러스터 및 Google Cloud 서비스에서 컨테이너를 실행할 때 발생하는 부작용을 제한하기 위해 사용할 수 있는 방법을 설명합니다.

포드 컨테이너 프로세스 권한 제한

클러스터 보안을 위해서는 컨테이너화된 프로세스의 권한을 제한하는 것이 중요합니다. 포드 및 컨테이너의 보안 컨텍스트를 사용하여 보안 관련 옵션을 설정할 수 있습니다. 이 설정을 사용하면 다음과 같은 프로세스의 보안 설정을 변경할 수 있습니다.

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

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

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

다음 단계