GSP480

개요

이 실습에서는 네트워크 통신에 세부적인 제한을 적용하여 Kubernetes Engine의 보안을 개선하는 방법을 알아봅니다.

최소 권한의 원칙은 결함과 악의적인 행위로부터 중요 시스템의 보호를 강화하는 데 중요한 설계 고려사항으로 널리 알려져 있습니다. 이 원칙은 모든 구성요소가 합법적 목적에 필요한 정보와 리소스에만 액세스할 수 있어야 한다고 제안합니다. 이 문서에서는 최소 권한의 원칙이 Kubernetes Engine 네트워크 계층 내에서 어떻게 구현될 수 있는지 보여줍니다.

네트워크 연결은 Kubernetes Engine 인프라의 두 계층에서 제한될 수 있습니다. 첫 번째이자 더 거칠고 단순한 메커니즘은 네트워크, 서브네트워크, 호스트 수준에서 방화벽 규칙을 적용하는 것입니다. 이러한 규칙은 Kubernetes Engine 외부의 VPC 수준에서 적용됩니다.

방화벽 규칙은 강력한 보안 조치이며 Kubernetes를 사용하면 네트워크 정책을 통해 더 세부적인 규칙을 정의할 수 있습니다. 네트워크 정책은 클러스터 내 통신을 제한하는 데 사용됩니다. 네트워크 정책은 호스트의 네트워크 네임스페이스에 연결된 포드에는 적용되지 않습니다.

이 실습에서는 비공개 Kubernetes Engine 클러스터와 클러스터에 액세스하는 데 사용할 배스천 호스트를 프로비저닝합니다. 배스천 호스트는 클러스터에 액세스할 수 있는 단일 호스트를 제공하며, 비공개 Kubernetes 네트워크와 결합 시 클러스터가 인터넷 전반의 악의적인 행위에 노출되지 않도록 보장합니다. 배스천은 클라우드 네트워크에 대한 VPN 액세스 권한이 없는 경우에 특히 유용합니다.

클러스터 내에 간단한 HTTP 서버 한 개와 클라이언트 포드 두 개가 프로비저닝됩니다. 네트워크 정책과 라벨을 사용하여 클라이언트 포드 중 하나의 연결만 허용하는 방법을 알아보겠습니다.

이 실습은 GKE Binary Authorization에 대한 이해를 높이기 위한 목적으로 GKE Helmsman 엔지니어가 생성했습니다. Cloud Shell에서 gsutil cp -r gs://spls/gke-binary-auth/* .을 실행하고 cd gke-binary-auth-demo 명령어를 실행하여 이 데모를 볼 수 있습니다. 누구나 Google Cloud의 애셋에 참여할 수 있습니다.

아키텍처

Dataplane V2를 사용하는 비공개 Standard 모드 Kubernetes 클러스터를 정의합니다. Dataplane V2에는 네트워크 정책이 기본적으로 사용 설정되어 있습니다.

클러스터가 비공개이므로 인터넷에서 API와 워커 노드에 모두 액세스할 수 없습니다. 대신 배스천 호스트를 정의하고 방화벽 규칙을 사용하여 액세스를 사용 설정합니다. 배스천의 IP 주소는 클러스터의 승인된 네트워크로 정의되어 API에 대한 액세스 권한을 부여합니다.

클러스터 내에서 다음 세 가지 워크로드를 프로비저닝합니다.

1. hello-server: 내부적으로 액세스 가능한 엔드포인트가 있는 간단한 HTTP 서버입니다.
2. hello-client-allowed: hello-server에 반복적으로 액세스하려고 시도하는 단일 포드입니다. 포드에 라벨이 지정되어 네트워크 정책에서 hello-server에 연결할 수 있습니다.
3. hello-client-blocked: hello-client-allowed와 동일한 코드를 실행하지만 포드에 라벨이 지정되어 네트워크 정책에서 hello-server에 연결하는 것을 허용하지 않습니다.

설정 및 요건

실습 시작 버튼을 클릭하기 전에

다음 안내를 확인하세요. 실습에는 시간 제한이 있으며 일시중지할 수 없습니다. 실습 시작을 클릭하면 타이머가 시작됩니다. 이 타이머는 Google Cloud 리소스를 사용할 수 있는 시간이 얼마나 남았는지를 표시합니다.

실무형 실습을 통해 시뮬레이션이나 데모 환경이 아닌 실제 클라우드 환경에서 실습 활동을 진행할 수 있습니다. 실습 시간 동안 Google Cloud에 로그인하고 액세스하는 데 사용할 수 있는 새로운 임시 사용자 인증 정보가 제공됩니다.

이 실습을 완료하려면 다음을 준비해야 합니다.

• 표준 인터넷 브라우저 액세스 권한(Chrome 브라우저 권장)

참고: 이 실습을 실행하려면 시크릿 모드(권장) 또는 시크릿 브라우저 창을 사용하세요. 개인 계정과 학습자 계정 간의 충돌로 개인 계정에 추가 요금이 발생하는 일을 방지해 줍니다.

• 실습을 완료하기에 충분한 시간(실습을 시작하고 나면 일시중지할 수 없음)

참고: 이 실습에는 학습자 계정만 사용하세요. 다른 Google Cloud 계정을 사용하는 경우 해당 계정에 비용이 청구될 수 있습니다.

실습을 시작하고 Google Cloud 콘솔에 로그인하는 방법

1. 실습 시작 버튼을 클릭합니다. 실습 비용을 결제해야 하는 경우 결제 수단을 선택할 수 있는 대화상자가 열립니다. 왼쪽에는 다음과 같은 항목이 포함된 실습 세부정보 창이 있습니다.

   • Google Cloud 콘솔 열기 버튼
   • 남은 시간
   • 이 실습에 사용해야 하는 임시 사용자 인증 정보
   • 필요한 경우 실습 진행을 위한 기타 정보

2. Google Cloud 콘솔 열기를 클릭합니다(Chrome 브라우저를 실행 중인 경우 마우스 오른쪽 버튼으로 클릭하고 시크릿 창에서 링크 열기를 선택합니다).

   실습에서 리소스가 가동되면 다른 탭이 열리고 로그인 페이지가 표시됩니다.

   팁: 두 개의 탭을 각각 별도의 창으로 나란히 정렬하세요.

   참고: 계정 선택 대화상자가 표시되면 다른 계정 사용을 클릭합니다.

3. 필요한 경우 아래의 사용자 이름을 복사하여 로그인 대화상자에 붙여넣습니다.

   {{{user_0.username | "Username"}}}

   실습 세부정보 창에서도 사용자 이름을 확인할 수 있습니다.

4. 다음을 클릭합니다.

5. 아래의 비밀번호를 복사하여 시작하기 대화상자에 붙여넣습니다.

   {{{user_0.password | "Password"}}}

   실습 세부정보 창에서도 비밀번호를 확인할 수 있습니다.

6. 다음을 클릭합니다.

   중요: 실습에서 제공하는 사용자 인증 정보를 사용해야 합니다. Google Cloud 계정 사용자 인증 정보를 사용하지 마세요. 참고: 이 실습에 자신의 Google Cloud 계정을 사용하면 추가 요금이 발생할 수 있습니다.

7. 이후에 표시되는 페이지를 클릭하여 넘깁니다.

   • 이용약관에 동의합니다.
   • 임시 계정이므로 복구 옵션이나 2단계 인증을 추가하지 않습니다.
   • 무료 체험판을 신청하지 않습니다.

잠시 후 Google Cloud 콘솔이 이 탭에서 열립니다.

참고: Google Cloud 제품 및 서비스에 액세스하려면 탐색 메뉴를 클릭하거나 검색창에 제품 또는 서비스 이름을 입력합니다.

Cloud Shell 활성화

Cloud Shell은 다양한 개발 도구가 탑재된 가상 머신으로, 5GB의 영구 홈 디렉터리를 제공하며 Google Cloud에서 실행됩니다. Cloud Shell을 사용하면 명령줄을 통해 Google Cloud 리소스에 액세스할 수 있습니다.

1. Google Cloud 콘솔 상단에서 Cloud Shell 활성화 를 클릭합니다.

2. 다음 창을 클릭합니다.

   • Cloud Shell 정보 창을 통해 계속 진행합니다.
   • 사용자 인증 정보를 사용하여 Google Cloud API를 호출할 수 있도록 Cloud Shell을 승인합니다.

연결되면 사용자 인증이 이미 처리된 것이며 프로젝트가 학습자의 PROJECT_ID, (으)로 설정됩니다. 출력에 이 세션의 PROJECT_ID를 선언하는 줄이 포함됩니다.

Your Cloud Platform project in this session is set to {{{project_0.project_id | "PROJECT_ID"}}}

gcloud는 Google Cloud의 명령줄 도구입니다. Cloud Shell에 사전 설치되어 있으며 명령줄 자동 완성을 지원합니다.

3. (선택사항) 다음 명령어를 사용하여 활성 계정 이름 목록을 표시할 수 있습니다.

gcloud auth list

4. 승인을 클릭합니다.

출력:

ACTIVE: * ACCOUNT: {{{user_0.username | "ACCOUNT"}}} To set the active account, run: $ gcloud config set account `ACCOUNT`

5. (선택사항) 다음 명령어를 사용하여 프로젝트 ID 목록을 표시할 수 있습니다.

gcloud config list project

출력:

[core] project = {{{project_0.project_id | "PROJECT_ID"}}} 참고: gcloud 전체 문서는 Google Cloud에서 gcloud CLI 개요 가이드를 참고하세요.

데모 클론

1. Cloud Storage 버킷에서 이 실습에 필요한 리소스를 복사합니다.

gsutil cp -r gs://spls/gsp480/gke-network-policy-demo .

2. 데모 디렉터리로 이동합니다.

cd gke-network-policy-demo

3. 데모 파일을 실행 가능하게 만듭니다.

chmod -R 755 *

작업 1. 실습 설정

먼저 Google Cloud 리전과 영역을 설정합니다.

1. Google Cloud 리전을 설정합니다.

gcloud config set compute/region "{{{project_0.default_region|placeholder}}}"

2. Google Cloud 영역을 설정합니다.

gcloud config set compute/zone "{{{project_0.default_zone|placeholder}}}"

이 실습에서는 다음 Google Cloud 서비스 API를 사용하며, 이러한 API는 사용 설정되어 있습니다.

• compute.googleapis.com
• container.googleapis.com
• cloudbuild.googleapis.com

또한 Terraform 구성은 Kubernetes Engine 클러스터를 만들 위치를 결정하기 위해 세 가지 파라미터를 사용합니다.

• project ID
• region
• zone

편의를 위해 이러한 파라미터는 terraform 디렉터리의 terraform.tfvars라는 파일에 지정됩니다.

3. 적절한 API가 사용 설정되어 있는지 확인하고 gcloud 기본값을 기반으로 terraform/terraform.tfvars 파일을 생성하기 위해 다음을 실행합니다.

make setup-project

4. 확인 메시지가 표시되면 y를 입력합니다.

이렇게 하면 필요한 서비스 API가 사용 설정되고 다음 키가 포함된 terraform/terraform.tfvars 파일도 생성됩니다.

5. 다음을 실행하여 값이 gcloud config list의 출력과 일치하는지 확인합니다.

cat terraform/terraform.tfvars

Kubernetes Engine 클러스터 프로비저닝

1. 그런 다음 프로젝트 루트 내에서 Terraform 구성을 적용합니다.

make tf-apply

2. 메시지가 표시되면 생성된 계획을 검토하고 yes를 입력하여 환경을 배포합니다.

배포하는 데 몇 분 정도 걸립니다.

작업 2. 검증

클러스터가 성공적으로 생성되면 Terraform에서 메시지를 출력합니다.

...snip... google_container_cluster.primary: Still creating... (3m0s elapsed) google_container_cluster.primary: Still creating... (3m10s elapsed) google_container_cluster.primary: Still creating... (3m20s elapsed) google_container_cluster.primary: Still creating... (3m30s elapsed) google_container_cluster.primary: Creation complete after 3m34s (ID: gke-demo-cluster) Apply complete! Resources: 5 added, 0 changed, 0 destroyed.

완료된 작업 테스트

내 진행 상황 확인하기를 클릭하여 실행한 작업을 확인합니다. Terraform을 사용하여 필요한 인프라를 배포하면 평가 점수가 표시됩니다.

Terraform을 사용하여 필요한 인프라 설정(실습 설정)

1. 이제 나머지 단계를 위해 배스천에 SSH로 연결합니다.

gcloud compute ssh gke-demo-bastion

kubectl 및 커스텀 Kubernetes 클라이언트의 기존 버전에는 클라이언트와 Google Kubernetes Engine 간의 인증을 관리하는 제공업체별 코드가 포함되어 있습니다. v1.26부터는 이 코드가 더 이상 OSS kubectl에 포함되지 않습니다. GKE 사용자는 별도의 인증 플러그인을 다운로드하고 사용하여 GKE별 토큰을 생성해야 합니다. 새로운 바이너리인 gke-gcloud-auth-plugin은 GKE를 지원하는 kubectl 인증을 확장하는 데 Kubernetes Client-go 사용자 인증 정보 플러그인 메커니즘을 사용합니다. 자세한 내용은 다음 문서를 참조하세요.

kubectl에서 기본 제공업체별 코드를 사용하는 대신 새로운 인증용 바이너리 플러그인을 사용하도록 하려면 다음 단계를 사용합니다.

2. 연결되면 다음 명령어를 실행하여 VM에 gke-gcloud-auth-plugin을 설치합니다.

sudo apt-get install google-cloud-sdk-gke-gcloud-auth-plugin

3. ~/.bashrc에서 export USE_GKE_GCLOUD_AUTH_PLUGIN=True를 설정합니다.

echo "export USE_GKE_GCLOUD_AUTH_PLUGIN=True" >> ~/.bashrc

4. 다음 명령어를 실행합니다.

source ~/.bashrc

5. 다음 명령어를 실행하여 이 클러스터의 구성이 Client-go 사용자 인증 정보 플러그인 구성으로 업데이트되도록 합니다.

gcloud container clusters get-credentials gke-demo-cluster --zone {{{project_0.default_zone|placeholder}}}

성공하면 다음 메시지가 표시됩니다.

kubeconfig entry generated for gke-demo-cluster.

이제 배스천에서 새로 만든 클러스터를 표준 kubectl 명령에 사용할 수 있습니다.

작업 3. hello 서버 설치

테스트 애플리케이션은 hello-server로 배포된 간단한 HTTP 서버 하나와 클라이언트 두 개로 구성됩니다. 클라이언트 하나에는 app=hello 라벨이 지정되고 다른 클라이언트에는 app=not-hello 라벨이 지정됩니다.

hello-app 매니페스트를 적용하여 세 가지 서비스를 모두 배포할 수 있습니다.

1. 배스천에서 다음을 실행합니다.

kubectl apply -f ./manifests/hello-app/

출력:

deployment.apps/hello-client-allowed created deployment.apps/hello-client-blocked created service/hello-server created deployment.apps/hello-server created

2. 세 포드가 모두 성공적으로 배포되었는지 확인합니다.

kubectl get pods

hello-client-allowed, hello-client-blocked, hello-server 배포 각각에 대해 실행 중인 포드가 하나씩 표시됩니다.

NAME READY STATUS RESTARTS AGE hello-client-allowed-7d95fcd5d9-t8fsk | 1/1 Running 0 14m hello-client-blocked-6497db465d-ckbn8 | 1/1 Running 0 14m hello-server-7df58f7fb5-nvcvd | 1/1 Running 0 14m

완료된 작업 테스트

내 진행 상황 확인하기를 클릭하여 실행한 작업을 확인합니다. 간단한 HTTP hello 서버를 배포하면 평가 점수가 표시됩니다.

hello 서버 설치

작업 4. hello 서버에 대한 기본 액세스 확인

1. 먼저 '허용된' 클라이언트를 테일링합니다.

kubectl logs --tail 10 -f $(kubectl get pods -oname -l app=hello)

Ctrl+C를 눌러 종료합니다.

2. 두 번째로 '차단된' 클라이언트의 로그를 테일링합니다.

kubectl logs --tail 10 -f $(kubectl get pods -oname -l app=not-hello)

3. Ctrl+C를 눌러 종료합니다.

두 포드 모두 hello-server 서비스에 성공적으로 연결할 수 있습니다. 액세스를 제한하는 네트워크 정책을 아직 정의하지 않았기 때문입니다. 각 창에 서버의 성공적인 응답이 표시됩니다.

Hostname: hello-server-7df58f7fb5-nvcvd Hello, world! Version: 1.0.0 Hostname: hello-server-7df58f7fb5-nvcvd Hello, world! Version: 1.0.0 Hostname: hello-server-7df58f7fb5-nvcvd ...

작업 5. 네트워크 정책으로 액세스 제한

이제 app=hello 라벨이 지정되지 않은 모든 포드에서 hello-server 포드에 대한 액세스를 차단합니다.

사용할 정책 정의는 manifests/network-policy.yaml에 포함되어 있습니다.

1. 다음 명령어를 사용하여 정책을 적용합니다.

kubectl apply -f ./manifests/network-policy.yaml

출력:

networkpolicy.networking.k8s.io/hello-server-allow-from-hello-client created

2. '차단된' 클라이언트의 로그를 다시 테일링합니다.

kubectl logs --tail 10 -f $(kubectl get pods -oname -l app=not-hello)

이제 '차단된' 클라이언트를 테일링하는 창에 출력이 다음과 같이 표시됩니다.

wget: download timed out wget: download timed out wget: download timed out wget: download timed out wget: download timed out wget: download timed out wget: download timed out wget: download timed out wget: download timed out ...

이제 네트워크 정책으로 인해 라벨이 지정되지 않은 포드에서 hello-server로의 통신이 차단되었습니다.

3. Ctrl+C를 눌러 종료합니다.

작업 6. 네트워크 정책으로 네임스페이스 제한

이전 예시에서는 포드 라벨을 기반으로 연결을 제한하는 네트워크 정책을 정의했습니다. 팀이나 애플리케이션에 자체 네임스페이스가 부여된 경우 특히 전체 네임스페이스에 라벨을 지정하는 것이 유용한 경우가 많습니다.

이제 지정된 네임스페이스의 트래픽만 허용하도록 네트워크 정책을 수정한 다음 hello-allowed 포드를 새 네임스페이스로 이동합니다.

1. 먼저 기존 네트워크 정책을 삭제합니다.

kubectl delete -f ./manifests/network-policy.yaml

출력:

networkpolicy.networking.k8s.io "hello-server-allow-from-hello-client" deleted

2. 네임스페이스 버전을 만듭니다.

kubectl create -f ./manifests/network-policy-namespaced.yaml

출력:

networkpolicy.networking.k8s.io/hello-server-allow-from-hello-client created

3. 이제 기본 네임스페이스에서 hello-allowed-client 포드의 로그를 확인합니다.

kubectl logs --tail 10 -f $(kubectl get pods -oname -l app=hello)

더 이상 hello-server에 연결할 수 없습니다.

4. Ctrl+C를 눌러 종료합니다.

5. 마지막으로 hello-clients 앱의 두 번째 사본을 새 네임스페이스에 배포합니다.

kubectl -n hello-apps apply -f ./manifests/hello-app/hello-client.yaml

출력:

deployment.apps/hello-client-allowed created deployment.apps/hello-client-blocked created

완료된 작업 테스트

내 진행 상황 확인하기를 클릭하여 실행한 작업을 확인합니다. hello-clients 앱의 두 번째 복사본을 새 네임스페이스에 성공적으로 배포했다면 평가 점수가 표시됩니다.

새 네임스페이스에 hello-clients 앱의 두 번째 복사본 배포

작업 7. 검증

다음으로 두 개의 새 hello-app 클라이언트의 로그를 확인합니다.

1. 다음 명령어를 실행하여 hello-apps 네임스페이스의 앱에서 'hello' 라벨이 지정된 앱의 로그를 확인합니다.

kubectl logs --tail 10 -f -n hello-apps $(kubectl get pods -oname -l app=hello -n hello-apps)

출력:

Hostname: hello-server-6c6fd59cc9-7fvgp Hello, world! Version: 1.0.0 Hostname: hello-server-6c6fd59cc9-7fvgp Hello, world! Version: 1.0.0 Hostname: hello-server-6c6fd59cc9-7fvgp Hello, world! Version: 1.0.0 Hostname: hello-server-6c6fd59cc9-7fvgp Hello, world! Version: 1.0.0 Hostname: hello-server-6c6fd59cc9-7fvgp

Kubernetes 1.10.x부터 NetworkPolicy는 지정된 네임스페이스 내의 포드에 대한 액세스 제한을 지원하지 않기 때문에 두 클라이언트 모두 성공적으로 연결할 수 있습니다. 포드 라벨, 네임스페이스 라벨별로 허용 목록을 만들거나 둘의 합집합(즉, OR)을 허용 목록에 추가할 수 있습니다. 하지만 아직 포드 라벨과 네임스페이스 라벨의 교차점(즉, AND)을 허용 목록에 추가할 수는 없습니다.

2. Ctrl+C를 눌러 종료합니다.

작업 8. 삭제

Qwiklabs에서 이 실습에 사용된 모든 리소스를 종료하지만, 비용을 절감하고 클라우드를 효율적으로 사용하려면 자체 환경을 정리해야 합니다.

1. 배스천 호스트에서 로그아웃합니다.

exit

2. 다음을 실행하여 환경을 삭제합니다.

make teardown

출력:

...snip... google_compute_subnetwork.cluster-subnet: Still destroying... (ID: us-east1/kube-net-subnet, 20s elapsed) google_compute_subnetwork.cluster-subnet: Destruction complete after 25s google_compute_network.gke-network: Destroying... (ID: kube-net) google_compute_network.gke-network: Still destroying... (ID: kube-net, 10s elapsed) google_compute_network.gke-network: Still destroying... (ID: kube-net, 20s elapsed) google_compute_network.gke-network: Destruction complete after 26s Destroy complete! Resources: 5 destroyed.

작업 9. 사용자 환경에서 문제 해결

Terraform을 실행할 때 설치 스크립트가 '권한 거부' 오류와 함께 실패함

Terraform에서 사용하는 사용자 인증 정보에는 선택한 프로젝트에서 리소스를 만드는 데 필요한 권한이 없습니다. gcloud config list에 나열된 계정에 리소스를 생성하는 데 필요한 권한이 있는지 확인합니다. 권한이 있다면 gcloud auth application-default login을 사용하여 애플리케이션 기본 사용자 인증 정보를 재생성합니다.

Terraform 작업 중 잘못된 디지털 지문 오류

특정 리소스를 업데이트할 때 Terraform에서 잘못된 지문으로 인한 오류가 발생하는 경우가 있습니다.

아래 오류가 표시되면 명령어를 다시 실행하세요.

수고하셨습니다

네트워크 통신에 세부적인 제한을 적용하여 Kubernetes Engine의 보안을 개선했습니다.

다음 단계/더 학습하기

• Terraform Google 제공업체
• Kubernetes 네트워크 정책
• Kubernetes Engine - 클러스터 네트워크 정책 만들기
• Kubernetes Engine - 네트워크 정책 튜토리얼
• Kubernetes Engine - 클러스터 보안 강화

Google Cloud 교육 및 자격증

Google Cloud 기술을 최대한 활용하는 데 도움이 됩니다. Google 강의에는 빠른 습득과 지속적인 학습을 지원하는 기술적인 지식과 권장사항이 포함되어 있습니다. 기초에서 고급까지 수준별 학습을 제공하며 바쁜 일정에 알맞은 주문형, 실시간, 가상 옵션이 포함되어 있습니다. 인증은 Google Cloud 기술에 대한 역량과 전문성을 검증하고 입증하는 데 도움이 됩니다.

설명서 최종 업데이트: 2025년 2월 25일

실습 최종 테스트: 2025년 2월 25일

Copyright 2026 Google LLC. 이 소프트웨어는 사용 또는 목적에 대한 보증이나 진술 없이 있는 그대로 제공됩니다. 이 소프트웨어를 사용하는 경우 Google과의 계약이 적용됩니다.