이 페이지에서는 GKE를 실행하는 데 권장되는 Google Kubernetes Engine(GKE) Autopilot의 보안 기능, 구성, 설정을 설명합니다.
이 페이지의 대상
이 페이지는 Google에서 특별히 Autopilot 클러스터에 적용하는 보안 제한사항과 Autopilot에서 사용할 수 있는 보안 기능을 이해하려는 보안 관리자를 위해 작성되었습니다.
모든 GKE 클러스터, 네트워크 구성, 워크로드에 적용되는 강화 옵션, 조치, 권장사항을 설명하는 GKE 보안 개요도 일어야 합니다.
Autopilot의 보안 조치
Autopilot 클러스터는 기본적으로 보안 개요 및 클러스터 보안 강화의 여러 권장사항을 포함한 보안 권장사항과 설정을 사용 설정하고 적용합니다.
사용 사례에 따라 권장되는 리소스를 확인하려면 사용 사례별 보안 리소스로 건너뜁니다. 다음 섹션에서는 Autopilot에서 자동으로 적용하는 보안 정책을 설명합니다.
Autopilot 및 Kubernetes 포드 보안 표준
Kubernetes 프로젝트에는 다음 정책을 정의하는 포드 보안 표준이라는 보안 가이드라인이 있습니다.
- 권한 있음: 액세스 제한이 없습니다. Autopilot에서는 사용되지 않습니다.
- 기준: 알려진 권한 에스컬레이션 경로를 방지합니다. 대부분의 워크로드를 큰 변경 없이 실행할 수 있습니다.
- 제한: 최고 수준의 보안입니다. 대부분의 워크로드가 상당한 변경이 필요합니다.
Autopilot 모드에서 GKE는 GKE Warden이라는 커스텀 허용 컨트롤러를 사용하여 포드 보안 제약 조건을 적용합니다. Google에서는 사용성을 위해 일부 수정사항을 적용하여 포드 보안 표준의 기준 수준에 있는 모든 권장사항을 포함하는 기본 보안 정책을 적용합니다. 또한 Autopilot의 기본 GKE Warden 허용 정책은 포드 보안 표준의 제한 수준에서 많은 제약 조건을 적용하지만 대부분의 워크로드 실행을 차단하는 제한을 방지합니다.
전체 제한 정책을 준수하기 위해 추가 제한사항을 적용해야 하는 경우에는 특정 네임스페이스에서 선택적으로 PodSecurity 허용 컨트롤러를 사용하면 됩니다.
다음 표에서는 기본 Autopilot GKE Warden 정책의 제어 기능이 포드 보안 표준 기준 수준 및 제한 수준의 제어 기능과 어떻게 다른지 설명합니다. 이 표의 각 제어 기능에 대한 설명은 포드 보안 표준의 해당 항목을 참조하세요.
규정 준수를 평가할 때는 제약조건이 자체 워크로드에 적용되는 방식을 고려했습니다. 작동하려면 특정 권한이 필요한 인증된 Google Cloud 파트너 워크로드 및 시스템 워크로드는 제외됩니다.
| 제어 | 기준 정책을 준수함 | 제한 정책을 준수함 | 추가 정보 |
|---|---|---|---|
| HostProcess | Autopilot이 HostProcess를 차단합니다. | ||
| 호스트 네임스페이스 | Autopilot이 호스트 네임스페이스를 차단합니다. 인증된 파트너의 일부 컨테이너는 호스트 네임스페이스를 사용하도록 허용됩니다. | ||
| 높은 권한을 가진 컨테이너 | Autopilot은 기본적으로 권한이 있는 컨테이너를 차단합니다. Autopilot은 보안 및 모니터링 도구 실행과 같은 목적을 위해 인증된 파트너의 권한이 있는 컨테이너를 허용합니다. | ||
| Linux 기능 | Autopilot 워크로드는 기본적으로 기준 포드 보안 표준에 지정된 기능에만 액세스할 수 있습니다. 다음 기능을 수동으로 사용 설정할 수 있습니다.
또한 Autopilot을 사용하면 일부 인증된 파트너 워크로드에서 삭제된 기능을 설정할 수 있습니다. |
||
| HostPath 볼륨 | 일부 준수함 | 일부 준수함 | Autopilot을 사용하면 컨테이너에서 디버깅을 위해 /var/log에 대한 읽기 전용 액세스 권한을 요청할 수 있지만 다른 모든 읽기 또는 쓰기 액세스 권한은 거부됩니다. |
| HostPorts | 특정 호스트 포트의 설정은 허용되지 않으므로 일부 예약 문제가 완화되고 우발적 또는 고의적인 서비스의 직접적 네트워크 노출을 방지합니다. 알려진 범위에서 무작위 호스트 포트 할당을 수동으로 설정하여 게임 서버와 같은 직접 연결 네트워킹 애플리케이션을 지원할 수 있습니다. | ||
| AppArmor | AppArmor docker-기본 보안 프로필은 Container-Optimized OS에 자동으로 적용됩니다. | ||
| SELinux | AppArmor가 이미 적용되었기 때문에 SELinux가 적용되지 않습니다. 또한 SELinux는 포드 보안 표준의 필수 항목이 아닙니다. | ||
/proc 마운트 유형 |
GKE는 ProcMountType 기능 플래그를 설정하지 않습니다.
Pod securityContext가 procMount를 '마스크되지 않음'으로 설정하면 GKE는 자동으로 '기본값'으로 재정의합니다. |
||
| seccomp 프로필 | Autopilot은 RuntimeDefault seccomp 프로필을 모든 워크로드에 적용합니다. 포드 사양에서 프로필을 Unconfined로 설정하여 특정 워크로드에 대해 이 설정을 수동으로 재정의할 수 있습니다. |
||
| sysctls | GKE는 --allowed-unsafe-sysctls kubelet 플래그를 설정하지 않으므로 안전하지 않은 sysctl을 사용하는 포드는 예약에 실패합니다. 추가 보호를 위해 2023년 7월 11일부터 새 1.27 이상 클러스터에 securityContext 설정을 적용하고 안전하지 않은 sysctl을 사용하는 포드를 거부하는 정책 규칙도 포함됩니다. | ||
| 볼륨 유형 | Autopilot은 디버깅을 위한 /var/log에 대한 읽기 전용 액세스 권한이 있는 HostPath 볼륨, Compute Engine 영구 디스크에 대한 gcePersistentDisk, 네트워크 파일 시스템 볼륨에 대한 nfs가 추가된 제한 정책의 볼륨 유형만 허용합니다. |
||
| 권한 에스컬레이션 | 이 설정은 루트로 실행되지 않는 컨테이너에만 보호를 제공합니다. 업계 설문조사에 따르면 컨테이너의 76%가 루트로 실행되는 것으로 나타났습니다. 따라서 Autopilot에서는 대부분의 워크로드를 지원하기 위해 루트로 실행하는 것을 허용합니다. 이 설정은 Kubernetes 루트 기능 처리 결함을 해결하기 위해 현재 파일 시스템 기능 사용을 허용하여 루트가 아닌 워크로드로 권한을 해제하는 데에도 유용합니다. | ||
| 루트가 아닌 상태로 실행 | 업계 설문조사에 따르면 컨테이너의 76%가 루트로 실행되는 것으로 나타났습니다. 따라서 Autopilot에서는 대부분의 워크로드를 지원하기 위해 루트로 실행하는 것을 허용합니다. | ||
| 루트가 아닌 사용자로 실행 | 컨테이너는 runAsUser를 0으로 설정할 수 있습니다.
업계 설문조사에 따르면 컨테이너의 76%가 루트로 실행되는 것으로 나타났습니다. 따라서 Autopilot에서는 대부분의 워크로드를 지원하기 위해 루트로 실행하는 것을 허용합니다. |
기본 제공 보안 구성
Google은 업계 권장사항과 전문 지식을 기반으로 Autopilot 클러스터에 여러 기본 제공 보안 설정을 적용합니다. 다음 표에서는 Autopilot에서 자동으로 적용하는 몇 가지 보안 구성을 설명합니다.
| 구성 | 설명 |
|---|---|
| 호스트 옵션 |
|
| Linux 기능 | 다음 Linux 기능을 사용할 수 있습니다. "SETPCAP", "MKNOD", "AUDIT_WRITE", "CHOWN", "DAC_OVERRIDE", "FOWNER", "FSETID", "KILL", "SETGID", "SETUID", "NET_BIND_SERVICE", "SYS_CHROOT", "SETFCAP", "SYS_PTRACE" 다음 기능을 수동으로 사용 설정할 수도 있습니다.
1.21 이전 GKE 버전에서는 |
| 높은 권한을 가진 컨테이너 | Google Cloud 파트너가 컨테이너를 배포하지 않는 한 컨테이너를 권한 있음 모드로 실행할 수 없습니다. 권한이 있는 컨테이너는 kubelet 변경과 같은 기본 노드를 변경할 수 있습니다. 이러한 액세스 권한은 포드 손상 영향을 증가시킬 수 있습니다. |
| GKE 관리형 네임스페이스 | 보안 조치로 Autopilot은 kube-system과 같은 GKE 관리 네임스페이스에 워크로드 배포를 허용하지 않습니다. |
| 컨테이너 격리 | Autopilot은 컨테이너 이스케이프 취약점의 영향을 제한하기 위해 컨테이너에 다음과 같은 제한사항을 적용합니다. Linux 기능 및 커널 보안
|
| 포드 수준 보안 정책 시행 | Autopilot은 PodSecurity 허용 컨트롤러, 게이트키퍼, 정책 컨트롤러와 포드 수준 보안 정책 시행 메커니즘을 지원합니다.
그러나 이 페이지에 설명된 기본 제공 보안 구성이 이미 요구사항을 충족하는 경우에는 이러한 구성을 사용하지 않아도 됩니다. |
| 노드에 SSH 연결 | Autopilot은 노드에 대한 SSH 액세스를 차단합니다. GKE는 노드 상태와 노드에서 실행되는 모든 Kubernetes 구성요소 등 노드의 모든 운영 측면을 처리합니다. 여전히 Kubernetes |
| 사용자 가장 | GKE 버전 1.22.4-gke.1501 이상은 모든 사용자 정의 사용자 및 그룹에 대한 사용자 가장을 지원합니다. kube-apiserver 사용자 및 system:masters 그룹과 같은 시스템 사용자 및 그룹은 가장할 수 없습니다. |
| 동적 허용 웹훅 변형 | Autopilot은 또한 Autopilot은 다음 리소스 중 하나 이상과 해당 리소스의 하위 리소스를 지정하는 웹훅을 거부합니다. - group: "" resource: nodes - group: "" resource: persistentVolumes - group: certificates.k8s.io resource: certificatesigningrequests - group: authentication.k8s.io resource: tokenreviews 리소스 또는 그룹에 |
| ValidatingAdmissionPolicies | Autopilot은 또한 Autopilot은 다음 리소스 중 하나 이상과 해당 리소스의 하위 리소스를 지정하는 - group: "" resource: nodes - group: "" resource: persistentVolumes - group: certificates.k8s.io resource: certificatesigningrequests - group: authentication.k8s.io resource: tokenreviews 리소스 또는 그룹에 |
| 인증서 서명 요청 | Autopilot에서 CertificateSigningRequests를 만들어 클러스터 인증 기관에서 서명된 인증서를 만들 수 있습니다. Autopilot은 시스템 구성요소와의 간섭을 방지하기 위해 시스템 그룹, 시스템 에이전트 또는 Google 관리형 IAM 서비스 에이전트와 같은 알려진 권한 있는 ID에 대한 CertificateSigningRequests를 거부합니다. |
| GKE 보안 기능 | Autopilot 클러스터는 권장되는 GKE 보안 기능을 사용 설정합니다. 사용 설정된 보안 기능 및 선택적 보안 기능의 목록은 Autopilot의 보안 기능을 참조하세요. |
| 노드 운영체제 | Autopilot 클러스터는 containerd를 노드 운영체제로 포함한 Container-Optimized OS를 사용합니다. Google에서 Container-Optimized OS를 만들고 관리합니다. |
| GKE 버전 업그레이드 | Autopilot 클러스터는 생성 시 GKE 출시 채널에 등록되며 자동 업그레이드는 항상 사용 설정됩니다. Google은 시간 경과에 따라 컨트롤 플레인과 노드를 출시 채널의 최신 버전으로 자동 업그레이드합니다. |
Autopilot의 보안 경계
Autopilot은 Kubernetes API에 대한 액세스 권한을 제공하지만 권한이 있는 포드와 같은 일부 높은 권한이 있는 Kubernetes 기능을 사용할 수 있는 권한을 삭제합니다. 목표는 노드 가상 머신(VM)에 액세스, 수정 또는 직접 제어하는 기능을 제한하는 것입니다. Autopilot은 이러한 제한을 구현하여 워크로드가 노드 VM에 대한 낮은 수준의 액세스 권한을 갖지 못하도록 제한하여 Google Cloud가 노드의 전체 관리 및 포드 수준 SLA를 제공할 수 있도록 합니다.
Google의 목표는 노드 VM에 대한 의도하지 않은 액세스를 방지하는 것입니다. Google은 Google 취약성 발견 보상 프로그램(VRP)을 통해 해당 취지의 제출을 접수하며 Google VRP 보상 패널 재량에 따라 보고서를 제공합니다.
기본적으로 클러스터 관리자와 같이 권한이 있는 사용자는 GKE 클러스터를 완전히 제어할 수 있습니다. 보안 권장사항에 따라 강력한 GKE 또는 Kubernetes 권한을 광범위하게 부여하지 않고 대신 멀티테넌시 가이드의 설명대로 가능하면 네임스페이스 관리자 위임을 사용하는 것이 좋습니다.
Autopilot은 단독으로 사용하도록 프로젝트의 단일 테넌트 VM을 프로비저닝합니다. 각 개별 VM에서 Autopilot 워크로드는 보안이 강화된 커널을 공유하면서 함께 실행될 수 있습니다. 공유 커널은 단일 보안 경계를 나타내므로 고위험 또는 신뢰할 수 없는 워크로드와 같이 강력한 격리가 필요한 경우 워크로드를 GKE Sandbox 포드에서 실행하여 멀티 레이어 보안 보호를 제공하는 것이 좋습니다.
사용 사례 기반 보안 리소스
다음 섹션에서는 사용 사례에 따라 Autopilot 클러스터 보안을 계획, 구현, 관리하기 위한 링크와 권장사항을 제공합니다.
클러스터 보안 계획
| 사용 사례 | 리소스 |
|---|---|
| 플랫폼으로서 GKE가 보안에 접근하는 방식 이해 |
|
| 환경 강화를 위한 자신의 역할 이해 | 공유 책임 모델을 알아봅니다. |
| 보안 강화 조치 및 이슈 대응에 대한 Google 권장사항 보기 |
|
| GKE에서 감사 로깅을 구현하는 방법 이해 |
|
인증 및 승인
Autopilot 클러스터를 설정한 후 Kubernetes API 또는 Google Cloud API와 같은 리소스를 사용하려면 사용자와 애플리케이션을 인증해야 할 수 있습니다.
| 사용 사례 | 리소스 |
|---|---|
| 클러스터 API 서버에 사용자 또는 애플리케이션 인증 | |
| Google Cloud API 및 서비스에 애플리케이션 인증 | Autopilot 클러스터를 사용하면 IAM 서비스 계정 역할을 하도록 Kubernetes 서비스 계정을 구성하여 GKE용 워크로드 아이덴티티 제휴를 사용하여 Google Cloud API에 대한 워크로드를 안전하게 인증할 수 있습니다. 자세한 내용은 GKE용 워크로드 아이덴티티 제휴를 사용하도록 애플리케이션 구성을 참조하세요. |
| 프로젝트 수준에서 작업 승인 | 프로젝트 수준에서 클러스터 전반의 작업을 승인하려면 IAM을 사용합니다. IAM 역할과 권한을 사용하여 특정 GKE 및 Kubernetes API 리소스에 대한 액세스 권한을 부여하거나 거부할 수 있습니다. 자세한 내용은 IAM 정책 만들기를 참조하세요. |
| 클러스터 수준에서 작업 승인 | 특정 클러스터의 Kubernetes API 리소스에 대한 작업을 승인하려면 기본 제공되는 Kubernetes 역할 기반 액세스 제어(RBAC) 메커니즘을 사용합니다. 자세한 내용은 RBAC를 사용한 클러스터의 작업 승인을 참조하세요. |
| 조직 수준에서 작업 승인 | Google Cloud 조직 정책 서비스를 사용하여 Google Cloud 조직의 GKE 리소스에 대한 특정 작업에 제약조건을 적용할 수 있습니다. 자세한 내용은 커스텀 조직 정책을 사용하여 GKE 리소스에 대한 작업 제한을 참조하세요. |
클러스터 및 워크로드 강화
사전 구성된 Autopilot 조치 이상으로 특별한 격리 또는 강화 요구사항이 있는 경우 다음 리소스를 고려하세요.
| 사용 사례 | 리소스 |
|---|---|
| 클러스터 엔드포인트에 대한 공개 액세스 제한 | Autopilot 클러스터를 비공개 클러스터로 만들어 클러스터 컨트롤 플레인의 공개 IP 주소를 중지합니다. 자세한 내용은 비공개 클러스터를 참조하세요. |
| 특정 네트워크에 대한 클러스터 액세스 제한 | 컨트롤 플레인 승인된 네트워크를 사용하여 클러스터에 액세스할 수 있는 IP 주소 범위를 지정합니다. |
| 클러스터 외부에 민감한 정보 저장 | 버전 관리가 사용 설정된 암호화된 외부 저장소 제공업체에 민감한 정보를 저장하는 것은 일반적인 규정 준수 요구사항이자 권장사항입니다. Secret Manager를 사용하여 데이터를 저장하고 GKE용 워크로드 아이덴티티 제휴를 사용하여 Autopilot 클러스터에서 데이터에 액세스합니다. 자세한 내용은 GKE용 워크로드 아이덴티티 제휴를 사용하여 GKE 클러스터 외부에 저장된 보안 비밀에 액세스를 참조하세요. |
| 클러스터에 배포하기 전에 컨테이너 이미지 확인 | 배포 시 Binary Authorization을 사용하여 포드 매니페스트에서 참조되는 컨테이너 이미지의 무결성을 확인합니다. 자세한 내용은 Binary Authorization을 사용하여 배포 시 컨테이너 이미지 확인을 참조하세요. |
보안 상황 모니터링
클러스터를 설정하고 워크로드를 배포한 후에는 클러스터 보안 상황을 관측할 수 있도록 모니터링 및 로깅을 설정하고 구성해야 합니다. 다음 작업을 모두 실행하는 것이 좋습니다.
- GKE 보안 상태 대시보드에 클러스터를 등록하여 컨테이너 운영체제 패키지의 문제가 있는 보안 구성 또는 취약점과 같은 문제를 감사하고 조치 가능한 완화 방법을 얻습니다.
- 클러스터 알림을 사용하여 새로운 보안 게시판 및 업그레이드 이벤트에 대한 알림을 받으세요.
- Cloud Monitoring의 GKE 대시보드 또는 GKE의 관측 가능성 탭을 사용하여 클러스터를 관찰합니다.
- Cloud Logging에서 GKE 감사 로그를 확인하고 관리하는 방법을 알아보세요.
다음 단계
- GKE 보안 개요읽기
- GKE 강화 가이드 읽기
- 보안 게시판 및 출시 노트 구독