개요

이 실습에서는 GKE 클러스터 내에 네임스페이스를 만든 다음, 역할 기반 액세스 제어를 사용해 관리자 외 사용자가 특정 네임스페이스에서 포드 작업을 할 수 있도록 허용합니다.

목표

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

• 사용자가 클러스터 리소스에 대한 액세스를 제어할 수 있도록 네임스페이스 만들기
• 네임스페이스 내에서 액세스를 제어할 수 있도록 역할 및 RoleBinding 만들기

참고: 이 실습에는 연결 세부정보 대화상자에서 사용할 수 있는 두 개의 사용자 이름이 프로비저닝되어 있습니다.

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

작업 1. 사용자가 클러스터 리소스에 액세스할 수 있도록 네임스페이스 만들기

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

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

Cloud Shell에서 시작할 때까지 기다리지 않고 즉시 다음 작업으로 진행해도 됩니다.

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

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

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

Cloud Shell에서 시작할 때까지 기다리지 않고 즉시 다음 작업으로 진행해도 됩니다.

실습 GKE 클러스터에 연결하기

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

참고: 사용자 이름 1의 Google Cloud 콘솔 탭에 있는지 확인합니다.

2. Cloud Shell에서 다음 명령어를 입력하여 영역 및 클러스터 이름의 환경 변수를 설정합니다.

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

5. Cloud Shell에서 다음 명령어를 입력하여 실습용 저장소를 실습용 Cloud Shell에 클론합니다.

git clone https://github.com/GoogleCloudPlatform/training-data-analyst

6. 작업 디렉터리로 연결되는 바로가기, 즉 소프트 링크를 생성합니다.

ln -s ~/training-data-analyst/courses/ak8s/v1.1 ~/ak8s

7. 이 실습의 샘플 파일이 포함된 디렉터리로 이동합니다.

cd ~/ak8s/RBAC/

네임스페이스 만들기

my-namespace.yaml이라는 매니페스트 파일이 생성되어 production이라는 새 네임스페이스를 만듭니다.

apiVersion: v1 kind: Namespace metadata: name: production

1. 다음 명령어를 사용하여 클러스터 내의 현재 네임스페이스를 나열합니다.

kubectl get namespaces

출력:

NAME STATUS AGE default Active 17m kube-node-lease Active 17m kube-public Active 17m kube-system Active 17m

2. Cloud Shell에서 다음 명령어를 실행하여 새 네임스페이스를 만듭니다.

kubectl create -f ./my-namespace.yaml

3. 다음 명령어로 네임스페이스가 생성된 것을 확인합니다.

kubectl get namespaces

출력:

NAME STATUS AGE default Active 6m kube-node-lease Active 6m kube-public Active 6m kube-system Active 6m production Active 4s

새 네임스페이스가 목록의 하단에 표시됩니다.

4. 다음을 실행하여 기존 네임스페이스의 세부정보를 확인할 수 있습니다.

kubectl describe namespaces production

출력:

Name: production Labels: Annotations: Status: Active Resource Quotas Name: gke-resource-quotas Resource Used Hard -------- --- --- count/ingresses.extensions 0 100 count/jobs.batch 0 5k pods 0 1500 services 0 500 No LimitRange resource.

네임스페이스에서 리소스 만들기

포드의 네임스페이스를 지정하지 않으면 '기본' 네임스페이스가 사용됩니다. 이 작업에서는 새 포드 생성 시 새로 만들어지는 네임스페이스의 위치를 지정합니다. my-pod.yaml이라는 간단한 매니페스트 파일은 포드를 생성하며 이 포드는 이미 만들어진 nginx 컨테이너를 포함합니다.

apiVersion: v1 kind: Pod metadata: name: nginx labels: name: nginx spec: containers: - name: nginx image: nginx ports: - containerPort: 80

1. Cloud Shell에서 다음 명령어를 실행하여 production이라는 네임스페이스에서 리소스를 만듭니다.

kubectl apply -f ./my-pod.yaml --namespace=production

또는 yaml 파일에서 네임스페이스를 지정할 수 있습니다. 이를 위해서는 metadata: 섹션의 namespace: production 필드가 필요합니다.

예를 들면 다음과 같습니다.

apiVersion: v1 kind: Pod metadata: name: nginx labels: name: nginx namespace: production spec: containers: - name: nginx image: nginx ports: - containerPort: 80

2. 다음 명령어를 사용하여 포드를 확인해 봅니다.

kubectl get pods

출력:

No resources found in default namespace.

kubectl에서 새 네임스페이스가 아닌 기본 네임스페이스를 확인했으므로 해당 포드가 표시되지 않습니다.

3. 명령어를 다시 실행하여 이번에는 새 네임스페이스를 지정합니다.

kubectl get pods --namespace=production

출력:

NAME READY STATUS RESTARTS AGE nginx 1/1 Running 0 20s

이제 새로 생성된 포드를 확인할 수 있습니다.

내 진행 상황 확인하기를 클릭하여 목표를 확인합니다.

Create namespace and pod

작업 2. 역할 및 RoleBinding

이 작업에서는 샘플 맞춤 역할을 생성한 다음 RoleBinding을 만들어 사용자 이름 2에 프로덕션 네임스페이스의 편집자 역할을 부여합니다.

이 역할은 사용자에게 제공되는 pod-reader-role.yaml 파일에서 정의됩니다. 이 매니페스트는 production 네임스페이스에서 포드 객체에 대한 만들기, 가져오기, 나열, 확인 권한을 제공하는 pod-reader 역할을 정의합니다. 이 역할은 포드를 삭제할 수 없다는 점에 유의하세요.

kind: Role apiVersion: rbac.authorization.k8s.io/v1 metadata: namespace: production name: pod-reader rules: - apiGroups: [""] resources: ["pods"] verbs: ["create", "get", "list", "watch"]

맞춤 역할 만들기

Role을 만들려면 할당되는 역할에 부여할 권한이 사용자의 계정에 있어야 합니다. 클러스터 관리자의 경우, 다음 RoleBinding을 만들어 자신의 사용자 계정에 클러스터 관리 역할을 부여함으로써 이를 쉽게 수행할 수 있습니다.

1. 사용자 이름 1 계정에 클러스터 관리자 권한을 부여하기 위해 다음 명령어에서 [USERNAME_1_EMAIL]을 사용자 이름 1 계정의 이메일 주소로 바꾸어 명령어를 실행합니다.

kubectl create clusterrolebinding cluster-admin-binding --clusterrole cluster-admin --user [USERNAME_1_EMAIL]

출력 예시:

kubectl create clusterrolebinding cluster-admin-binding --clusterrole cluster-admin --user gcpstaging28307_student@qwiklabs.net

2. Cloud Shell에서 다음 명령어를 사용하여 역할을 만듭니다.

kubectl apply -f pod-reader-role.yaml

3. 다음 명령어를 실행해 역할을 나열하고 해당 역할이 만들어진 것을 확인합니다.

kubectl get roles --namespace production

출력:

NAME AGE pod-reader 3m

RoleBinding 만들기

역할은 권한 할당을 위해 사용되지만 그 자체로는 아무것도 하지 못합니다. 역할은 사용자 및 객체에 연결되어야 하며 해당 작업은 RoleBinding에서 수행됩니다.

username2-editor-binding.yaml 매니페스트 파일은 username2-editor라는 RoleBinding을 만들고 두 번째 실습 사용자는 이전에 만든 pod-reader 역할에 연결됩니다. 이 역할은 포드를 생성하고 확인할 수는 있지만 포드를 삭제할 수는 없습니다.

kind: RoleBinding apiVersion: rbac.authorization.k8s.io/v1 metadata: name: username2-editor namespace: production subjects: - kind: User name: [USERNAME_2_EMAIL] apiGroup: rbac.authorization.k8s.io roleRef: kind: Role name: pod-reader apiGroup: rbac.authorization.k8s.io

이 파일은 자리표시자 [USERNAME_2_EMAIL]을 포함하며 적용하기 전에 사용자 이름 2의 이메일 주소로 바꿔야 합니다.

1. Cloud Shell에서 사용자 이름 2의 전체 이메일 주소를 포함하는 환경 변수를 만듭니다.

export USER2=[USERNAME_2_EMAIL]

출력 예시:

export USER2=gcpstaginguser68_student@qwiklabs.net

2. Cloud Shell에서 sed를 사용해 파일 내 자리표시자를 해당 환경 변수 값으로 바꿉니다.

sed -i "s/\[USERNAME_2_EMAIL\]/${USER2}/" username2-editor-binding.yaml

3. Cloud Shell에서 다음 명령어를 실행하여 수정이 올바로 이루어졌는지 확인합니다.

cat username2-editor-binding.yaml

이제 제목 섹션은 다음과 유사하게 표시됩니다.

출력 예시:

subjects: - kind: User name: gcpstaginguser68_student@qwiklabs.net apiGroup: rbac.authorization.k8s.io

나중에 이 RoleBinding을 적용하게 됩니다.

액세스 테스트하기

이제 사용자 이름 2로 매니페스트 파일 production-pod.yaml을 사용해 포드를 생성하여 사용자 이름 2가 프로덕션 네임스페이스에서 포드를 생성할 수 있는지 테스트합니다. 이 매니페스트는 단일 nginx 컨테이너가 포함된 간단한 포드를 배포합니다.

apiVersion: v1 kind: Pod metadata: name: production-pod labels: name: production-pod namespace: production spec: containers: - name: production-pod image: nginx ports: - containerPort: 8080

이는 별도의 사용자 계정이므로 클러스터 및 실습용 저장소의 샘플 파일에 액세스할 수 있도록 Cloud Shell 환경을 다시 한번 준비해야 합니다.

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

참고: 사용자 이름 2의 Google Cloud 콘솔 탭에 있는지 확인합니다.

2. 사용자 이름 2의 Cloud Shell에서 다음 명령어를 입력하여 해당 영역의 환경 변수 및 클러스터 이름을 설정합니다.

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

5. Cloud Shell에서 다음 명령어를 입력하여 실습용 저장소를 실습용 Cloud Shell에 다음과 같이 클론합니다.

git clone https://github.com/GoogleCloudPlatform/training-data-analyst

6. 작업 디렉터리로 연결되는 바로가기, 즉 소프트 링크를 생성합니다.

ln -s ~/training-data-analyst/courses/ak8s/v1.1 ~/ak8s

7. 이 실습의 샘플 파일이 포함된 디렉터리로 이동합니다.

cd ~/ak8s/RBAC/

8. 다음 명령어를 사용하여 사용자 이름 2로 프로덕션 네임스페이스를 볼 수 있는지 확인합니다.

kubectl get namespaces

출력:

NAME STATUS AGE default Active 29m kube-node-lease Active 29m kube-public Active 29m kube-system Active 29m production Active 23m

프로덕션 네임스페이스가 목록의 하단에 표시되므로 계속 진행할 수 있습니다.

9. Cloud Shell에서 다음 명령어를 실행하여 production이라는 네임스페이스에서 리소스를 만듭니다.

kubectl apply -f ./production-pod.yaml

이 작업은 실패하게 되며, 사용자 이름 2에게 올바른 권한이 없어 포드를 생성하지 못했음이 표시됩니다. 현재로서는 사용자 이름 2가 해당 계정에 역할을 할당받지 못했으므로, 실습 시작 시 보유했던 보기 권한만 보유합니다. 이제 이를 변경하게 됩니다.

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

참고: 사용자 이름 1의 Google Cloud 콘솔 탭에 있는지 확인합니다.

11. 사용자 이름 1의 Cloud Shell에서 다음 명령어를 실행하여, production 네임스페이스에서 포드를 생성할 권한이 포함된 pod-reader 역할을 사용자 이름 2에 부여하는 RoleBinding을 만듭니다.

kubectl apply -f username2-editor-binding.yaml

12. 사용자 이름 1의 Cloud Shell에서 다음 명령어를 실행하여 새 역할 바인딩을 탐색합니다.

kubectl get rolebinding

출력:

No resources found in default namespace.

kubectl이 기본 네임스페이스를 표시하므로 역할 바인딩이 표시되지 않습니다.

13. 사용자 이름 1의 Cloud Shell에서 프로덕션 네임스페이스를 지정하여 다음 명령어를 실행합니다.

kubectl get rolebinding --namespace production

출력:

NAME AGE username2-editor 23s

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

참고: 사용자 이름 2의 Google Cloud 콘솔 탭에 있는지 확인합니다.

15. 사용자 이름 2의 Cloud Shell에서 다음 명령어를 실행하여 프로덕션이라는 네임스페이스에서 리소스를 생성합니다.

kubectl apply -f ./production-pod.yaml

이제 사용자 이름 2가 production 네임스페이스에서 포드에 대한 만들기 권한을 보유하므로 이 작업은 성공적으로 완료됩니다.

16. 다음 명령어를 사용하여 포드가 프로덕션 네임스페이스에 적절히 배포되어 있는지 확인합니다.

kubectl get pods --namespace production

출력:

NAME READY STATUS RESTARTS AGE nginx 1/1 Running 0 16m production-pod 1/1 Running 0 20s

새로 생성된 포드를 확인할 수 있습니다.

17. production-pod를 삭제하여 pod-reader 역할이 부여한 특정 RBAC 권한만이 사용자 이름 2에 적용되는지 확인합니다.

kubectl delete pod production-pod --namespace production

사용자 이름 2가 포드에 대한 삭제 권한을 보유하지 않으므로 이 작업은 실패합니다.

내 진행 상황 확인하기를 클릭하여 목표를 확인합니다.

Roles and RoleBindings

실습 종료하기

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

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

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

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

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

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

Copyright 2020 Google LLC All rights reserved. Google 및 Google 로고는 Google LLC의 상표입니다. 기타 모든 회사명 및 제품명은 해당 업체의 상표일 수 있습니다.