개요

IAM을 사용하여 GKE 클러스터에 대한 액세스를 제어합니다. 권한이 있는 포드 생성을 제한하는 포드 보안 정책을 만들고 테스트합니다. 또한 IP 주소 및 사용자 인증 정보 순환을 수행합니다.

참고: 이 실습에서는 GKE Standard 모드를 사용합니다. 또한 포드 보안 정책을 따르며 GKE Autopilot의 기본 제공 보안 설정을 재정의하는 정책은 만들 수 없습니다.

목표

이 실습에서는 다음 작업을 수행하는 방법을 알아봅니다.

• IAM을 사용하여 GKE 액세스 제어하기
• 포드 보안 정책을 만들고 사용하여 포드 생성 제어하기
• IP 주소 및 사용자 인증 정보 순환 수행하기

참고: 이 실습을 위해 Google Cloud Skills Boost는 연결 세부정보 대화상자에서 확인할 수 있는 두 개의 사용자 이름을 프로비저닝했습니다.

이 실습에서는 이러한 두 계정을 각각 사용자 이름 1과 사용자 이름 2로 지칭합니다.

작업 1: IAM 역할을 사용하여 프로젝트의 모든 GKE 클러스터에 대한 관리 액세스 권한 부여하기

첫 번째 사용자로 Google Cloud 콘솔에 로그인하기

1. 시크릿 창에서 Google Cloud 콘솔에 평소처럼 로그인하되 제공된 사용자 이름 1을 사용합니다. 두 사용자 이름 모두 동일한 비밀번호를 사용한다는 점에 유의합니다.
2. Google Cloud 콘솔 제목 표시줄에서 Cloud Shell 활성화()를 클릭합니다.
3. 계속을 클릭합니다.

프로비저닝이 완료되면 Cloud Shell 프롬프트가 표시됩니다.

참고: 사용자 이름 1 계정에서 로그아웃하면 사용자 이름 2 계정이 Google Cloud Skills Boost에서 삭제될 수 있습니다. 따라서 이 실습을 마칠 때까지 사용자 이름 1에 로그인한 상태를 유지하세요.

두 번째 사용자로 Google Cloud 콘솔에 로그인 및 탐색하기

1. 시크릿 창에서 다른 탭을 엽니다.
2. console.cloud.google.com으로 이동합니다.
3. 화면의 오른쪽 상단에 있는 사용자 아이콘을 클릭한 다음 계정 추가를 클릭합니다.
4. 제공된 사용자 이름 2로 Google Cloud 콘솔에 로그인합니다. 두 사용자 이름 모두 동일한 비밀번호를 사용한다는 점에 다시 한번 유의합니다.

참고: 사용자 이름 2 Google Cloud 콘솔 탭이 표시되었는지 확인합니다.

5. 사용자 이름 2로 로그인한 상태에서 탐색 메뉴()에서 Kubernetes Engine > 클러스터를 클릭합니다.

6. 페이지 상단에서 실습 프로젝트 ID가 선택되어 있는지 확인합니다.

클러스터를 만드는 옵션이 사용 중지되어 있는 것을 볼 수 있습니다.

참고: 사용자 이름 2는 현재 프로젝트에 액세스할 수 있으나 뷰어 역할만 보유하고 있습니다. 따라서 프로젝트의 모든 리소스가 표시되기는 하지만 읽기 전용으로만 액세스할 수 있습니다.

사용자 이름 2에 GKE 관리자 IAM 역할 부여하기

이제 사용자 이름 2가 기본 역할을 사용해 GKE 클러스터를 만들고 워크로드를 배포할 수 있도록 허용하여, 사용자에게 모든 GKE 클러스터를 관리하고 이 프로젝트의 해당 클러스터 내 리소스를 관리할 권한을 부여합니다. 프로젝트 소유자 권한을 보유하고 있는 사용자 이름 1 계정을 사용하여 사용자 이름 2에 추가 권한을 부여합니다.

1. 사용자 이름 1 Google Cloud 콘솔 탭으로 다시 전환합니다.

참고: 사용자 이름 1 Google Cloud 콘솔 탭이 표시되었는지 확인합니다.

2. 탐색 메뉴()에서 IAM 및 관리자 > IAM을 클릭합니다.

3. IAM 콘솔에서 사용자 이름 2에 해당하는 행을 찾은 다음 해당 행의 오른쪽 끝에 있는 연필 아이콘을 클릭하여 사용자의 권한을 편집합니다.

4. 현재 사용자 이름 2에는 프로젝트 내의 모든 리소스에 대한 읽기 액세스 권한을 제공하는 뷰어 역할이 있습니다.

5. 다른 역할 추가를 클릭하여 드롭다운에서 다른 역할을 선택하여 추가합니다.

6. 역할 선택 드롭다운 상자에서 Kubernetes Engine > Kubernetes Engine 클러스터 관리자를 선택합니다.

7. 저장을 클릭합니다.

참고: 이제 사용자 이름 2에는 프로젝트의 모든 GKE 클러스터를 관리하고 해당 클러스터 내의 리소스를 관리할 수 있는 액세스 권한이 있습니다.

조직에서 사용하기에 이 액세스 권한 수준이 너무 광범위하면 Kubernetes 역할 기반 액세스 제어를 사용하여 GKE 클러스터 내에서 사용자의 권한을 제한할 수 있습니다.

내 진행 상황 확인하기를 클릭하여 목표를 확인합니다. 사용자 이름 2에 GKE 관리자 IAM 역할 부여하기

사용자 이름 2의 액세스 테스트하기

이제 사용자 이름 2를 사용하여 GKE 클러스터를 생성해 작업한 내용을 확인하겠습니다.

1. 사용자 이름 2 Google Cloud 콘솔 탭으로 다시 전환합니다.

참고: 사용자 이름 2 Google Cloud 콘솔 탭이 표시되었는지 확인합니다.

2. 사용자 이름 2로 로그인한 상태에서 탐색 메뉴()에서 Kubernetes Engine > 클러스터를 클릭합니다.

이제 클러스터 생성 옵션이 사용 설정된 것을 볼 수 있습니다. 변경 사항을 보려면 사용자 이름 2의 웹브라우저 탭을 새로고침해야 할 수 있습니다.

3. 만들기를 클릭하여 GKE 클러스터를 만들기 시작합니다.

4. Standard 클러스터로 전환을 클릭하고 다음 팝업에서 이를 확인합니다.

주의: 이 실습에서는 GKE Standard 모드를 사용해야 합니다.

5. 클러스터 이름을 standard-cluster-1(기본값이 아닌 경우)로 설정합니다.

6. 리전 클러스터가 아니라 영역 클러스터가 선택되었는지 확인합니다.

7. 기본값이 아닌 경우 클러스터에 대해 영역을 선택합니다.

8. 다른 모든 값을 기본값으로 두고 만들기를 클릭합니다.

클러스터가 프로비저닝을 시작하지만 곧 실패합니다.

참고: 이 실습 단계의 실패는 의도된 것입니다.

9. 화면 상단의 툴바에서 알림 아이콘을 클릭하여 오류 메시지를 확인합니다.

사용자 이름 2에는 여전히 클러스터를 배포하는 데 필요한 일부 권한이 없습니다. 이는 GKE가 노드에 Google Cloud Compute Engine 인스턴스를 활용하기 때문입니다.

GKE 클러스터를 배포하려면 사용자에게 Compute Engine 기본 서비스 계정의 iam.serviceAccountUser 역할도 할당되어야 합니다.

사용자 이름 2에 ServiceAccountUser IAM 역할 부여하기

이제 사용자 이름 2가 GKE 클러스터를 성공적으로 배포할 수 있도록 IAM을 사용하여 사용자 이름 2에 iam.serviceAccountUser 역할을 부여하겠습니다.

1. 사용자 이름 1 Google Cloud 콘솔 탭으로 다시 전환합니다.

참고: 사용자 이름 1 Google Cloud 콘솔 탭이 표시되었는지 확인합니다.

2. 탐색 메뉴()에서 IAM 및 관리자 > 서비스 계정을 클릭합니다.

3. IAM 콘솔에서 Compute Engine 기본 서비스 계정에 해당하는 행을 클릭하여 선택합니다.

4. 권한을 클릭하여 권한 정보 패널을 엽니다.

5. 권한 페이지에서 액세스 권한 부여를 클릭합니다.

창 오른쪽에 권한 정보 패널이 열립니다.

6. 새 주 구성원 상자에 사용자 이름 2의 사용자 이름을 입력합니다. 이 이름은 실습 세부정보 페이지에서 복사할 수 있습니다.
7. 역할 선택 상자에서 서비스 계정 > 서비스 계정 사용자가 선택되어 있는지 확인합니다.
8. 저장을 클릭합니다.

내 진행 상황 확인하기를 클릭하여 목표를 확인합니다. 사용자 이름 2에 서비스 계정 사용자 IAM 역할 부여하기

사용자 이름 2가 GKE 클러스터를 만들 수 있는지 확인하기

이제 사용자 이름 2를 사용하여 GKE 클러스터를 생성해 작업한 내용을 확인하겠습니다.

1. 사용자 이름 2 Google Cloud 콘솔 탭으로 다시 전환합니다.

참고: 사용자 이름 2 Google Cloud 콘솔 탭이 표시되었는지 확인합니다.

2. 사용자 이름 2로 로그인한 상태에서 탐색 메뉴()에서 Kubernetes Engine > 클러스터를 클릭합니다. 웹브라우저를 새로고침해야 할 수 있습니다.

3. 만들기를 클릭하여 GKE 클러스터를 만들기 시작합니다.

4. Standard 클러스터로 전환을 클릭하고 다음 팝업에서 이를 확인합니다.

5. 클러스터 이름의 기본값이 standard-cluster-1이 아닌 경우 이렇게 설정합니다.

6. 리전 클러스터가 아니라 영역 클러스터가 선택되었는지 확인합니다.

7. 기본값이 아닌 경우 클러스터에 대해 영역을 선택합니다.

8. 다른 모든 값을 기본값으로 두고 만들기를 클릭합니다.

참고: 클러스터 배포가 완료될 때까지 몇 분 정도 기다려야 합니다.

이번에는 클러스터가 성공적으로 배포됩니다.

내 진행 상황 확인하기를 클릭하여 목표를 확인합니다. GKE 클러스터 만들기

작업 2. 포드 보안 허용 정의 및 사용하기

PodSecurity는 GKE 클러스터에서 실행되는 포드에 포드 보안 표준을 적용할 수 있는 Kubernetes 허용 컨트롤러입니다. 포드 보안 표준은 Kubernetes에서 포드 보안의 고급 요구사항을 다루는 사전 정의된 보안 정책입니다. 이러한 정책은 매우 허용적인 정책부터 매우 제한적인 정책까지 다양합니다.

이 작업에서는 클러스터의 기본 네임스페이스에서 권한이 없는 포드 생성을 허용하는 포드 보안 정책을 만듭니다. 권한이 없는 포드는 사용자가 루트로 코드를 실행하는 것을 허용하지 않으며 호스트의 기기에 대해 제한된 액세스 권한을 가집니다.

그런 다음 권한이 없는 액세스로 포드를 배포할 수 있는 기능이 필요한 계정에 정책을 연결하는 역할 바인딩에 사용할 수 있는 ClusterRole을 생성합니다.

권한이 있는 포드를 배포할 수 있는 기능이 필요한 사용자는 포드 보안 정책이 사용 설정된 후 관리자가 포드를 배포할 수 있도록 제공되는 기본 제공 PSP에 대한 액세스 권한을 부여받을 수 있습니다.

구성요소를 설정한 뒤 이러한 정책을 적용하는 PodSecurityPolicy 컨트롤러를 사용 설정한 다음 다른 권한이 있는 사용자에게 미치는 영향을 테스트합니다.

GKE 클러스터에 연결

1. 사용자 이름 1 Google Cloud 콘솔 탭으로 다시 전환합니다.

참고: 사용자 이름 1 Google Cloud 콘솔 탭이 표시되었는지 확인합니다.

2. Cloud Shell에서 다음 명령어를 입력하여 이 실습에서의 클러스터를 생성하기 위해 사용한 Google Cloud 영역 및 클러스터 이름의 환경 변수를 생성합니다.

export my_zone={{{project_0.default_zone | ZONE }}} export my_cluster=standard-cluster-1

3. 다음과 같이 kubectl 명령줄 도구의 명령줄 자동 완성 기능을 구성합니다.

source <(kubectl completion bash)

4. 다음과 같이 kubectl의 클러스터에 대한 액세스 권한을 구성합니다.

gcloud container clusters get-credentials $my_cluster --zone $my_zone

PodSecurity를 사용하여 포드 보안 표준 적용

PodSecurity 허용 컨트롤러를 사용하려면 특정 모드의 특정 포드 보안 표준을 특정 네임스페이스에 적용해야 합니다.

새 네임스페이스 생성

클러스터에 네임스페이스를 만듭니다.

kubectl create ns baseline-ns kubectl create ns restricted-ns

이 명령어는 다음 네임스페이스를 만듭니다.

• baseline-ns: 허용적인 워크로드용
• restricted-ns: 매우 제한적인 워크로드용

라벨을 사용하여 보안 정책 적용

다음 포드 보안 표준을 적용합니다.

• 기준: 경고 모드에서 baseline-ns에 적용
• 제한: 시행 모드에서 restricted-ns에 적용

kubectl label --overwrite ns baseline-ns pod-security.kubernetes.io/warn=baseline kubectl label --overwrite ns restricted-ns pod-security.kubernetes.io/enforce=restricted

이러한 명령어는 다음과 같은 결과를 생성합니다.

• 기준 정책을 위반하는 baseline-ns 네임스페이스의 워크로드가 허용되며 클라이언트가 경고 메시지를 표시합니다.
• 제한 정책을 위반하는 restricted-ns 네임스페이스의 워크로드가 거부되며 GKE가 감사 로그에 항목을 추가합니다.

라벨이 추가되었는지 확인합니다.

kubectl get ns --show-labels

출력은 다음과 비슷합니다.

baseline-ns Active 74s kubernetes.io/metadata.name=baseline-ns,pod-security.kubernetes.io/warn=baseline restricted-ns Active 18s kubernetes.io/metadata.name=restricted-ns,pod-security.kubernetes.io/enforce=restricted default Active 57m kubernetes.io/metadata.name=default kube-public Active 57m kubernetes.io/metadata.name=kube-public kube-system Active 57m kubernetes.io/metadata.name=kube-system

내 진행 상황 확인하기를 클릭하여 목표를 확인합니다. 네임스페이스와 라벨 만들기

구성된 정책 테스트

PodSecurity 허용 컨트롤러가 의도한 대로 작동하는지 확인하려면 기준 및 제한 정책을 위반하는 워크로드를 두 네임스페이스 모두에 배포합니다. 다음 매니페스트 예시에서는 권한 에스컬레이션을 허용하는 nginx 컨테이너를 배포합니다.

1. 다음 명령어를 사용하여 nano로 psa-workload.yaml이라는 파일을 만들고 엽니다.

nano psa-workload.yaml

2. nano가 열리면 다음 사항을 psa-workload.yaml 파일에 붙여넣습니다.

apiVersion: v1 kind: Pod metadata: name: nginx labels: app: nginx spec: containers: - name: nginx image: nginx securityContext: privileged: true

3. Ctrl+O 키를 누른 다음 Enter 키를 눌러 수정한 파일을 저장합니다.

4. Ctrl+X 키를 눌러 nano 텍스트 편집기를 종료합니다.

5. baseline-ns 네임스페이스에 매니페스트를 적용합니다.

kubectl apply -f psa-workload.yaml --namespace=baseline-ns

출력은 다음과 비슷합니다.

Warning: would violate PodSecurity "baseline:latest": privileged (container "nginx" must not set securityContext.privileged=true) pod/nginx created

기준 정책을 사용하면 포드가 네임스페이스에서 배포할 수 있습니다.

6. 포드가 성공적으로 배포했는지 확인합니다.

kubectl get pods --namespace=baseline-ns -l=app=nginx

7. restricted-ns 네임스페이스에 매니페스트를 적용합니다.

kubectl apply -f psa-workload.yaml --namespace=restricted-ns

출력은 다음과 비슷합니다.

Error from server (Forbidden): error when creating "workload.yaml": pods "nginx" is forbidden: violates PodSecurity "restricted:latest": allowPrivilegeEscalation != false (container "nginx" must set securityContext.allowPrivilegeEscalation=false), unrestricted capabilities (container "nginx" must set securityContext.capabilities.drop=["ALL"]), runAsNonRoot != true (pod or container "nginx" must set securityContext.runAsNonRoot=true), seccompProfile (pod or container "nginx" must set securityContext.seccompProfile.type to "RuntimeDefault" or "Localhost")

포드가 네임스페이스에서 배포하지 않습니다. 감사 항목이 로그에 추가됩니다.

내 진행 상황 확인하기를 클릭하여 목표를 확인합니다. 'restricted-ns' 네임스페이스에 매니페스트를 적용합니다

감사 로그에서 정책 위반 확인

감사 및 시행 모드의 정책 위반은 클러스터 감사 로그에 기록됩니다. Google Cloud 콘솔의 로그 탐색기를 사용하여 이러한 로그를 볼 수 있습니다.

1. Google Cloud 콘솔 제목 표시줄의 검색창에 로그 탐색기를 입력한 다음 검색 결과에서 로그 탐색기를 클릭합니다.

2. 쿼리 필드에 다음을 입력합니다.

resource.type="k8s_cluster" protoPayload.response.reason="Forbidden" protoPayload.resourceName="core/v1/namespaces/restricted-ns/pods/nginx"

3. 쿼리 실행을 클릭합니다.

4. 쿼리 결과 섹션에서 '금지됨' 로그 항목을 확장합니다. 세부정보는 다음과 비슷합니다.

{ ... protoPayload: { @type: "type.googleapis.com/google.cloud.audit.AuditLog" authenticationInfo: {1} authorizationInfo: [1] methodName: "io.k8s.core.v1.pods.create" request: {6} requestMetadata: {2} resourceName: "core/v1/namespaces/restricted-ns/pods/nginx" response: { @type: "core.k8s.io/v1.Status" apiVersion: "v1" code: 403 details: {2} kind: "Status" message: "pods "nginx" is forbidden: violates PodSecurity "restricted:latest": privileged (container "nginx" must not set securityContext.privileged=true), allowPrivilegeEscalation != false (container "nginx" must set securityContext.allowPrivilegeEscalation=false), unrestricted capabilities (container "nginx" must set securityContext.capabilities.drop=["ALL"]), runAsNonRoot != true (pod or container "nginx" must set securityContext.runAsNonRoot=true), seccompProfile (pod or container "nginx" must set securityContext.seccompProfile.type to "RuntimeDefault" or "Localhost")" metadata: {0} reason: "Forbidden" status: "Failure" } serviceName: "k8s.io" status: {2} } receiveTimestamp: "2022-12-01T19:19:25.353235326Z" resource: {2} timestamp: "2022-12-01T19:19:21.469360Z" }

(선택사항) 작업 3. IP 주소 및 사용자 인증 정보 순환

클러스터에서 IP 및 사용자 인증 정보 순환을 수행합니다. 사용자 인증 정보의 수명을 줄이기 위해 정기적으로 순환을 수행하는 것이 안전합니다. 제공 IP와 사용자 인증 정보를 순환하는 별도의 명령어가 있지만 사용자 인증 정보를 순환하면 IP도 추가로 순환됩니다.

1. Cloud Shell에서 다음 명령어를 실행합니다.

gcloud container clusters update $my_cluster --zone $my_zone --start-credential-rotation

2. Y를 입력하고 계속 진행합니다.
3. 작업이 완료될 때까지 Cloud Shell을 열어 둡니다.

Cloud Shell에서 명령어가 완료되면 클러스터는 각 노드를 업데이트하는 프로세스를 시작합니다. 클러스터가 이 프로세스를 완료하는 데 최대 15분 정도 소요될 수 있습니다. 이 프로세스는 현재 사용자의 kubeconfig 항목도 자동으로 업데이트합니다.

4. 이제 클러스터 마스터는 원래 주소와 더불어 새 IP 주소를 임시로 제공합니다.

참고: 액세스 권한을 유지하려면 순환 프로세스를 완료하기 전에 kubectl 또는 API를 사용하여 마스터에 액세스하는 다른 시스템에서 kubeconfig 파일을 업데이트해야 합니다.

5. 다음 명령어를 실행하여 사용자 인증 정보 및 IP 순환 작업을 완료합니다.

gcloud container clusters update $my_cluster --zone $my_zone --complete-credential-rotation

이렇게 하면 순환 프로세스가 마무리되고 원래 클러스터 IP 주소가 삭제됩니다.

참고: 사용자 인증 정보 순환이 완료되지 않고 오류 메시지가 반환되면 다음 명령어를 실행하세요. gcloud container clusters upgrade $my_cluster --node-pool=default-pool --zone $my_zone

6. Y를 입력하고 계속 진행합니다.

7. 클러스터가 성공적으로 업그레이드되면 다음 명령어를 다시 실행하세요.

gcloud container clusters update $my_cluster --zone $my_zone --complete-credential-rotation

실습 종료하기

실습을 완료하면 실습 종료를 클릭합니다. Google Cloud Skills Boost에서 사용된 리소스를 자동으로 삭제하고 계정을 지웁니다.

실습 경험을 평가할 수 있습니다. 해당하는 별표 수를 선택하고 의견을 입력한 후 제출을 클릭합니다.

별점의 의미는 다음과 같습니다.

• 별표 1개 = 매우 불만족
• 별표 2개 = 불만족
• 별표 3개 = 중간
• 별표 4개 = 만족
• 별표 5개 = 매우 만족

의견을 제공하고 싶지 않다면 대화상자를 닫으면 됩니다.

의견이나 제안 또는 수정할 사항이 있다면 지원 탭을 사용하세요.