클러스터 보안 강화

Kubernetes의 개발 속도로 인해 종종 새로운 보안 기능을 사용하게 됩니다. 이 페이지에서는 Google Kubernetes Engine(GKE) 클러스터를 강화하기 위한 최신 가이드를 구현하는 방법을 안내합니다.

이 가이드에서는 클러스터 생성 시 고객 조치가 필요한 고가치 보안 완화 방법을 우선합니다. 중요도가 낮은 기능, 기본 설정에 따른 보안, 생성 후 사용 설정 가능한 기능은 이 문서의 뒷부분에서 설명합니다. 보안 항목에 대한 일반적인 개요는 보안 개요를 읽어보세요.

Security Health Analytics를 사용하여 이러한 권장사항 및 기타 일반적인 구성 오류를 자동으로 확인할 수 있습니다.

아래의 권장사항이 CIS GKE 벤치마크 권장사항과 관련이 있는 경우에 지정됩니다.

지체 없는 GKE 인프라 업그레이드 (기본 버전 2019-11-11).

CIS GKE 벤치마크 권장사항: 6.5.3. 노드 자동 업그레이드가 GKE 노드에 사용 설정되어 있는지 확인

보안을 향상시킬 수 있는 가장 간단한 방법 중 하나는 Kubernetes 버전을 최신 상태로 유지하는 것입니다. Kubernetes에는 새로운 보안 기능과 보안 패치가 자주 제공됩니다.

보안 패치에 대한 자세한 내용은 GKE 보안 게시판을 참조하세요.

Google Kubernetes Engine에서는 마스터가 자동으로 패치되고 업그레이드됩니다. 노드 자동 업그레이드도 클러스터의 노드를 자동으로 업그레이드합니다.

노드 자동 업그레이드를 사용 중지하는 경우 자체 일정에 따라 월 단위로 업그레이드하는 것이 좋습니다. 이전 클러스터는 노드 자동 업그레이드를 선택하고 중요한 패치와 관련된 GKE 보안 게시판을 따라야 합니다.

자세한 내용은 노드 자동 업그레이드를 참조하세요.

제어 영역 및 노드에 대한 네트워크 액세스 제한

CIS GKE 벤치마크 권장사항: 6.6.2. VPC 기반 클러스터 선호, 6.6.3. 마스터 승인 네트워크가 사용 설정되어 있는지 확인, 6.6.4. 비공개 엔드포인트는 사용 설정되고 공개 액세스는 중지된 상태로 클러스터가 생성되었는지 학인, 6.6.5. 클러스터가 비공개 노드로 생성되었는지 확인

클러스터 제어 영역과 노드의 인터넷 노출을 제한해야 합니다. 이는 클러스터 생성 시점에만 설정할 수 있습니다.

기본적으로 GKE 클러스터 제어 영역과 노드에는 모든 IP 주소에서 액세스할 수 있는 인터넷 라우팅 가능 주소가 있습니다.

GKE 클러스터 제어 영역의 경우 비공개 클러스터 만들기를 참조하세요. 네트워크 수준 보호를 제공할 수 있는 세 가지 유형의 비공개 클러스터가 있습니다.

  • 공개 엔드포인트 액세스 사용 안 함: 마스터 및 노드에 대한 모든 인터넷 액세스를 차단하는 가장 안전한 옵션입니다. Cloud InterconnectCloud VPN을 사용하여 온프레미스 네트워크를 Google Cloud에 연결하도록 구성한 경우에 적합합니다. 이러한 기술은 회사 네트워크를 클라우드 VPC에 효과적으로 연결합니다.
  • 공개 엔드포인트 액세스 사용 설정, 마스터 승인 네트워크 사용 설정(권장사항): 이 옵션은 정의된 소스 IP 주소에서 마스터에 대한 제한된 액세스를 제공합니다. 기존 VPN 인프라가 없거나 회사 VPN, Cloud Interconnect 또는 Cloud VPN 대신 공개 인터넷을 통해 연결된 원격 사용자나 지사가 있는 경우에 적합합니다.
  • 공개 엔드포인트 액세스 사용, 마스터 승인 네트워크 사용 안 함: 인터넷에 있는 모든 사용자가 제어 영역에 네트워크 연결을 할 수 있도록 허용하는 기본 옵션입니다.

노드에 직접 인터넷 액세스를 사용하지 않으려면 클러스터 생성 시 gcloud tooloption --enable-private-nodes를 지정합니다.

이는 GKE가 RFC 1918 비공개 IP 주소로 노드를 프로비저닝한다는 것을 의미합니다. 즉, 공개 인터넷을 통해 노드에 직접 연결할 수 없습니다.

클러스터는 최소한 마스터 인증 네트워크 및 비공개 노드를 사용하는 것이 좋습니다. 이렇게 하면 다음 항목을 통해 제어 영역에 연결할 수 있습니다.

  • 마스터 인증 네트워크의 허용된 CIDR
  • 클러스터 VPC 내의 노드
  • 마스터를 관리하는 Google의 내부 프로덕션 작업

클러스터 생성 시 다음 gcloud 플래그에 해당합니다.

  • --enable-ip-alias
  • --enable-private-nodes
  • --enable-master-authorized-networks

그룹 인증(베타)

CIS GKE 벤치마크 권장사항: 6.8.3. GKE용 Google 그룹스로 Kubernetes RBAC 사용자 관리

이 설정은 클러스터 생성 시점에만 사용 설정될 수 있습니다.

그룹을 사용하여 사용자를 관리해야 합니다. 그룹을 사용하면 ID 관리 시스템과 ID 관리자를 사용하여 ID를 제어할 수 있습니다. 그룹 구성원을 조정하면 그룹에 사용자를 추가하거나 제거할 때마다 RBAC 구성을 업데이트할 필요가 없습니다.

Google 그룹스를 사용하여 사용자 권한을 관리하려면 클러스터를 만들 때 GKE용 Google 그룹스를 사용 설정해야 합니다. 이를 통해 동일한 권한을 가진 사용자를 손쉽게 관리하고 ID 관리자가 사용자를 중앙에서 일관성 있게 관리하도록 허용할 수 있습니다.

GKE용 Google 그룹스를 사용하려면 gke-security-groups Google 그룹을 생성하여 사용자 액세스를 관리하고 클러스터 생성 시 gcloud 플래그를 --security-group으로 지정합니다.

컨테이너 노드 선택사항

다음 섹션에서는 보안 노드 구성 선택사항을 설명합니다.

보안 GKE 노드 사용 설정

CIS GKE 벤치마크 권장사항: 6.5.5. 보안 GKE 노드가 사용 설정되어 있는지 확인

보안 GKE 노드는 강력하고 검증 가능한 노드 ID와 무결성을 제공하여 GKE 노드 보안을 강화하고 모든 GKE 클러스터에서 사용 설정되어야 합니다.

보안 GKE 노드를 사용 설정하려면 클러스터 생성 또는 업데이트 시 gcloud 옵션을 --enable-shielded-nodes로 지정합니다. 보안 GKE 노드를 보안 부팅과 함께 사용해야 합니다. 타사의 서명되지 않은 커널 모듈이 필요한 경우 보안 부팅을 사용하면 안 됩니다. 보안 부팅을 사용 설정하려면 클러스터 생성 시 gcloud 플래그를 --shielded-secure-boot로 지정하세요.

containerd 런타임에서 강화 노드 이미지 선택

Containerd(cos_containerd)를 포함한 컨테이너 최적화 OS 이미지는 Kubernetes와 직접 통합된 containerd를 메인 컨테이너 런타임으로 하는 컨테이너 최적화 OS 이미지의 한 변형입니다.

containerd는 Docker의 핵심 런타임 구성요소이며 Kubernetes Container 런타임 인터페이스(CRI)의 핵심 컨테이너 기능을 제공하도록 설계되었습니다. 전체 Docker 데몬보다 훨씬 덜 복잡하므로 공격에 취약한 부분이 적습니다.

클러스터에서 cos_containerd 이미지를 사용하려면 클러스터 생성 또는 업그레이드 시 gcloud 플래그를 --image-type=cos_containerd로 지정하세요.

cos_containerd는 컨테이너를 실행하기 위해 특별히 커스텀으로 빌드, 최적화, 강화된 GKE의 선호 이미지입니다.

워크로드 아이덴티티 사용 설정

CIS GKE 벤치마크 권장사항: 6.2.2. 전용 Google Cloud 서비스 계정 및 워크로드 아이덴티티 사용 선호

워크로드 아이덴티티는 Google API를 인증하는 데 권장되는 방식입니다. 서비스 계정으로 Google Cloud 인증에 설명된 노드 서비스 계정을 사용하거나 서비스 계정 키를 보안 비밀로 내보내는 이전 권장사항을 대체합니다.

워크로드 아이덴티티는 메타데이터 숨김을 사용해야 할 필요성을 대체하며, 따라서 두 접근 방법은 상호 호환되지 않습니다. 메타데이터 숨김으로 보호되는 민감한 메타데이터는 워크로드 아이덴티티로도 보호됩니다.

GKE Sandbox로 워크로드 격리 강화

CIS GKE 벤치마크 권장사항: 6.10.4. 특히 신뢰할 수 없는 워크로드의 격리 강화를 위해 GKE Sandbox 고려

GKE Sandbox는 악성 코드가 클러스터 노드의 호스트 커널에 영향을 미치지 않도록 차단하는 보안 레이어를 추가합니다.

GKE Sandbox로 워크로드 격리 강화에서 GKE Sandbox를 사용하는 방법을 알아보세요.

권한

Google 서비스 계정 최소 권한 사용

CIS GKE 벤치마크 권장사항: 6.2.1. Compute Engine 기본 서비스 계정을 사용하여 GKE 클러스터 실행하지 않는 것을 선호

각 GKE 노드에는 Cloud Identity and Access Management(Cloud IAM) 서비스 계정이 연결되어 있습니다. 기본적으로 노드에는 Compute Engine 기본 서비스 계정이 제공되며, 이는 Cloud Console의 IAM 섹션으로 이동하여 찾을 수 있습니다. 이 계정은 기본적으로 넓은 액세스 범위를 포함하기 때문에, 다양한 애플리케이션에 유용하지만, Kubernetes Engine 클러스터를 실행하는 데 필요한 것보다 많은 권한을 포함합니다. Compute Engine 기본 서비스 계정을 사용하는 대신 GKE 클러스터를 실행하는 데 필요한 최소 권한만 있는 서비스 계정을 만들어서 사용해야 합니다.

워크로드 아이덴티티를 출시하면서 노드 서비스 계정에 더 제한된 사용 사례를 제안하고 있습니다. 로깅, 모니터링, 유사한 작업을 담당하는 시스템 데몬이 노드 서비스 계정을 사용할 것으로 예상됩니다. 대신 Pod의 워크로드는 Google ID를 워크로드 아이덴티티로 프로비저닝해야 합니다.

GKE에는 최소한 monitoring.viewer, monitoring.metricWriter, logging.logWriter 역할이 포함된 서비스 계정이 필요합니다. 모니터링 역할로깅 역할을 자세히 알아보세요.

다음 명령어는 GKE를 작동하는 데 필요한 최소 권한으로 Cloud IAM 서비스 계정을 만듭니다.

gcloud

gcloud iam service-accounts create sa-name \
  --display-name=sa-name

gcloud projects add-iam-policy-binding project-id \
  --member "serviceAccount:sa-name@project-id.iam.gserviceaccount.com" \
  --role roles/logging.logWriter

gcloud projects add-iam-policy-binding project-id \
  --member "serviceAccount:sa-name@project-id.iam.gserviceaccount.com" \
  --role roles/monitoring.metricWriter

gcloud projects add-iam-policy-binding project-id \
  --member "serviceAccount:sa-name@project-id.iam.gserviceaccount.com" \
  --role roles/monitoring.viewer

구성 커넥터

참고: 이 단계에는 구성 커넥터가 필요합니다. 설치 안내를 따라 클러스터에 구성 커넥터를 설치하세요.

  1. 서비스 계정을 만들려면 다음 리소스를 service-account.yaml로 다운로드합니다. [SA_NAME]을 서비스 계정에 사용할 이름으로 바꿉니다.

    apiVersion: iam.cnrm.cloud.google.com/v1beta1
    kind: IAMServiceAccount
    metadata:
      name: [SA_NAME]
    spec:
      displayName: [SA_NAME]
    그런 후 다음을 실행합니다.
    kubectl apply -f service-account.yaml

  2. logging.logWriter 역할을 서비스 계정에 적용합니다. 다음 리소스를 policy-logging.yaml로 다운로드합니다. [SA_NAME][PROJECT_ID]를 자체 정보로 바꿉니다.

    apiVersion: iam.cnrm.cloud.google.com/v1beta1
    kind: IAMPolicyMember
    metadata:
      name: policy-logging
    spec:
      member: serviceAccount:[SA_NAME]@[PROJECT_ID].iam.gserviceaccount.com
      role: roles/logging.logWriter
      resourceRef:
        kind: Project
        name: [PROJECT_ID]
    kubectl apply -f policy-logging.yaml

  3. monitoring.metricWriter 역할을 적용합니다. 다음 리소스를 policy-metrics-writer.yaml로 다운로드합니다. [SA_NAME][PROJECT_ID]를 자체 정보로 바꿉니다.

    apiVersion: iam.cnrm.cloud.google.com/v1beta1
    kind: IAMPolicyMember
    metadata:
      name: policy-metrics-writer
    spec:
      member: serviceAccount:[SA_NAME]@[PROJECT_ID].iam.gserviceaccount.com
      role: roles/monitoring.metricWriter
      resourceRef:
        kind: Project
        name: [PROJECT_ID]
    kubectl apply -f policy-metrics-writer.yaml

  4. monitoring.viewer 역할을 적용합니다. 다음 리소스를 policy-monitoring.yaml로 다운로드합니다. [SA_NAME][PROJECT_ID]를 자체 정보로 바꿉니다.

    apiVersion: iam.cnrm.cloud.google.com/v1beta1
    kind: IAMPolicyMember
    metadata:
      name: policy-monitoring
    spec:
      member: serviceAccount:[SA_NAME]@[PROJECT_ID].iam.gserviceaccount.com
      role: roles/monitoring.viewer
      resourceRef:
        kind: Project
        name: [PROJECT_ID]
    kubectl apply -f policy-monitoring.yaml

또한 Google Container Registry에서 비공개 이미지를 사용할 때는 이에 대한 액세스 권한을 부여해야 합니다.

gcloud

gcloud projects add-iam-policy-binding project-id \
--member "serviceAccount:sa-name@project-id.iam.gserviceaccount.com" \
--role roles/storage.objectViewer

구성 커넥터

참고: 이 단계에는 구성 커넥터가 필요합니다. 설치 안내를 따라 클러스터에 구성 커넥터를 설치하세요.

서비스 계정에 storage.objectViewer 역할을 적용합니다. 다음 리소스를 policy-object-viewer.yaml로 다운로드합니다. [SA_NAME][PROJECT_ID]를 자체 정보로 바꿉니다.

apiVersion: iam.cnrm.cloud.google.com/v1beta1
kind: IAMPolicyMember
metadata:
  name: policy-object-viewer
spec:
  member: serviceAccount:[SA_NAME]@[PROJECT_ID].iam.gserviceaccount.com
  role: roles/storage.objectViewer
  resourceRef:
    kind: Project
    name: [PROJECT_ID]
kubectl apply -f policy-object-viewer.yaml

다른 사용자가 이 서비스 계정으로 새 클러스터 또는 노드 풀을 만들 수 있게 하려면 해당 사용자에게 이 서비스 계정의 서비스 계정 사용자 역할을 부여해야 합니다.

gcloud

gcloud iam service-accounts add-iam-policy-binding \
sa-name@project-id.iam.gserviceaccount.com \
--member=user:user \
--role=roles/iam.serviceAccountUser

구성 커넥터

참고: 이 단계에는 구성 커넥터가 필요합니다. 설치 안내를 따라 클러스터에 구성 커넥터를 설치하세요.

서비스 계정에 iam,serviceAccountUser 역할을 적용합니다. 다음 리소스를 policy-service-account-user.yaml로 다운로드합니다. [SA_NAME][PROJECT_ID]를 자체 정보로 바꿉니다.

apiVersion: iam.cnrm.cloud.google.com/v1beta1
kind: IAMPolicyMember
metadata:
  name: policy-service-account-user
spec:
  member: serviceAccount:[SA_NAME]@[PROJECT_ID].iam.gserviceaccount.com
  role: roles/iam.serviceAccountUser
  resourceRef:
    kind: Project
    name: [PROJECT_ID]
kubectl apply -f policy-service-account-user.yaml

클러스터가 이미 있으면 이제 이 새로운 서비스 계정으로 새로운 노드 풀을 만들 수 있습니다.

gcloud container node-pools create node-pool \
  --service-account=sa-name@project-id.iam.gserviceaccount.com \
  --cluster=cluster-name

GKE 클러스터에 다른 Google Cloud 서비스에 대한 액세스 권한이 필요하면 추가 서비스 계정을 만들고 워크로드 아이덴티티를 사용하여 서비스 계정에 대한 액세스 권한을 워크로드에 부여해야 합니다.

클러스터 탐색 RBAC 권한 제한

기본적으로 Kubernetes는 CustomResourceDefinitions의 항목을 포함한 클러스터의 API 정보에 대한 광범위한 액세스 권한을 부여하는 방임적인 discovery ClusterRoleBindings 집합으로 클러스터를 부트스트랩합니다.

사용자는 system:discoverysystem:basic-user ClusterRoleBindings의 대상에 포함된 system:authenticated 그룹이 인증된 사용자(Google 계정이 있는 사용자 포함)를 포함할 수 있으며 GKE의 클러스터에 대한 유의미한 수준의 보안을 나타내지 않는다는 점을 알아야 합니다.

클러스터의 탐색 API를 강화하고자 하는 경우 다음 중 하나 이상을 고려해야 합니다.

  • 승인된 네트워크를 구성하여 설정된 IP 범위에 대한 액세스 제한
  • 비공개 클러스터를 설정하여 VPC 액세스 제한
  • 기본 system:discoverysystem:basic-user ClusterRoleBindings의 대상 선별. 예를 들어 system:(un)authenticated 액세스를 허용하는 Kubernetes 기본값 대신 system:serviceaccounts 그룹 및 다른 알려진 사용자와 그룹 액세스만 허용하는 것을 고려

네임스페이스와 RBAC를 사용하여 클러스터 리소스에 대한 액세스 제한

CIS GKE 벤치마크 권장사항: 5.6.1. 네임스페이스를 사용하여 리소스 간 관리 경계 만들기

각 팀과 환경별로 별도의 네임스페이스 또는 클러스터를 생성하여 팀에 Kubernetes에 대한 최소 권한을 부여합니다. 책임성 및 지불 거절과 관련하여 각 네임스페이스에 비용 센터 및 적절한 라벨을 지정합니다. 특히 프로덕션 환경에서 개발자에게만 애플리케이션을 배포하고 관리하는 데 필요한 네임스페이스의 액세스 수준을 제공합니다. 사용자가 클러스터에 수행해야 하는 작업을 매핑하고 각 작업을 수행하는 데 필요한 권한을 정의합니다.

네임스페이스 만들기에 대한 자세한 내용은 Kubernetes 문서를 참조하세요.

Cloud IAM역할 기반 액세스 제어(RBAC)는 함께 작동하며, 개체가 클러스터의 리소스를 사용하기 위해서는 어느 수준에서든 충분한 권한을 보유해야 합니다.

그룹 및 사용자에게 적절한 GKE용 Cloud IAM 역할을 할당하여 프로젝트 수준의 권한을 제공하고 RBAC를 사용하여 클러스터 및 네임스페이스 수준의 권한을 부여합니다. 자세한 내용은 액세스 제어를 참조하세요.

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

네트워크 정책으로 Pod 간 트래픽 제한

CIS GKE 벤치마크 권장사항: 6.6.7. 네트워크 정책이 사용 설정되어 있고 적절하게 설정되어 있는지 확인

기본적으로 클러스터에 있는 모든 Pod는 서로 통신할 수 있습니다. 워크로드의 필요에 따라 Pod 간 통신을 제어해야 합니다.

서비스에 대한 네트워크 액세스를 제한하면 클러스터 내에서 공격자의 측면 이동이 더 어려워지고 실수로 인한 서비스 거부나 고의적인 서비스 거부로부터 서비스를 보호할 수 있습니다. 트래픽을 제어하는 두 가지 권장 방법은 다음과 같습니다.

  1. Istio를 사용합니다. GKE에 Istio 설치를 참조하세요. 부하 분산, 서비스 승인, 제한, 할당량, 측정항목 등에 관심이 있는 경우 이 옵션을 선택합니다.
  2. Kubernetes 네트워크 정책을 사용합니다. 클러스터 네트워크 정책 설정을 참조하세요. Kubernetes에서 제공하는 기본 액세스 제어 기능을 찾고 있는 경우 이 옵션을 선택합니다. Kubernetes 문서에 간단한 nginx 배포를 위한 훌륭한 둘러보기가 포함되어 있습니다.

Istio와 네트워크 정책은 필요할 경우 함께 사용할 수 있습니다.

보안 비밀 관리

CIS GKE 벤치마크 권장사항: 6.3.1. Cloud KMS에서 관리되는 키를 사용하여 Kubernetes 보안 비밀 암호화

etcd에 저장되는 보안 비밀과 같이 민감한 정보를 위한 추가 보안 레이어를 제공해야 합니다. 이렇게 하려면 GKE 클러스터와 통합된 보안 비밀 관리자를 구성해야 합니다. 일부 솔루션은 GKE와 Anthos GKE On-Prem 모두에서 작동하므로 여러 환경에서 워크로드를 실행하는 경우 더 적합할 수 있습니다. HashiCorp Vault와 같은 외부 보안 비밀 관리자를 사용하는 경우 클러스터를 만들기 전에 사용 준비를 완료해야 합니다.

보안 비밀 관리에는 여러 가지 옵션이 있습니다.

  • Kubernetes 보안 비밀은 기본적으로 GKE에서 사용할 수 있습니다. 선택적으로 애플리케이션 레이어 보안 비밀 암호화를 사용하여 관리하는 키로 애플리케이션 레이어에서 암호화할 수 있습니다.
  • HashiCorp Vault와 같은 보안 비밀 관리자를 사용할 수 있습니다. 이는 강화 HA 모드에서 실행될 때 일관성 있는 프로덕션 수준의 보안 비밀 관리 방법을 제공합니다. Kubernetes 서비스 계정 또는 Google Cloud 서비스 계정을 사용하여 HashiCorp Vault에 인증할 수 있습니다. GKE에서 Vault를 사용하는 방법에 대한 자세한 내용은 Kubernetes에서 HashiCorp Vault 실행 및 연결을 참조하세요.

GKE VM은 기본적으로 etcd를 포함하는 스토리지 레이어에서 암호화됩니다.

허용 컨트롤러를 사용하여 정책 적용

CIS GKE 벤치마크 권장사항: 6.10.3. Pod 보안 정책이 사용 설정되어 있고 적절하게 설정되어 있는지 확인

허용 컨트롤러는 클러스터가 사용되는 방식을 제어하고 적용하는 플러그인입니다. Kubernetes의 고급 보안 기능 중 일부를 사용하도록 설정해야 하며, 클러스터 보안 강화를 위한 심층 방어 방식의 중요한 요소입니다.

기본적으로 Kubernetes에서 Pod는 필요한 것 이상의 기능으로 작동될 수 있습니다. 해당 워크로드에 필요한 정도로만 Pod 기능을 제한해야 합니다.

Kubernetes는 명시적으로 부여된 기능만으로 Pod 실행을 제한하기 위한 방법을 제공합니다. Pod 보안 정책을 사용하면 Pod에 대한 스마트 기본값을 설정하고, 시스템 전체에서 사용 설정하려는 제어 방법을 적용할 수 있습니다. 이러한 정책은 애플리케이션의 요구에 맞게 정의해야 합니다. restricted-psp.yaml 예시 정책은 좋은 출발점이 됩니다.

Pod 보안 정책을 자세히 알아보려면 PodSecurityPolicies 사용을 참조하세요.

NetworkPolicy를 사용 중이며 PodSecurityPolicy의 적용 대상인 Pod가 있는 경우 PodSecurityPolicy를 사용할 권한이 있는 RBAC 역할 또는 ClusterRole을 만듭니다. 그런 다음 Pod의 서비스 계정에 역할 또는 ClusterRole을 결합합니다. 이 경우 사용자 계정에 권한을 부여하는 것만으로는 충분하지 않습니다. 자세한 내용은 정책 승인을 참조하세요.

클러스터 구성 모니터링

클러스터 구성을 감사하여 정의된 설정과의 편차를 확인해야 합니다.

Security Health Analytics을 사용하여 이 강화 가이드에서 다룬 많은 권장사항 및 기타 일반적인 구성 오류를 자동으로 확인할 수 있습니다.

보안 기본 사항

다음 섹션에서는 새 클러스터에서 기본적으로 안전하게 구성되는 옵션을 설명합니다. 기존 클러스터가 안전하게 구성되어 있는지 확인해야 합니다.

노드 메타데이터 보호(1.12 이상 기본값)

CIS GKE 벤치마크 권장사항: 6.4.1. 기존 Compute Engine 인스턴스 메타데이터 API가 사용 중지되어 있는지 확인, 6.4.2. GKE 메타데이터 서버가 사용 설정되어 있는지 확인

Compute Engine의 인스턴스 메타데이터 서버는 메타데이터 쿼리 헤더를 적용하지 않는 기존 /0.1//v1beta1/ 엔드포인트를 노출합니다. 이러한 API는 1.12 이상의 새 클러스터에서 기본적으로 사용 중지되었습니다. 이전 버전에서 클러스터를 업그레이드한 경우 기존 API 사용 중지를 수동으로 수행해야 합니다.

Kubernetes에 대한 일부 실제 공격은 사용자 인증 정보를 추출하기 위해 VM 메타데이터 서버에 액세스합니다. 워크로드 아이덴티티 또는 메타데이터 숨김을 사용하는 경우 이러한 공격이 차단됩니다.

Compute Engine v1beta1 및 v0.1 메타데이터 서버 엔드포인트는 지원 중단되었으며 서비스가 종료될 예정입니다. v1 엔드포인트를 사용하도록 모든 요청을 업데이트해야 합니다.

자세한 내용은 클러스터 메타데이터 보호를 참조하세요.

기존 클라이언트 인증 방법 중지(1.12 이상 기본값)

CIS GKE 벤치마크 권장사항: 6.8.1. 정적 비밀번호를 사용하는 기본 인증이 중지되어 있는지 확인, 6.8.2. 클라이언트 인증서를 사용한 인증이 중지되어 있는지 확인

Kubernetes API 서버에 인증하는 방법은 몇 가지가 있습니다.

GKE에서 지원되는 방법은 서비스 계정 bearer 토큰, OAuth 토큰, x509 클라이언트 인증서, 정적 비밀번호입니다. OAuth 토큰 방법의 경우 GKE는 Kubernetes 구성을 설정하고, 액세스 토큰을 가져오고, 이를 최신 상태로 유지하는 방식으로 gcloud를 통해 인증을 관리합니다.

GKE가 Google OAuth와 통합되기 전에는 사전 프로비저닝된 x509 인증서 또는 정적 비밀번호가 유일하게 사용 가능한 인증 방법이었지만 이제 1.12 이상부터는 권장되지 않으며 새 클러스터에서 기본적으로 중지됩니다.

기존 클러스터는 OAuth로 이동해야 합니다. 클러스터 외부의 시스템에서 장기적인 사용자 인증 정보가 필요한 경우 필요한 권한을 보유한 Google 서비스 계정 또는 Kubernetes 서비스 계정을 생성하고 키를 내보내는 것이 좋습니다.

기존 클러스터를 업데이트하고 정적 비밀번호를 삭제하려면 다음 명령어를 사용하세요.

gcloud container clusters update cluster-name \
  --no-enable-basic-auth

현재 기존 클러스터에서 사전 발급된 클라이언트 인증서를 삭제할 수 있는 방법이 없지만 RBAC가 사용 설정되어 있고 ABAC가 사용 중지되어 있는 경우 권한이 없습니다.

Cloud Logging 사용(기본값)

CIS GKE 벤치마크 권장사항: 6.7.1. Stackdriver Kubernetes Logging 및 Monitoring이 사용 설정되어 있는지 확인

운영 오버헤드를 줄이고 로그의 통합 보기를 유지하려면 클러스터 배포 위치와 상관없이 일관성 있는 로깅 전략을 구현합니다. Anthos 클러스터는 기본적으로 Cloud Logging과 통합되어 있으며 이렇게 구성된 상태를 유지해야 합니다.

모든 GKE 클러스터에는 Kubernetes API 서버로 전송된 호출을 시간순으로 기록하는 Kubernetes 감사 로깅이 기본적으로 사용 설정되어 있습니다. Kubernetes 감사 로그 항목은 의심스러운 API 요청을 조사하거나, 통계를 수집하거나, 원치 않는 API 호출에 대한 모니터링 알림을 생성하는 데 유용합니다.

GKE 클러스터는 Cloud 감사 로그에 의한 Kubernetes 감사 로깅Cloud Logging을 통합합니다. 원하는 경우 로깅 시스템으로 로그를 Cloud Logging에서 내보내기하는 것이 가능합니다.

Kubernetes 웹 UI(대시보드) 사용 안 함(1.10 이상 기본값)

CIS GKE 벤치마크 권장사항: 6.10.1. Kubernetes 웹 UI가 중지되어 있는지 확인

GKE에서 실행할 때 Kubernetes 웹 UI(대시보드)를 사용 설정하면 안 됩니다.

Kubernetes 웹 UI(대시보드)는 상위 권한의 Kubernetes 서비스 계정으로 지원됩니다. Cloud Console에서 대부분의 동일 기능을 제공하므로 이러한 권한이 필요하지 않습니다.

Kubernetes 웹 UI를 사용 중지하려면 다음을 수행하세요.

gcloud container clusters update cluster-name \
    --update-addons=KubernetesDashboard=DISABLED

ABAC 중지(1.10 이상 기본값)

CIS GKE 벤치마크 권장사항: 6.8.4. 기존 승인(ABAC)이 중지되어 있는지 확인

ABAC(속성 기반 액세스 제어)를 중지하고 대신 GKE에서 RBAC(역할 기반 액세스 제어)를 사용해야 합니다.

Kubernetes에서 RBAC는 클러스터 및 네임스페이스 수준에서 리소스에 대한 권한을 부여하기 위해 사용됩니다. RBAC를 사용하면 권한 집합이 포함된 규칙을 사용하여 역할을 정의할 수 있습니다. RBAC는 상당한 보안 이점이 있으며, Kubernetes에서 현재 안정화되어 있으므로, 이제는 ABAC를 사용 중지해야 합니다.

아직 ABAC를 사용하는 경우에는 먼저 RBAC 사용을 위한 기본 요건을 참조하세요. 클러스터를 이전 버전에서 업그레이드했고, ABAC를 사용하는 경우에는 액세스 제어 구성을 업데이트해야 합니다.

gcloud container clusters update cluster-name \
    --no-enable-legacy-authorization

위의 권장사항에 따라 새 클러스터를 만들려면 다음 명령어를 사용하세요.

gcloud container clusters create cluster-name \
    --no-enable-legacy-authorization

다음 단계