[GCP] IAM에 대해 알아보자(2)- 기본 사용법

이전 포스팅에서는 Cloud SDK를 설치 했었다. 이제는 IAM을 간단하게 사용해보기로 하자. 그래도 막무가내로 하는 것 보다는 목표를 정하는 것이 좋으니 다음과 같은 상황이라 생각하고 실습을 해보자.

 

다른 개발 부서에서 GCP에 어플리케이션을 배포하고 테스트하기 위헤 권한을 부여해달라는 요청을 받았다.   

간단한 주문이다. 일단 CI/CD나 네트워크 설정 및 방화벽은 생각하지 않기로 하고 진행해보자. 그럼 다음과 같은 요소들을 생각할 수 있다.

 

1. 다른 개발부서의 개발자들이 VM에 접속할 수 있어야 함.  

2. 개발자들이 파일 업로드(배포)도 할 수 있어야 함.

3. 배포한 어플리케이션이 필요에 따라 다른 리소스에 접근할 수 있어야 함.

 

위 내용들을 하나식 해결해보도록 하자. 진행은 SDK로 진행할 것인데, Cloud Console 대신 SDK로 진행하는 이유는 사용한 명령어들을 잘 기록해 두면 나중에 일관성 있는 인프라를 구축할 수 있기 때문이다. 물론 그렇게 따지면 Terraform을 사용해서 IaC를 하는 것이 가장 좋지만, 지금은 Terraform까지 다루면 양이 너무 많아지니 나중에 따로 포스팅 하도록 하고 지금은 SDK를 사용한다. 그리고 SDK를 사용해 구축한 히스토리를 잘 보관해두면 Terraform 코드를 작성할 때 아주아주 편하다. 

 

사전 작업

 저번 포스팅에서는 SDK를 설치만 해둔 상태이다. 아래 명령어로 계정 설정을 하도록 하자. 

$ gcloud auth login <ACCOUNT>
Go to the following link in your browser:

 ...
 
 Enter verification code:

gcloud auth login 명령어는 말 그대로 로그인을 하는 명령어이다. <ACCOUNT>에 GCP에서 사용하는 google 계정을 입력하면 대뜸 링크 하나를 출력해준다. 링크를 열면 google 로그인 페이지가 출력되는데 <ACCOUNT>로 입력한 계정으로 로그인하면 코드를 하나 발급해준다. 그것을 그대로 복사해와서 Enter verification code에 입력해주면 로그인이 된다. 

$ gcloud config set account <ACCOUNT>
Updated property [core/account]

gcloud config set account 명령어는 인증에 사용할 계정을 설정하는 것이다. 아마 처음으로 로그인 했다면 기본으로 로그인한 계정이 인증계정이 될텐데, 만약에 gcloud로 로그인 된 계정이 여러개일 경우 위 명령어로 사용할 계정을 선택해줄 수 있다. 선택된 계정을 확인해보고 싶다면 아래처럼 gcloud auth list 명령어를 입력해보자.

$ gcloud auth list
Credentialed Accounts
ACTIVE  ACCOUNT
   *    <ACCOUNT>

마지막으로 기본 프로젝트 설정을 해주어야한다. 만약에 기본 프로젝트를 설정하지 않으면 매번 명령어를 입력할 때마다 옵션으로 프로젝트를 명시해줘야 한다. 아래처럼 gcloud config set project를 입력하자. 중요한 것은 <PROJECT_ID>에 프로젝트 이름이 아닌 프로젝트 ID를 입력해야 한다는 것이다.

$ gcloud projects list 
PROJECT_ID         NAME               PROJECT_NUMBER
<PROJECT_NAME>     <PROJECT_ID>       384574098861

$ gcloud config set project <PROJECT_ID>
Updated property [core/project].

기본적으로 프로젝트를 생성하면 프로젝트 이름과 프로젝트 ID가 동일하지만 기존 프로젝트가 존재하는 상태에서 똑같은 이름의 프로젝트를 생성하면 자동으로 ID 뒤에 랜덤 숫자를 붙여버린다.

 

예를 들면 test-project라는 이름의 프로젝트를 처음 만들면 ID도 test-project가 되지만 같은 이름으로 프로젝트를 또 만들면 이름은 test-project 그대로 똑같이 생성되나 ID는 test-project-123455 이런식으로 생성된다.

 

뭐 당연한 걸 말하고 있나 싶지만 이게 조직이 커지면 실수로 이름이 중복되는 프로젝트를 종종 만드는데, GCP의 경우 프로젝트를 조직 -> 폴더 -> 프로젝트 이런식으로 관리하기 때문에 폴더나 조직(부서)이 다르다면 티가 잘 안난다. 그래서 종종 다른 부서에서 프로젝트를 잘못 설정해 이게 왜 안되느냐고 문의가 가끔 오기도 한다. 그러니 초반에 네이밍 규칙을 잘 정해 이런 일이 없도록 하자.

개발 부서를 위한 역할 부여 

아마 처음 GCP를 시작했다면 본인의 역할은 기본 역할인 소유자로 되어 있을 것이다. 역할에 대해 잘 모르겠다면 이전 포스팅이나 아래 문서르 참고하자.

 

역할 이해  |  Cloud IAM 문서  |  Google Cloud

 

일단 개발 부서가 테스트할 VM이 있어야 한다. 만약 GCP가 처음이라면 Compute API 사용을 허용해주어야 한다.

$ gcloud service enable compute
Operation "..." finished successfully.

참고로 위 명령어는 결제 설정이 되어 있어야 한다. Google Cloud Console에서 결재 수단을 등록하고 결제 계정을 생성한 뒤 프로젝트에서 방금 만든 결제 계정을 선택하면 된다.

 

Compute API를 허용했다면 아래 CLI를 사용해 VM을 생성하자.

$ gcloud compute instances create study-web-dev-1 \
--zone=asia-northeast3-a \
--machine-type=f1-micro \
--image=ubuntu-minimal-2004-focal-v20211209 \
--image-project=ubuntu-os-cloud \
--boot-disk-size=10GB \
--boot-disk-type=pd-balanced \
--boot-disk-device-name=study-web-dev-1


NAME             ZONE               MACHINE_TYPE  PREEMPTIBLE  INTERNAL_IP       EXTERNAL_IP      STATUS
study-web-dev-1  asia-northeast3-a  f1-micro                   xxx.xxx.xxx.xxx   xxx.xxx.xxx.xxx  RUNNING

위에서 부터 

--zone : VM을 생성할 리전 내 영역이다. asia-northeast3(서울) 리전의 경우 a, b, c 이렇게 3개의 가용 영역이 존재한다.

--machine-type : VM 유형이다. VM 유형에 따라 CPU와 MEM 등이 달라진다. 

--image : VM에 띄울 이미지이다. 지금은 ubuntu 20.04 이미지를 선택했다.

--image-project : 이미지가 속한 프로젝트이다. 나중에 디스크 이미지를 직접 만들면 현재 프로젝트의 ID가 이미지의 프로젝트가 된다.

--boot-disk-size : 부팅 디스크 용량이다. 이미지별로 최소 용량이 있는데 위 ubuntu 이미지의 경우 10GB가 최소 용량이다.

--boot-disk-type : 디스크 타입을 설정한다. pd-balanced는 균형있는 SSD 디스크로 범용적으로 사용된다.

--boot-disk-device-name : 디스크 이름을 설정한다. 나 같은 경우는 VM Instance 이름과 똑같이 만든다.

 

혹시 다른 이미지를 사용하고 싶다면 gcloud compute images list 명령어를 사용하자. grep 등의 명령어를 같이 사용하면 편하게 이미지를 선택할 수 있으며 아래 처럼 명령어를 사용해 깔끔하게 최신 이미지를 선택할 수도 있다. 

# gcloud compute images list 명령어로 원하는 이미지 찾기
$ gcloud compute images list | grep centos

# Ubuntu 20.04 minimal 이미지 중 최신 이미지 명 출력 
$ gcloud compute images list --filter=name:ubuntu-minimal-2004 --uri | awk -Fimages/ '{ print $2 }'

# CentOS를 사용하고 싶다면 fileter만 바꿔준다.
$ gcloud compute images list --filter=name:centos-7  --uri | awk -Fimages/ '{ print $2 }'

 

옵션들에 대해서는 간단하게 설명했는데 자세하게 설명하면 너무 글이 길어질 것 같아 나중에 따로 포스팅 하도록 하겠다. 만약에 위 내용들에 대해 궁금하다면 아래 문서들을 참고해 보면 옵션을 선택할 때 도움이 된다.

 

gcloud compute instance create CLI - https://cloud.google.com/sdk/gcloud/reference/compute/instances/create 

Machine Type - https://cloud.google.com/compute/docs/machine-types

Image - https://cloud.google.com/compute/docs/images#os-compute-support

Disk Type - https://cloud.google.com/compute/docs/disks?hl=ko-KR 

 

이렇게 VM이 생성됐다. 배포는 개발팀에서 알아서 할 것이므로 접속만 가능하게 해서 주면 될 것이다. 물론 원래는 사전 설정들이 필요하지만 IAM을 포스팅하는 중이니 일단 넘어가자. 

 

그럼 이제 개발팀을 위해 개발팀 전용 그룹을 생성하고 그룹에 개발자 계정을 추가해 주어야한다. 여기서 그룹이란 사용자를 묶어서 관리하는 것이다. 만약에 개발팀원이 10명이라면 모두 비슷한 작업을 하더라도 1명씩 역할을 부여해 주어야하는데 이 인원들을 그룹으로 묶어버리면 그룹에 역할을 부여해서 쉽게 관리할 수 있게 된다. 그리고 이 그룹은 GCP에서는 API만 제공하고 실제로는 Google Workspace 그룹에서 관리된다. 그렇기 때문에 그룹을 생성하기 위해서는 Google의 Cloud ID나 WorkSpace를 사용하고 있어야한다. 하지만 이렇게 까지 설정해서 하는 것은 너무 과하기 때문에 그냥 개발자 계정 하나만 만들어서 진행하도록 하자. 어차피 그룹에다가 역할 부여하는 것도 일반 계정에 부여하는 거랑 별 다를게 없다. 

 

먼저 개발자용 계정을 하나 만들자. GCP는 AWS처럼 아무렇게나 IAM계정을 생성할 수 없다. 반드시 google계정이나 WorkSpace계정으로 생성해야한다. 즉, 기존에 존재하는 google계정을 GCP로 불러오는 식이다. 그래도 다행히 google은 실명인증이 되지 않더라도 쉽게 계정을 만들 수 있기 때문에 실습에 문제될 것은 없다.

 

위 처럼 간단한 정보만 입력하면 회원가입을 할 수 있다. 중요한 것은 생년월일이 성인 기준을 만족해야한다. 만약에 생년월일이 성인 기준을 만족하지 못하면 인증을 해야한다. 

 

이렇게 생성했으면 IAM에 방금 생성한 계정을 추가하도록 하자. IAM 계정 추가는 Google Cloud Console -> IAM 및 관리자 -> IAM 으로 이동해 상단의 +추가 버튼을 클릭하면 된다. 그런데 추가할 때 역할을 부여하지 않으면 IAM계정이 추가 되지 않는다. 먼저 어떤 역할을 부여해줄 지 생각해보자. 

 

일단 필요한 권한은 인스턴스에 접속해야하고, 파일을 업로드 해야한다. 먼저 인스턴스 접속부터 생각하.자. GCP에서는 다양한 접속방법을 제공하고 있는데, Cloud Console에서 로그인 된 사용자로 인증해 web으로 접속할 수도 있고 공개키를 만들어서 접속하거나 OS계정과 비밀번호를 사용해서 접속할 수도 있다. IAM이나 그룹에 추가되어 있지 않은 외부 사용자라면 어쩔수 없이 키를 만드는 방식으로 진행해야겠지만 지금은 IAM계정이 존재하는 내부 사용자이므로 다른 방법을 사용하는 것이 좋다. 이번에는 IAP를 사용해보도록 하자. 

 

 IAP는 Identity-Aware-Proxy의 약자로 VM에 대한 엑세스를 보호하는 서비스이다. 생각보다 편하기도하고 중요한 서비스라 짚고 넘어가는 것이 좋겠다. 만약에 위에서 만든 VM에 외부 IP가 설정되어 있지 않다면 외부에서 어떻게 SSH로 접근해야할까? 이런 경우는 아주 흔한 경우이다. Private Subnet에 배포되어 있거나 Public Subnet에 배포되어 있더라도 보통은 로드밸런서 사용하기 때문에 VM자체는 외부 IP를 두지 않는다. 이는 DB에도 해당된다. 

 

 이때 사용할 수 있는 것이 IAP이다. IAP를 사용하면 VPN없이 내부 네트워크의 리소스에 접근할 수 있다. 인증은 사용자 계정으로 인증하므로 따로 계정을 전달할 필요없이 역할만 부여해주면 된다. IAP의 TCP 터널링 사용시 기존 인스턴스에게 IAP에 대한 방화벽을 허용해주어야 한다. 방화벽은 gcloud compute firewall-rules create 명령어로 생성할 수 있다.

$ gcloud compute firewall-rules create allow-ssh-ingress-from-iap \
  --direction=INGRESS \
  --action=allow \
  --rules=tcp:22 \
  --source-ranges=35.235.240.0/20
  
  Creating firewall...done.
NAME                        NETWORK  DIRECTION  PRIORITY  ALLOW   DENY  DISABLED
allow-ssh-ingress-from-iap  default  INGRESS    1000      tcp:22        False

위 명령어는 전체 인스턴스에 대해 35.235.240.0/20 대역의 22번 포트 접근을 허용해주겠다는 의미이다. 

 

그리고 VM계정 관리르 위해 OS로그인을 설정해주자. OS로그인을 설정하면 VM접속 시 일관된 ID를 사용할 수 있으며 VM별로 SSH키를 생성할 필요가 없어진다. gcloud compute project-info add-metadata 명령어를 사용해 설정하자.

$ gcloud compute project-info add-metadata \
    --metadata enable-oslogin=TRUE

 

그 다음 gcloud compute ssh 명령어를 사용해 VM Instance에 접속해보자. 

$ gcloud compute ssh study-web-dev-1--tunnel-through-iap

명령어를 보면 뒤에 --tunnel-through-iap 옵션이 붙어있는 것을 볼 수 있는데 이는 강제로 TCP 터널링을 사용하겠다는 뜻이다. gcloud compute ssh 명령어는 외부 IP가 없으면 IAP를 통한 TCP 터널링을 하고 외부 IP가 존재하면 그냥 외부 IP를 사용해 접근한다. 

 

아마 위 명령어를 입력하면 키 페어를 생성할 것이다. 이는 IAP의 TCP 터널링을 통해 키를 교환하면서 접속하게 되는 방식이라 그렇다. 키는 osLogin을 사용할 경우 한번만 생성하면 되며 키를 생성하고 나면 약간의 시간이 흐른 후 정상적으로 접속이 되는 것을 볼 수 있다. 또한 osLogin을 사용했기 때문에 사용자 계정이 google계정으로 되어있을 것이다.

 

 그러면 이제 개발자의 계정도 이렇게 접속이 가능해야 한다. 우리 계정은 소유자 역할이 부여되어 있기 때문에 별다른 문제없이 접속이 됐지만 개발자 계정은 필요한 권한만 부여해야 하기 때문에 적절한 역할을 찾아야한다. IAP TCP 터널링을 통해 접근하기 위해 필요한 역할은 아래와 같다.

 

- roles/compute.osLogin    // osLogin

- roles/iap.tunnelResourceAccessor  // IAP 보안터널사용자

- roles/iam.serviceAccountUser // 서비스 계정으로 작업 실행

 

참고로 osLogin시 Service Account를 가장해서 로그인 하기 때문에 iam.serviceAccountUser 역할을 꼭 추가해주어야한다. 자세한 내용은 아래 두 문서를 참고하자.

 

IAP TCP 전달을 사용할 권한 부여 - https://cloud.google.com/iap/docs/using-tcp-forwarding#grant-permission 

OS로그인 IAM 역할 부여- https://cloud.google.com/compute/docs/instances/managing-instance-access#grant-iam-roles

 

아직 파일업로드 건이 남아있긴 하지만 일단 이 역할들을 부여해서 IAM 계정을 추가해보자.

osLogin와 iam.serviceAccountUser 역할은 어디있는지 모르겠다... 하지만 SDK를 사용해서 역할을 부여할 수 있기 때문에 아래와 같이 명령어를 입력해 역할을 부여하자. gcloud projects add-iam-policy-binding

gcloud projects add-iam-policy-binding <PROJEcT_ID> --member=user:<IAM_ACCOUNT> --role=roles/compute.osLogin
gcloud projects add-iam-policy-binding <PROJEcT_ID> --member=user:<IAM_ACCOUNT> --role=roles/iam.serviceAccountUser

--member 옵션은 일반 사용자면 user:<IAM_ACCOUNT>, 그룹이면 group:<IAM_ACCOUNT>, 서비스 계정이면 serviceAccount:<IAM_ACCOUNT>로 입력해야한다. 이제 역할도 부여되었으니 VM으로 접속이 되는지 확인해보자.

 

먼저 SDK로 계정설정부터 진행하자. 

$ gcloud auth login <IAM_ACCOUNT>
Go to the following link in your browser:

 ...
 
 Enter verification code:

그 다음 로그인한 계정으로 전환하고 기본 프로젝트를 설정해준다.

$ gcloud config set account <IAM_ACCOUNT>
Updated property [core/account].

$ gcloud config set project <PROJECT_ID>
Updated property [core/project].

마지막으로 잘 변경되었는지 확인헤보자.

$ gcloud auth list
Credentialed Accounts
ACTIVE  ACCOUNT
        <ACCOUNT>
   *    <IAM_ACCOUNT>

ACTIVE 표시가 개발자 계정에 표시되어 있다면 잘 전환된 것이다. 이제는 뭘하든 개발자 계정의 역할을 사용한다. 따라서 소유자 권한은 사용할 수 없고 osLogin과 IAP 보안터널사용자 역할만 사용할 수 있게 된다. 

 

이제 VM에 접속해보자. 

$ gcloud compute ssh study-web-dev-1 --tunnel-through-iap

역할이 잘 부여됐다면 정상적으로 접속될 것이다. 만약에 접속이 안된다면 역할을 다시 확인해 보거나 방화벽이 잘 설정되어 있는지 확인하도록 하자. 

 

 

 

 

다음 포스팅에서는 개발자가 배포를 시작하는 시점부터 진행하도록 한다.