Kubernetes의 개발 속도로 인해 종종 새로운 보안 기능을 사용하게 됩니다. 이 페이지에서는 GKE On-Prem 클러스터 강화하기 위한 최신 가이드를 구현하는 방법을 안내합니다.
이 가이드에서는 클러스터 생성 시 조치가 필요한 고가치 보안 완화 방법을 우선합니다. 중요도가 낮은 기능, 기본 설정에 따른 보안, 클러스터 생성 후 사용 설정 가능한 기능은 뒷부분에서 설명합니다. 보안 주제의 일반적인 개요는 보안을 참조하세요.
vSphere VM 암호화
GKE On-Prem 클러스터 노드는 vSphere 클러스터의 가상 머신(VM)에서 실행됩니다. VMware vSphere 보안 안내 및 VM 암호화 권장사항 안내를 따르세요.
지체 없는 인프라 업그레이드
Kubernetes에는 새로운 보안 기능과 보안 패치가 자주 제공됩니다. 보안 패치에 대한 자세한 내용은 GKE On-Prem 보안 게시판을 참조하세요.
개발자는 GKE On-Prem 클러스터를 최신 상태로 유지해야 합니다. 각 출시 버전의 출시 노트 계획을 검토하여 매월 새로운 패치 출시 버전과 3개월마다 부 버전으로 업데이트하세요. 클러스터를 업그레이드하는 방법 알아보기
또한 vSphere 인프라를 업그레이드하고 보호해야 합니다.
- 가상 머신을 신속하게 패치하고 업그레이드하기 위한 프로세스를 설정하세요.
- 최신 VMware 보안 권장사항을 확인하세요.
- 호스트에 패치 적용의 안내를 따르세요.
OpenID Connect 구성
클러스터에 사용자 인증을 구성하려면 OpenID Connect(OIDC)를 사용합니다.
역할 기반 액세스 제어(RBAC)를 통해 액세스 권한을 부여할 때 OIDC 그룹도 활용해야 합니다. 이렇게 하면 사용자가 역할을 변경할 때 RBAC 구성을 수동으로 업데이트할 필요가 없습니다.
Google Cloud 서비스 계정에 최소 권한 원칙 사용
GKE On-Prem에는 Google Cloud 서비스 계정 4개가 필요합니다.
- GKE On-Prem 소프트웨어에 액세스하기 위해 허용 목록에 포함된 서비스 계정. Anthos를 구매할 때 이 계정을 만듭니다.
- Connect에서 GKE On-Prem 클러스터를 Google Cloud에 등록하는 데 사용할 등록 서비스 계정
- Connect에서 GKE On-Prem 클러스터와 Google Cloud 간의 연결을 설정하는 데 사용할 연결 서비스 계정
- Cloud Logging에서 사용할 클러스터 로그를 수집하기 위한 Cloud Logging 서비스 계정
설치하는 동안 이러한 서비스 계정에 ID 및 액세스 관리 역할을 결합합니다. 이러한 역할은 프로젝트 내의 특정 권한을 서비스 계정에 부여합니다. 서비스 계정은 최소 권한 원칙을 사용하여 구성해야 합니다. 서비스 계정의 각 역할을 수행하는 데 필요한 권한만 부여하세요.
Kubernetes 네임스페이스 및 RBAC를 사용하여 액세스 제한
팀에 Kubernetes에 대한 최소 액세스 권한을 부여하려면 Kubernetes 네임스페이스 또는 환경별 클러스터를 만듭니다. 책임성 및 지불 거절과 관련하여 각 네임스페이스에 비용 센터와 적절한 라벨을 지정합니다. 특히 프로덕션 환경에서 애플리케이션을 배포하고 관리하는 데 필요한 네임스페이스의 액세스 수준을 개발자에게만 제공합니다.
사용자가 클러스터에 수행해야 하는 작업을 매핑하고 각 작업을 수행하는 데 필요한 권한을 정의합니다. 클러스터 수준 및 네임스페이스 수준의 권한을 부여하려면 Kubernetes RBAC를 사용합니다.
GKE On-Prem을 설치하는 데 사용되는 Google Cloud 서비스 계정의 권한 외에 IAM은 GKE On-Prem 클러스터에 적용되지 않습니다.
클러스터 탐색 RBAC 권한 제한
기본적으로 Kubernetes는 CustomResourceDefinitions의 항목을 포함한 클러스터의 API 정보에 대한 광범위한 액세스 권한을 부여하는 방임적인 discovery ClusterRoleBindings 집합으로 클러스터를 시작합니다. Kubernetes 1.14에서는 이러한 권한이 축소되어 GKE On-Prem 버전 1.2부터 사용할 수 있습니다. 액세스를 제한해야 하는 경우 온프렘 방화벽을 적절하게 구성하는 것이 좋습니다.
보안 비밀 관리
etcd에 저장된 Kubernetes 보안 비밀과 같은 민감한 정보를 보호하기 위해 GKE On-Prem 클러스터와 통합된 보안 비밀 관리자를 구성합니다.
여러 환경에서 워크로드를 실행하는 경우 Google Kubernetes Engine과 GKE On-Prem을 모두 지원하는 솔루션을 선호할 수 있습니다. HashiCorp Vault와 같은 외부 보안 비밀 관리자를 사용하려면 GKE On-Prem 클러스터를 만들기 전에 설정해야 합니다.
보안 비밀 관리에는 여러 가지 옵션이 있습니다.
- Kubernetes 보안 비밀은 기본적으로 GKE On-Prem에서 사용할 수 있습니다. 앞에서 설명한 것처럼 클러스터는 VM에 vSphere 암호화를 사용하여 보안 비밀에 대한 기본적인 저장 데이터 암호화 보호 기능을 제공합니다. 보안 비밀은 기본적으로 더 이상 암호화되지 않습니다. 이러한 보안 비밀을 애플리케이션 레이어에서 암호화하려면 EncryptionConfig를 수정하고 키 관리 서비스 플러그인을 사용하면 됩니다.
- HashiCorp Vault와 같은 외부 보안 비밀 관리자를 사용할 수 있습니다. Kubernetes 서비스 계정 또는 Google Cloud 서비스 계정을 사용하여 HashiCorp에 인증할 수 있습니다.
제어 영역 및 노드에 대한 네트워크 액세스 제한
클러스터 제어 영역과 노드의 인터넷 노출을 제한해야 합니다. 클러스터를 만든 후에는 이러한 선택 항목을 변경할 수 없습니다.
기본적으로 GKE On-Prem 클러스터 노드는 RFC 1918 주소를 사용하여 생성되며 이를 변경하면 안 됩니다. 제어 영역에 대한 액세스를 제한하려면 온프렘 네트워크에 방화벽 규칙을 구현해야 합니다.
네트워크 정책을 사용하여 pod 간 트래픽 제한
기본적으로 GKE On-Prem 클러스터의 모든 서비스는 서로 통신할 수 있습니다. 워크로드의 필요에 따라 서비스 간 통신을 제어해야 합니다.
서비스에 대한 네트워크 액세스를 제한하면 클러스터 내에서 공격자의 측면 이동이 더 어려워지고 실수나 고의적인 서비스 거부로부터 서비스를 보호할 수 있습니다. 트래픽을 제어하는 두 가지 권장 방법은 다음과 같습니다.
- 애플리케이션 엔드포인트에 대한 L7 트래픽을 제어하려면 Istio를 사용합니다. 부하 분산, 서비스 승인, 제한, 할당량, 측정항목에 관심이 있다면 이 옵션을 선택하세요.
- pod 간 L4 트래픽을 제어하려면 Kubernetes 네트워크 정책을 사용합니다. Kubernetes에서 제공하는 기본 액세스 제어 기능을 찾고 있는 경우 이 옵션을 선택합니다.
GKE On-Prem 클러스터를 만든 후 Istio 및 Kubernetes 네트워크 정책을 모두 사용 설정할 수 있습니다. 필요한 경우 함께 사용해도 됩니다.
Anthos Config Management 정책 컨트롤러 사용
Kubernetes 허용 컨트롤러는 Kubernetes 클러스터 사용 방법을 제어하고 적용하는 플러그인입니다. Kubernetes 고급 보안 기능을 사용하려면 허용 컨트롤러를 사용 설정해야 합니다. 허용 컨트롤러는 클러스터를 강화하기 위한 심층 방어 방식에서 중요한 요소입니다.
Anthos Config Management의 정책 컨트롤러를 사용하는 것이 가장 좋습니다. 정책 컨트롤러는 OPA 제약조건 프레임워크를 사용하여 CRD로 정책을 설명하고 적용합니다. 클러스터에 적용할 제약조건은 클러스터에 배포되는 제약조건 템플릿에서 정의됩니다.
클러스터 구성 모니터링
클러스터 구성을 감사하여 정의된 설정과의 편차를 확인해야 합니다. 이러한 구성을 자동으로 확인하려면 배포된 위치와 관계없이 GKE On-Prem 클러스터에서 작동하는 솔루션을 사용해야 합니다. Anthos 파트너를 참조하세요.
기존 클라이언트 인증 방법 사용 안 함(기본값)
Kubernetes API 서버에 인증하는 방법에는 몇 가지가 있습니다. 권장되는 인증 메커니즘은 OIDC입니다. 기본 인증은 기본적으로 사용 중지되어 있습니다. 인증에 x509 인증서를 사용하지 마세요.
Cloud Logging 사용(기본값)
운영 오버헤드를 줄이고 로그의 통합 보기를 유지하려면 클러스터 배포 위치와 상관없이 일관성 있는 로깅 전략을 구현합니다. GKE On-Prem은 기본적으로 Google Cloud의 작업 제품군과 통합됩니다. 설치 중에 GKE On-Prem 구성 파일에 stackdriver 사양을 입력하여 Google Cloud의 작업 제품군을 사용 설정해야 합니다.
모든 GKE On-Prem 클러스터에는 기본적으로 Kubernetes 감사 로깅이 사용 설정되어 있습니다. 감사 로깅은 Kubernetes API 서버로 전송된 호출을 시간순으로 기록합니다. 감사 로그 항목은 의심스러운 API 요청을 조사하고, 통계를 수집하고, 원치 않는 API 호출에 대한 모니터링 알림을 만드는 데 유용합니다.
GKE On-Prem 클러스터는 Kubernetes 감사 로깅을 Google Cloud 감사 로그 및 Cloud Logging과 통합합니다. GKE On-Prem은 Logging에서 자체 로깅 시스템으로 라우팅할 수도 있습니다.
Google Cloud의 작업 제품군은 클러스터에서 로그를 수집하고 집계합니다. Google Cloud의 작업 제품군을 사용 설정하면 Google에서 보다 우수한 지원을 받을 수 있습니다. 자세한 내용은 로깅 및 모니터링을 참조하세요.
Kubernetes 대시보드 사용 안 함(기본값)
Kubernetes 대시보드는 상위 권한이 있는 Kubernetes 서비스 계정의 지원으로 Kubernetes에 대한 여러 가지 강력한 공격에 악용되었습니다. Google Cloud Console은 GKE On-Prem에 권장되는 웹 인터페이스입니다. 동일한 기능을 대부분 제공하며 승격된 권한 없이 IAM 및 Kubernetes RBAC를 지원하고 멀티 클러스터 관리와 같은 Anthos 기능을 제공합니다.
Kubernetes 대시보드는 GKE On-Prem에 포함되지 않습니다.
속성 기반 액세스 제어 사용 중지(기본값)
Kubernetes에서는 RBAC를 사용하여 클러스터와 네임스페이스 수준의 리소스에 권한을 부여합니다. RBAC를 사용하면 권한 집합이 포함된 규칙을 사용하여 역할을 정의할 수 있습니다.
기본적으로 속성 기반 액세스 제어(ABAC)는 GKE On-Prem 클러스터에서 사용 중지되며 사용 설정하지 않아야 합니다.