이 페이지에서는 GKE 보안 상황 대시보드에서 GKE Threat Detection을 사용하여 적격한 GKE 클러스터에서 활성 위협을 스캔하는 방법을 설명합니다. GKE 보안 상황 대시보드를 사용하면 적격한 GKE 클러스터에서 다양한 스캔 및 감사 기능을 사용 설정하고 보안 문제를 해결하는 데 도움이 되는 실행 가능한 권장사항을 표시할 수 있습니다. 이 페이지에서는 GKE Threat Detection의 작동 방식, 사용하는 사전 정의된 규칙, 제한사항, 사용 설정 방법을 설명합니다.
이 페이지는 자체 조직의 취약점 감지 솔루션을 구현하려는 보안 전문가를 대상으로 합니다. Google 콘텐츠에서 참조하는 일반적인 역할 및 예시 작업에 대해 자세히 알아보려면 Google Cloud 일반 GKE Enterprise 사용자 역할 및 작업을 참고하세요.
이 페이지를 읽기 전에 보안 상태 대시보드의 일반적인 개요를 숙지해야 합니다. GKE Threat Detection은 보안 상황 대시보드의 기능입니다.
작동 방식
GKE Threat Detection은 GKE Enterprise 사용자에게 제공되는 고급 GKE 보안 상황 대시보드 기능입니다. GKE 클러스터가 Fleet에 등록되면 GKE Threat Detection에서 클러스터 및 워크로드 위협에 대한 사전 정의된 규칙 집합에 따라 Cloud Logging의 GKE 감사 로그를 평가합니다. 위협이 발견되면 GKE 보안 상황 대시보드에 위협에 대한 설명, 잠재적 영향, 위협 완화를 위한 권장 조치와 함께 발견 항목이 표시됩니다.
Fleet에 등록된 모든 GKE 클러스터는 활성 위협이 있는지 지속적으로 스캔합니다. Google은 MITRE ATT&CK® 전략을 사용하여 감지된 위협을 분류합니다.
GKE Threat Detection은 Security Command Center Event Threat Detection 서비스를 기반으로 합니다. GKE 보안 상황 대시보드에서는 GKE에 적용되는 규칙의 하위 집합만 평가됩니다.
포함된 GKE 보안 상황 기능
GKE Threat Detection은 고급 등급의 Kubernetes 보안 상황 스캔과 함께 번들로 제공됩니다. 클러스터에서 GKE Threat Detection을 활성화하면 다음 스캔 기능도 활성화됩니다.
- 워크로드 구성 감사
- 보안 게시판 표시(미리보기)
광범위한 보안 전략의 일부로 사용
GKE Threat Detection은 환경에서 사용해야 하는 다양한 보안 관측 가능성 제품 중 하나입니다. 다양한 보안 문제에 대해 클러스터를 모니터링하도록 취약점 스캔과 같은 GKE 보안 상황 대시보드의 다른 기능을 사용하는 것이 좋습니다. 자세한 내용은 GKE 문서의 보안 상황 대시보드 정보를 참조하세요.
또한 클러스터 및 워크로드에서 클러스터 보안 강화의 보안 조치를 최대한 많이 구현하는 것이 좋습니다.
가격 책정
GKE Threat Detection은 GKE Enterprise를 통해 추가 비용 없이 제공됩니다.
사전 정의된 GKE Threat Detection 규칙
다음 표에서는 GKE Threat Detection이 GKE 감사 로그를 평가하는 평가 규칙을 설명합니다.
| 표시 이름 | API 이름 | 로그 소스 유형 | 설명 |
|---|---|---|---|
| 방어 회피: Breakglass 워크로드 배포 생성됨(미리보기) | BINARY_AUTHORIZATION_BREAKGLASS_WORKLOAD_CREATE |
Cloud 감사 로그: 관리자 활동 로그 |
break-glass 플래그를 사용해 Binary Authorization 설정을 재정의하여 배포된 워크로드 배포를 감지합니다. |
| 방어 회피: Breakglass 워크로드 배포 업데이트됨(미리보기) | BINARY_AUTHORIZATION_BREAKGLASS_WORKLOAD_UPDATE |
Cloud 감사 로그: 관리자 활동 로그 |
break-glass 플래그를 사용해 Binary Authorization 설정을 재정의하여 워크로드가 업데이트되면 감지합니다. |
| 탐색: 민감한 Kubernetes 객체 확인 가능 | GKE_CONTROL_PLANE_CAN_GET_SENSITIVE_OBJECT |
Cloud 감사 로그: GKE 데이터 액세스 로그 |
잠재적으로 악의적인 행위자가
|
| 권한 에스컬레이션: 민감한 Kubernetes RBAC 객체 변경 | GKE_CONTROL_PLANE_EDIT_SENSITIVE_RBAC_OBJECT |
Cloud 감사 로그: GKE 관리자 활동 로그 |
권한을 에스컬레이션하기 위해 잠재적인 악의적 행위자가 PUT 또는 PATCH 요청을 사용하여 민감한 cluster-admin 역할의 ClusterRole, RoleBinding 또는 ClusterRoleBinding 역할 기반 액세스 제어(RBAC) 객체를 수정하려고 시도했습니다. |
| 권한 에스컬레이션: 마스터 인증서에 대한 Kubernetes CSR 만들기 | GKE_CONTROL_PLANE_CSR_FOR_MASTER_CERT |
Cloud 감사 로그: GKE 관리자 활동 로그 |
잠재적인 악의적 행위자가 Kubernetes 마스터 인증서 서명 요청(CSR)을 만들고 cluster-admin 액세스 권한을 부여합니다. |
| 권한 에스컬레이션: 민감한 Kubernetes 바인딩 만들기 | GKE_CONTROL_PLANE_CREATE_SENSITIVE_BINDING |
Cloud 감사 로그: IAM 관리자 활동 감사 로그 |
권한을 에스컬레이션하기 위해 잠재적인 악의적 행위자가 cluster-admin 역할에 대해 새 RoleBinding 또는 ClusterRoleBinding 객체를 만들려고 시도했습니다. |
| 권한 에스컬레이션: 손상된 부트스트랩 사용자 인증 정보로 Kubernetes CSR 가져오기 | GKE_CONTROL_PLANE_GET_CSR_WITH_COMPROMISED_BOOTSTRAP_CREDENTIALS |
Cloud 감사 로그: GKE 데이터 액세스 로그 |
잠재적인 악의적 행위자가 손상된 부트스트랩 사용자 인증 정보를 사용하여 kubectl 명령어로 인증서 서명 요청(CSR)을 쿼리했습니다. |
| 권한 에스컬레이션: 권한이 있는 Kubernetes 컨테이너 실행 | GKE_CONTROL_PLANE_LAUNCH_PRIVILEGED_CONTAINER |
Cloud 감사 로그: GKE 관리자 활동 로그 |
잠재적으로 악의적인 행위자가 권한이 있는 컨테이너 또는 권한 에스컬레이션 기능이 있는 컨테이너를 포함하는 포드를 만들었습니다.
권한이 있는 컨테이너에는 |
| 사용자 인증 정보 액세스: Kubernetes 네임스페이스에서 보안 비밀 액세스됨 | SECRETS_ACCESSED_IN_KUBERNETES_NAMESPACE |
Cloud 감사 로그: GKE 데이터 액세스 로그 |
현재 Kubernetes 네임스페이스의 서비스 계정이 보안 비밀 또는 서비스 계정 토큰에 액세스하면 이를 감지합니다. |
| 초기 액세스: 익명 GKE 리소스가 인터넷에서 생성됨(미리보기) | GKE_RESOURCE_CREATED_ANONYMOUSLY_FROM_INTERNET |
Cloud 감사 로그: GKE 관리자 활동 로그 |
사실상 익명의 인터넷 사용자에서 리소스 생성 이벤트를 감지합니다. |
| 초기 액세스: GKE 리소스가 인터넷에서 익명으로 수정됨(미리보기) | GKE_RESOURCE_MODIFIED_ANONYMOUSLY_FROM_INTERNET |
Cloud 감사 로그: GKE 관리자 활동 로그 |
사실상 익명의 인터넷 사용자에서 리소스 조작 이벤트를 감지합니다. |
| 권한 에스컬레이션: 사실상 익명 사용자에게 GKE 클러스터 액세스 권한이 부여됨(미리보기) | GKE_ANONYMOUS_USERS_GRANTED_ACCESS |
Cloud 감사 로그: GKE 관리자 활동 로그 |
누군가 다음 사용자 또는 그룹 중 하나를 참조하는 RBAC 바인딩을 만들었습니다.
이러한 사용자 및 그룹은 사실상 익명이므로 RBAC 역할에 대한 역할 바인딩 또는 클러스터 역할 바인딩을 만들 때는 피해야 합니다. 바인딩이 필요한지 검토합니다. 바인딩이 필요하지 않으면 삭제합니다. |
| 실행: 의심스러운 실행 또는 시스템 포드에 연결(미리보기) | GKE_SUSPICIOUS_EXEC_ATTACH |
Cloud 감사 로그: GKE 관리자 활동 로그 |
누군가 exec 또는 attach 명령어를 사용하여 셸을 가져오거나 kube-system 네임스페이스에서 실행 중인 컨테이너에서 명령어를 실행했습니다.
이러한 메서드는 합법적인 디버깅 목적으로 사용되기도 합니다. 하지만 kube-system 네임스페이스는 Kubernetes에서 만든 시스템 객체용이며 예기치 않은 명령어 실행이나 셸 생성은 검토해야 합니다.
|
| 권한 에스컬레이션: 민감한 호스트 경로 마운트로 생성된 워크로드(미리보기) | GKE_SENSITIVE_HOSTPATH |
Cloud 감사 로그: GKE 관리자 활동 로그 |
누군가 호스트 노드의 파일 시스템에서 민감한 경로에 hostPath 볼륨 마운트를 포함하는 워크로드를 만들었습니다. 호스트 파일 시스템의 이러한 경로에 대한 액세스 권한은 노드에서 권한이 있거나 민감한 정보에 액세스하고 컨테이너 이스케이프 처리하는 데 사용될 수 있습니다. 가능하면 클러스터에서 hostPath 볼륨을 허용하지 마세요.
|
| 권한 에스컬레이션: shareProcessNamespace가 사용 설정된 워크로드(미리보기) | GKE_SHAREPROCESSNAMESPACE_POD |
Cloud 감사 로그: GKE 관리자 활동 로그 |
누군가 모든 컨테이너가 동일한 Linux 프로세스 네임스페이스를 공유할 수 있도록 shareProcessNamespace 옵션을 true로 설정하여 워크로드를 배포했습니다.
이렇게 하면 신뢰할 수 없거나 손상된 컨테이너가 다른 컨테이너에서 실행되는 프로세스의 환경 변수, 메모리, 기타 민감한 정보에 액세스하고 이를 제어하여 권한을 에스컬레이션할 수 있습니다.
|
| 권한 에스컬레이션: 권한이 있는 동사가 포함된 ClusterRole(미리보기) | GKE_CLUSTERROLE_PRIVILEGED_VERBS |
Cloud 감사 로그: GKE 관리자 활동 로그 |
누군가 bind, escalate 또는 impersonate 동사가 포함된 RBAC ClusterRole을 만들었습니다. 이러한 동사로 역할에 바인딩된 주체는 더 높은 권한을 가진 다른 사용자를 가장하거나, 추가 권한이 포함된 추가 Roles 또는 ClusterRoles에 바인딩하거나, 자체 ClusterRole 권한을 수정할 수 있습니다. 이로 인해 해당 주체가 클러스터 관리자 권한을 얻을 수 있게 될 수 있습니다.
|
| 권한 에스컬레이션: 권한이 있는 역할에 대한 ClusterRoleBinding(미리보기) | GKE_CRB_CLUSTERROLE_AGGREGATION_CONTROLLER |
Cloud 감사 로그: GKE 관리자 활동 로그 |
누군가 기본 system:controller:clusterrole-aggregation-controller ClusterRole을 참조하는 RBAC ClusterRoleBinding을 만들었습니다. 이 기본 ClusterRole에는 사용자가 자신의 역할 권한을 수정하여 권한 에스컬레이션을 허용하는 escalate 동사가 있습니다.
|
| 방어 회피: 인증서 서명 요청(CSR)이 수동으로 삭제됨(미리보기) | GKE_MANUALLY_DELETED_CSR |
Cloud 감사 로그: GKE 관리자 활동 로그 |
누군가 인증서 서명 요청(CSR)을 수동으로 삭제했습니다. CSR은 가비지 컬렉션 컨트롤러에 의해 자동으로 삭제되지만 악의적인 행위자가 감지를 회피하기 위해 CSR을 수동으로 삭제할 수 있습니다. 삭제된 CSR이 승인 및 발급된 인증서에 대한 것이면 잠재적인 악의적 행위자는 이제 클러스터에 액세스할 수 있는 추가 인증 방법을 갖게 됩니다. 인증서에 연결된 권한은 포함된 주체에 따라 다르지만 권한이 높을 수 있습니다. Kubernetes는 인증서 취소를 지원하지 않습니다. |
| 사용자 인증 정보 액세스: Kubernetes 인증서 서명 요청(CSR) 승인 시도 실패(미리보기) | GKE_APPROVE_CSR_FORBIDDEN |
Cloud 감사 로그: GKE 관리자 활동 로그 |
누군가 인증서 서명 요청(CSR)을 수동으로 승인하려고 했지만 실패했습니다. 클러스터 인증을 위한 인증서를 만드는 것은 공격자가 손상된 클러스터에 영구적으로 액세스하기 위해 흔히 사용하는 방법입니다. 인증서에 연결된 권한은 포함된 주체에 따라 다르지만 권한이 높을 수 있습니다. |
| 사용자 인증 정보 액세스: 수동으로 승인된 Kubernetes 인증서 서명 요청(CSR)(미리보기) | GKE_CSR_APPROVED |
Cloud 감사 로그: GKE 관리자 활동 로그 |
누군가 인증서 서명 요청(CSR)을 수동으로 승인했습니다. 클러스터 인증을 위한 인증서를 만드는 것은 공격자가 손상된 클러스터에 영구적으로 액세스하기 위해 흔히 사용하는 방법입니다. 인증서에 연결된 권한은 포함된 주체에 따라 다르지만 권한이 높을 수 있습니다. |
| 실행: 잠재적인 리버스 셸 인수로 생성된 Kubernetes 포드(미리보기) | GKE_REVERSE_SHELL_POD |
Cloud 감사 로그: GKE 관리자 활동 로그 |
누군가 일반적으로 리버스 셸과 연관된 명령어나 인수가 포함된 포드를 만들었습니다. 공격자는 리버스 셸을 사용하여 클러스터에 대한 초기 액세스를 확장 또는 유지하고 임의 명령어를 실행합니다. |
| 방어 회피: 잠재적인 Kubernetes 포드 가장(미리보기) | GKE_POD_MASQUERADING |
Cloud 감사 로그: GKE 관리자 활동 로그 |
누군가 GKE가 일반 클러스터 운영을 위해 만드는 기본 워크로드와 유사한 이름 지정 규칙으로 포드를 배포했습니다. 이러한 기법을 가장이라고 합니다. |
| 권한 에스컬레이션: 의심스러운 Kubernetes 컨테이너 이름 - 익스플로잇 및 이스케이프(미리보기) | GKE_SUSPICIOUS_EXPLOIT_POD |
Cloud 감사 로그: GKE 관리자 활동 로그 |
누군가 컨테이너 이스케이프에 사용되는 일반적인 도구와 유사한 이름 지정 규칙으로 포드를 배포했거나 클러스터에서 다른 공격을 실행했습니다. |
| 영향: 의심스러운 Kubernetes 컨테이너 이름 - 암호화폐 채굴(미리보기) | GKE_SUSPICIOUS_CRYPTOMINING_POD |
Cloud 감사 로그: GKE 관리자 활동 로그 |
누군가 일반적인 암호화폐 코인 채굴기와 유사한 이름 지정 규칙으로 포드를 배포했습니다. 클러스터에 대한 초기 액세스 권한을 얻은 공격자가 암호화폐 채굴에 클러스터 리소스를 사용하려는 시도일 수 있습니다. |
| 실행: 민감한 네임스페이스에서 워크로드가 트리거됨 (미리보기) | GKE_SENSITIVE_NAMESPACE_WORKLOAD_TRIGGERED |
Cloud 감사 로그: GKE 관리자 활동 로그 |
누군가 kube-system 또는 kube-public 네임스페이스에 워크로드 (예: 포드 또는 배포)를 배포했습니다. 이러한 네임스페이스는 GKE 클러스터 운영에 매우 중요하며 승인되지 않은 워크로드는 클러스터 안정성 또는 보안을 손상시킬 수 있습니다.
|
| 실행: GKE에서 기능이 과도한 컨테이너 실행 (미리보기) | GKE_EXCESSIVELY_CAPABLE_CONTAINER_CREATED |
Cloud 감사 로그: GKE 관리자 활동 로그 |
누군가 승격된 보안 컨텍스트가 있는 클러스터에서 다음 기능 중 하나 이상이 포함된 컨테이너를 만들었습니다.
|
| 지속성: GKE Webhook 구성 감지됨 (미리보기) | GKE_WEBHOOK_CONFIG_CREATED |
Cloud 감사 로그: GKE 관리자 활동 로그 |
GKE 클러스터에서 webhook 구성이 감지되었습니다. 웹훅은 Kubernetes API 요청을 가로채고 수정할 수 있으므로 공격자가 클러스터 내에 유지되거나 리소스를 조작할 수 있습니다. |
| 방어 회피: 정적 포드 생성됨 (미리보기) | GKE_STATIC_POD_CREATED |
Cloud 감사 로그: GKE 관리자 활동 로그 |
다른 사용자가 GKE 클러스터에 정적 포드를 만들었습니다. 정적 포드는 노드에서 직접 실행되고 Kubernetes API 서버를 우회하므로 모니터링 및 제어하기가 더 어렵습니다. 공격자는 정적 포드를 사용하여 감지를 피하거나 지속성을 유지할 수 있습니다. |
| 초기 액세스: TOR 프록시 IP에서 API 호출 성공 (미리보기) | GKE_TOR_PROXY_IP_REQUEST |
Cloud 감사 로그: GKE 관리자 활동 로그 |
Tor 네트워크와 연결된 IP 주소에서 GKE 클러스터에 API를 성공적으로 호출했습니다. Tor는 익명성을 제공하며 공격자는 이를 악용하여 신원을 숨기는 경우가 많습니다. |
| 초기 액세스: GKE NodePort 서비스 생성됨 (미리보기) | GKE_NODEPORT_SERVICE_CREATED |
Cloud 감사 로그: GKE 관리자 활동 로그 |
사용자가 NodePort 서비스를 만들었습니다. NodePort 서비스는 노드의 IP 주소 및 고정 포트에서 포드를 직접 노출하므로 클러스터 외부에서 포드에 액세스할 수 있습니다. 이렇게 하면 공격자가 노출된 서비스의 취약점을 악용해 클러스터 또는 민감한 정보에 액세스할 수 있으므로 상당한 보안 위험이 발생할 수 있습니다. |
| 영향: GKE kube-dns 수정 감지됨 (미리보기) | GKE_KUBE_DNS_MODIFICATION |
Cloud 감사 로그: GKE 관리자 활동 로그 |
다른 사용자가 GKE 클러스터의 kube-dns 구성을 수정했습니다. GKE kube-dns는 클러스터 네트워킹의 중요한 구성요소이며 구성을 잘못하면 보안 침해가 발생할 수 있습니다. |
GKE Threat Detection을 사용 설정하는 방법
GKE Threat Detection을 사용 설정하려면 고급 등급의 Kubernetes 보안 상황 스캔에 적법한 클러스터를 등록합니다. 이렇게 하면 워크로드 구성 감사 및 보안 게시판 표시와 같이 Kubernetes 보안 상황 스캔 기본 등급에 포함된 모든 기능도 활성화됩니다.
자세한 내용은 GKE Threat Detection을 사용하여 클러스터에서 위협 찾기를 참조하세요.
제한사항
GKE Threat Detection에는 다음 제한사항이 적용됩니다.
- GKE Enterprise에서만 사용 가능
- 조직의 프로젝트에서만 사용 가능
- 데이터 상주 구성과 같은 Security Command Center 옵션을 지원하지 않음
- Fleet에 등록된 클러스터의 결과만 표시
- GKE는 더 이상 영향을 받는 연결된 리소스가 없는 위협 발견 항목을 최대 180일 동안 보관
- 기존 클러스터의 결과만 표시. 클러스터를 삭제하면 GKE Threat Detection에서 GKE 보안 상황 대시보드에 발견 항목을 더 이상 표시하지 않습니다.