[GCP Associate Cloud Engineer] IAM

IAM(Identity and Access Management)

정체성과 접근 관리를 의미하며, 클라우드에서 리소스에 대한 접근 권한을 관리하는 중요한 서비스이다. 

 

클라우드 환경에는 다양한 리소스가 존재한다. 예를 들어, 가상 서버를 생성하거나 데이터베이스를 관리하는 등 다양한 리소스를 활용할 수 있다. 이러한 리소스에 접근하려면 정체성이 필요하다.

 

IAM에서 관리하는 정체성은 크게 두 가지로 나뉜다.

사람(Human): 클라우드 서비스를 직접 사용하려는 사용자(예: 개발자, 관리자 등).

비인간(Non-Human): 애플리케이션이 데이터베이스와 같은 리소스에 접근하여 작업을 수행해야 하는 경우.

 

예를 들어, 특정 사용자가 가상 서버를 시작하거나 중지하려고 한다면, 해당 사용자가 리소스에 접근할 수 있는 권한을 IAM을 통해 설정해야 한다.

 

 

GCP에서의 IAM

 

Cloud IAM은 크게 두 가지 핵심 기능을 담당한다.

 - 인증(Authentication): 사용자가 올바른 사용자(정체성)인지 확인.

 - 권한(Authorization): 사용자가 올바른 접근 권한을 가지고 있는지 확인.

 

IAM은 정체성을 여러 유형으로 구분한다.

 - GCP 사용자: Google 계정으로 인증된 사용자.

 - 외부 인증 사용자: GCP 외부에서 인증된 사용자.

 - 사용자 그룹(Groups): 여러 사용자를 하나의 그룹으로 묶어 관리. 예를 들어, 개발자 그룹을 만들면, 새로운 팀원이 들어왔을 때 그룹에 추가하는 것만으로 권한 관리가 가능하다.

 - GCP 내에서 실행 중인 애플리케이션: 예를 들어, GCP의 가상 머신에서 실행 중인 애플리케이션.

 - 데이터 센터 내에서 실행 중인 애플리케이션: 온프레미스 환경에서 실행되며 GCP 리소스에 접근해야 하는 애플리케이션.

 - 비인증 사용자(Unauthenticated users): 특정 리소스를 **공개(Public)**로 설정하여 비인증 사용자도 접근할 수 있게 설정.

 

Cloud IAM의 주요 특징

 

Cloud IAM은 매우 세부적인 제어를 제공한다.

 · 특정 사용자가 특정 리소스에 대해 특정 작업만 수행하도록 설정.

 · 특정 IP 주소에서만 접근 가능하도록 설정.

 · 특정 시간대에만 접근 가능하도록 제한.

예를 들어, 한 사용자가 특정 데이터베이스에 대해 읽기 작업만 수행할 수 있게 제한하거나, 애플리케이션이 특정 시간 동안에만 실행되도록 설정할 수 있다.

 

일반적인 IAM 개념

 

멤버(Member): 권한을 부여받을 사용자 또는 애플리케이션.

리소스(Resource): 특정 클라우드 스토리지 버킷과 같이 권한을 행사할 대상.

액션(Action): 객체 업로드, 객체 삭제 등 멤버가 수행할 작업.

 

Google Cloud IAM의 주요 개념

 

1. 역할(Role)

특정 리소스에서 특정 작업을 수행할 수 있는 권한의 집합으로 역할은 멤버에 대해 아무것도 모르고, 역할은 단순히 권한의 집합일 뿐이며, 멤버와 연결되지 않는다.

 

기본 역할(Basic Roles)

기본 역할은 GCP에서 IAM 도입 이전부터 존재했던 가장 원시적인 형태의 역할이며, 광범위한 권한을 제공한다.

 

Viewer (roles/viewer): GCP 내 모든 리소스에 대해 읽기 전용 작업 가능.

Editor (roles/editor): Viewer 권한에 추가로 수정 작업 가능.

Owner (roles/owner): Editor 권한에 추가로 역할 및 권한 관리와 청구 관리 가능.

 

기본 역할은 광범위한 권한을 제공하므로, 프로덕션 환경에서는 권장되지 않는다.

 

 

사전 정의된 역할(Predefined Roles)

사전 정의된 역할은 GCP가 제공하는 세분화된 권한을 가진 역할이며, 특정 서비스 및 목적에 따라 설계되었다.

 

서비스별로 역할이 정의되어 아래와 같은 역할이 존재한다.

Storage Admin: 버킷과 객체 모두 관리 가능.

Storage Object Admin: 객체 관리 가능(버킷 생성 및 관리 불가).

Storage Object Viewer: 객체 읽기 권한만 부여.

Storage Object Creator: 객체 생성 가능.

...

 

세분화된 권한을 제공하므로, 각 사용자가 프로젝트 내에서 수행하는 작업에 정확히 맞는 권한을 할당할 수 있다.

사전 정의된 역할은 프로덕션 환경에서 권장된다.

 

사용자 정의 역할(Custom Roles)

사전 정의된 역할이 특정 요구를 충족하지 못할 경우, 조직의 고유한 요구사항에 맞춘 사용자 정의 역할을 생성할 수 있다.

필요한 권한만 선택하여 사용자 정의 역할을 생성 가능하기 때문에 조직 수준에서 관리 및 적용 가능하다.

고도로 세분화된 접근 제어가 가능하여 최소 권한 원칙을 준수할 수 있다.

 

역할 유형별 비교

역할 유형	범위	권장 여부	사용 예시
기본 역할	광범위한 권한	프로덕션 환경에서 권장되지 않음	특정 프로젝트 전체 읽기 전용 제공
사전 정의된 역할	서비스별로 세분화된 권한 제공	프로덕션 환경에서 권장	특정 작업에 맞는 권한 부여
사용자 정의 역할	조직 요구에 맞춘 고도로 세분화된 권한	고급 사용 사례에서 유용	최소 권한만 부여해야 하는 경우

 

GCP에서 역할 목록

 

2. 정책(Policy)

역할을 멤버와 연결하는 구조로 정책을 사용해 특정 멤버에게 특정 역할을 할당할 수 있다.
예를들어 동료에게 Storage Object Admin 역할을 부여해 특정 버킷 관리 권한을 부여할 수 있다.

GCloud를 통해 IAM 관리

 

IAM 정책 조회 및 관리

 

IAM 정책은 멤버(사용자, 서비스 계정 등)와 역할의 매핑 정보를 포함한다.

 

# IAM 정책 조회
gcloud projects get-iam-policy [PROJECT_ID]

 

 

현재 프로젝트에 할당된 모든 사용자 및 서비스 계정 목록과 그들이 가지고 있는 역할(Role) 정보를 확인할 수 있다.

 

 

# 사용자에게 역할 할당
gcloud projects add-iam-policy-binding [PROJECT_ID] \
    --member=user:[EMAIL] \
    --role=roles/storage.objectAdmin

 

--member=user:[EMAIL] : 특정 이메일 계정에 대해 권한 부여.

--role=roles/storage.objectAdmin : Cloud Storage 객체 관리 권한을 부여.

이 명령어를 실행하면, IAM 정책이 업데이트되며 해당 사용자가 Cloud Storage 객체를 관리할 수 있는 권한을 획득하게 된다.

 

# 사용자 역할 제거
gcloud projects remove-iam-policy-binding [PROJECT_ID] \
    --member=user:[EMAIL] \
    --role=roles/storage.objectAdmin

이 명령어를 실행하면, 사용자에 대한 Storage Object Admin 역할이 제거된다.

 

 

# 전체 IAM 정책 설정
gcloud projects set-iam-policy [PROJECT_ID] policy.json

IAM 정책을 완전히 덮어쓰기 해야 할 경우 set-iam-policy를 사용한다.

주의할 점은 이것을 사용하면 기존 정책이 모두 덮어씌워지므로, 일반적으로 잘 사용하지 않는다.

여기서 policy.json 파일에는 전체 IAM 정책이 JSON 형식으로 포함되어 있어야 한다.

 

역할 관리

 

# 특정 역할의 상세 정보 확인
gcloud iam roles describe roles/storage.objectAdmin

 

roles/storage.objectAdmin 역할이 어떤 권한을 포함하는지 확인할 수 있다.

역할의 GA(General Availability), Beta, Alpha 등 현재 스테이지 정보도 제공된다.

 

# 사용자 정의(Custom) 역할 생성
gcloud iam roles create myCustomRole \
    --project=[PROJECT_ID] \
    --title="My Custom Role" \
    --description="Custom role for specific permissions" \
    --permissions="storage.objects.list,storage.objects.get"

 

 

--title="My Custom Role" : 역할의 제목.

--description="Custom role for specific permissions" : 역할 설명.

--permissions="storage.objects.list,storage.objects.get" : 특정 권한을 부여.

 

GCP의 사전 정의된 역할로 충분하지 않을 경우, 사용자 정의 역할을 만들 수 있다.

 

완전히 새로운 역할을 만들지 않고, 기존 역할을 복사하여 일부 권한만 수정하는 방법도 있다.

# 기존 역할 복사하여 새로운 역할 생성
gcloud iam roles copy \
    --source=roles/storage.objectAdmin \
    --destination=my.custom.role \
    --project=my-first-project-304608

 

기존 역할 roles/storage.objectAdmin을 새로운 역할 my.custom.role로 복사.

프로젝트 내에서 새로운 역할을 생성할 때 유용하다.

 

# 프로젝트 삭제
gcloud projects delete [PROJECT_ID]

 

이 명령어를 실행하면 프로젝트가 완전히 삭제되므로 신중히 실행해야 한다.

 

명령어 정리

명령어	설명
gcloud compute project-info describe	현재 프로젝트 정보 조회
gcloud config set project [PROJECT_ID]	기본 작업 프로젝트 설정
gcloud projects get-iam-policy [PROJECT_ID]	IAM 정책 조회
gcloud projects add-iam-policy-binding	사용자에게 특정 역할 추가
gcloud projects remove-iam-policy-binding	사용자 역할 제거
gcloud iam roles describe [ROLE_NAME]	특정 역할 정보 조회
gcloud iam roles create	새로운 사용자 정의 역할 생성
gcloud iam roles copy	기존 역할을 복사하여 새 역할 생성
gcloud projects delete [PROJECT_ID]	프로젝트 삭제

서비스 계정(Service Account)

GCP에서 애플리케이션이 특정 리소스에 접근해야 할 때 사용된다.

일반 사용자 계정과 다르게 비밀번호가 없으며, RSA 공개/개인 키를 이용하여 인증을 수행한다.

브라우저 로그인이나 쿠키 인증이 불가능하며, 애플리케이션 또는 가상 머신에 할당되어 GCP API를 호출하는 데 사용된다.

 

서비스 계정이 필요한 이유는 일반 사용자 계정을 애플리케이션에 직접 할당하는 것은 보안상 위험이 크다.

예를 들어 잘못된 사용자 계정이 유출될 경우 모든 리소스에 대한 접근 권한이 악용될 수 있다. 그리고 개발자가 변경될 경우 해당 계정을 철회하는 것이 어렵다. 추가적으로 서비스 간 인증이 필요할 경우 별도의 인증 프로세스가 필요하다.

따라서 서비스 계정을 생성하여 특정 애플리케이션에만 필요한 최소한의 권한을 부여하는 것이 GCP에서 권장되는 방식이다.

 

서비스 계정의 종류

 

기본 서비스 계정 (Default Service Account)

GCP에서 특정 서비스를 생성할 때 자동으로 생성되는 서비스 계정이다.

기본적으로 Editor 역할이 할당되며, 대부분의 리소스에 대한 수정 권한이 부여된다.

기본 서비스 계정은 광범위한 권한을 가지므로, 프로덕션 환경에서는 사용을 지양하는 것이 좋다.

대신, 사용자 관리 서비스 계정을 생성하여 세부적인 접근 제어를 설정하는 것이 권장된다.

 

사용자 관리 서비스 계정 (User-managed Service Account)

사용자가 직접 생성하여 특정 애플리케이션이나 VM에 할당하는 서비스 계정이다.

최소 권한 원칙에 따라 필요한 역할만 부여 가능하다.

특정 IAM 역할을 부여하여 권한을 제한할 수 있다.

생성 후 VM, Cloud Functions, Cloud Run 등의 서비스에 연결하여 사용 가능하다.

 

 

Google 관리 서비스 계정 (Google-managed Service Account)

GCP가 자동으로 생성하고 관리하는 내부 시스템 계정으로 사용자가 직접 생성하거나 수정할 수 없다.

예를 들어, Cloud Functions 또는 BigQuery 같은 GCP 서비스가 내부적으로 특정 작업을 수행할 때 사용된다.

일반적으로 신경 쓸 필요가 없으며, 주로 기본 및 사용자 관리 서비스 계정을 활용하면 된다.

 

서비스 계정 생성 및 활용

 

# 서비스 계정 생성
gcloud iam service-accounts create my-compute-sa \
    --description="Service account for Compute Engine" \
    --display-name="My Compute Service Account"

 

my-compute-sa: 서비스 계정의 ID

--description: 서비스 계정에 대한 설명

--display-name: 콘솔에서 확인할 수 있는 표시 이름

서비스 계정이 생성되면, 이메일 주소 형식의 서비스 계정 ID가 자동으로 할당된다. 

 

서비스 계정이 생성된 후, IAM 역할을 부여하여 접근 권한을 설정해야 한다.

# 서비스 계정에 역할 할당
gcloud projects add-iam-policy-binding my-first-project-304608 \
    --member="serviceAccount:[EMAIL]" \
    --role="roles/storage.objectAdmin"

 

--member: 서비스 계정을 지정

--role: 해당 서비스 계정에 부여할 IAM 역할

 

 

VM에서 특정 권한을 가진 서비스 계정을 사용하려면, VM을 생성할 때 서비스 계정을 연결해야 한다.

# 서비스 계정을 VM에 연결
gcloud compute instances create my-vm \
    --zone=us-central1-a \
    --machine-type=e2-medium \
    --service-account=[EMAIL]

 

--service-account: VM에 사용할 서비스 계정 지정

이렇게 하면 해당 VM에서 실행되는 애플리케이션이 서비스 계정을 사용하여 GCP 리소스에 접근할 수 있다.

 

GCP API를 호출하는 애플리케이션에서 서비스 계정 키을 사용할 수 있다.

# 서비스 계정 키 생성
gcloud iam service-accounts keys create my-key.json \
    --iam-account=[EMAIL]

 

my-key.json: 생성된 키 파일

애플리케이션이 이 키 파일을 사용하여 GCP API에 접근 가능하게 된다.

이때 서비스 계정 키 파일이 유출되면 보안 위험이 크므로 안전한 보관이 필수이다.

보안 강화를 위해 Cloud IAM 권한 관리 및 Google Secret Manager를 활용하는 것이 권장된다.

 

서비스 계정이 더 이상 필요하지 않을 경우 삭제할 수 있다.

#  서비스 계정 삭제
gcloud iam service-accounts delete [EMAIL]

 

ACL(Access Control List)

ACL과 IAM의 차이점

 

IAM은 버킷 단위로 일괄적인 권한을 부여하며, 모든 객체가 동일한 권한을 가지고, ACL은 개별 객체에 대해 세분화된 권한을 설정할 수 있으며, 특정 객체만 공개하거나 특정 사용자에게만 권한을 부여할 수 있다.

IAM과 ACL 중 하나라도 접근을 허용하면 사용자는 해당 객체에 접근 가능하기 때문에 IAM 또는 ACL 중 하나라도 권한이 있으면 접근이 가능하다.

 

Google Cloud Storage 접근 제어 방식

 

Uniform (IAM 기반의 일괄 적용)

IAM을 사용하여 버킷 내 모든 객체에 동일한 권한을 부여하는 방식으로 객체별 세분화된 권한 관리가 불가능하며, 설정된 IAM 역할에 따라 접근 권한이 결정된다.

 

IAM을 활용하여 버킷 내 모든 객체에 동일한 접근 권한을 적용하려면 Uniform Access를 활성화해야 한다.

# IAM을 사용한 Uniform Bucket-Level Access 설정
gcloud storage buckets update my-bucket \
    --uniform-bucket-level-access

 

--uniform-bucket-level-access: 버킷 내 모든 객체에 IAM 역할을 동일하게 적용

Uniform 설정이 활성화되면, 객체별 ACL 설정이 비활성화되며 IAM을 통해서만 접근 제어가 가능하다.

 

Fine-Grained (ACL을 통한 세밀한 제어)

IAM 외에도 각 객체별로 ACL을 설정하여 개별 권한을 부여할 수 있다.

예를 들어, 버킷 내의 index.html 파일은 공개로 설정하고, private.pdf 파일은 특정 사용자만 접근하도록 설정 가능하다.

 

 

# ACL을 사용한 Fine-Grained Access 설정
gcloud storage buckets update my-bucket \
    --no-uniform-bucket-level-access

 

--no-uniform-bucket-level-access: 객체별 ACL을 활성화

Fine-Grained 모드가 활성화되면, 개별 객체에 대해 ACL을 설정할 수 있으며 IAM과 함께 동작한다.

 

# 특정 객체를 Public으로 설정
gcloud storage objects add-acl public-read \
    gs://my-bucket/index.html

 

add-acl public-read: 특정 객체를 모두에게 공개

이제 index.html 파일은 인터넷에서 누구나 접근 가능하다.

 

# 특정 사용자에게 읽기 권한 부여
gcloud storage objects add-acl \
    --entity=user:example@gmail.com \
    --role=READER \
    gs://my-bucket/private.pdf

 

--entity=user:example@gmail.com: 특정 사용자를 지정

--role=READER: 해당 사용자에게 읽기 권한 부여

이제 example@gmail.com 사용자는 private.pdf 파일을 읽을 수 있다.

 

# ACL을 제거하여 접근 차단
gcloud storage objects remove-acl \
    --entity=allUsers \
    gs://my-bucket/index.html

--entity=allUsers: 모든 사용자에 대한 접근 권한 제거

이제 index.html 파일은 더 이상 공용으로 접근할 수 없다.

Signed URL

특정 객체에 대해 일정 시간 동안만 접근을 허용하는 URL로 Google 계정 없이도 접근 가능하다.

즉, IAM 권한이 없어도 파일 다운로드 또는 업로드 가능하여 일반적으로 임시 접근 권한을 부여해야 할 때 유용하다.

Signed URL이 필요한 이유는 고객이나 파트너와 같은 외부 사용자에게 GCP 리소스에 대한 임시 접근 권한을 부여하고 싶을 때, 사용자에게 Google 계정이 없어도 특정 파일을 공유하고 싶을 때, 특정 파일에 대해 다운로드 또는 업로드 권한을 제한된 시간 동안 허용하고 싶을 때 주로 사용한다.

 

Signed URL의 동작 방식

 

서비스 계정을 생성하고, 해당 객체에 접근할 수 있는 적절한 권한을 부여하고, 서비스 계정의 키를 생성하여 이를 사용해 Signed URL을 생성한다.

Signed URL을 특정 사용자와 공유하면, 해당 사용자는 로그인 없이 지정된 시간 동안 객체에 접근 가능하고, 시간이 만료되면 URL이 자동으로 비활성화된다.

 

# 서비스 계정 키 생성
gcloud iam service-accounts create my-signed-url-sa \
    --description="Service account for signed URLs" \
    --display-name="Signed URL Service Account"
    
# 서비스 계정 키(JSON) 생성
gcloud iam service-accounts keys create my-key.json \
    --iam-account=my-signed-url-sa@my-project.iam.gserviceaccount.com
    
# Signed URL 생성
gsutil signurl -d 10m my-key.json gs://my-bucket/my-object

-d 10m: 유효기간 10분 설정 (m: 분, h: 시간, d: 일)

my-key.json: 서비스 계정 키 파일

gs://my-bucket/my-object: Signed URL을 생성할 객체

 

 

Python을 사용하여 프로그램 내에서 Signed URL을 생성할 수도 있다.

from google.cloud import storage
from datetime import timedelta

def generate_signed_url(bucket_name, object_name, expiration_minutes=10):
    storage_client = storage.Client()
    bucket = storage_client.bucket(bucket_name)
    blob = bucket.blob(object_name)

    signed_url = blob.generate_signed_url(
        version="v4",
        expiration=timedelta(minutes=expiration_minutes),
        method="GET",
    )

    return signed_url

# 사용 예시
url = generate_signed_url("my-bucket", "my-object")
print(f"Signed URL: {url}")

Google Cloud Storage를 사용한 정적 웹사이트 호스팅

Google Cloud Storage를 웹사이트 호스팅에 활용하면 서버 없이 HTML, CSS, JavaScript 파일을 배포할 수 있다.

저렴한 비용으로 빠른 응답 속도의 웹사이트를 운영할 수 있기 때문에 Google의 글로벌 인프라를 활용하여 높은 가용성과 확장성을 확보할 수 있다.

사용자 지정 도메인을 사용할 경우, 버킷 이름과 도메인이 동일해야 한다.

모든 사용자가 웹사이트에 접근할 수 있도록 Storage Object Viewer 역할을 부여해야 한다.

 

#  버킷 생성
gcloud storage buckets create mywebsite.com \
    --location=US \
    --storage-class=STANDARD \
    --public-access-prevention=disabled

 

mywebsite.com: 사용할 도메인과 동일한 이름으로 버킷 생성.

--location=US: 스토리지 위치 설정.

--storage-class=STANDARD: 기본 저장소 클래스 사용.

--public-access-prevention=disabled: 퍼블릭 액세스를 허용.

 

# 웹사이트 파일을 업로드
gcloud storage cp index.html gs://mywebsite.com/
gcloud storage cp -r assets/ gs://mywebsite.com/

이제 웹사이트 파일이 Cloud Storage 버킷에 업로드된다.

 

# 모든 사용자에게 읽기 권한 부여
gcloud storage buckets add-iam-policy-binding mywebsite.com \
    --member=allUsers \
    --role=roles/storage.objectViewer

 

--member=allUsers: 모든 사용자에게 접근 권한 부여

--role=roles/storage.objectViewer: 객체 읽기 권한 부여

 

 

# 인덱스 페이지 및 오류 페이지 설정
gcloud storage buckets update mywebsite.com \
    --website-main-page=index.html \
    --website-not-found-page=404.html

 

--website-main-page=index.html: 기본 페이지를 index.html로 설정.

--website-not-found-page=404.html: 에러 발생 시 404.html로 리디렉트.

 

 

Cloud Storage에서 호스팅된 웹사이트는 다음 형식의 URL로 접근 가능하다.

# 기본 URL을 통한 웹사이트 접근
https://storage.googleapis.com/[BUCKET_NAME]/index.html

 

웹사이트를 https://storage.googleapis.com/mywebsite.com/index.html 대신, 사용자 지정 도메인(ex: mywebsite.com)으로 접근하려면 도메인 연결이 필요하다.

도메인을 Google Cloud Storage 버킷과 연결하려면 DNS 도메인 소유권을 확인해야 한다.

그리고 도메인과 Cloud Storage를 연결하려면 CNAME 레코드 추가가 필요하다.

 

# Cloud DNS를 사용한 CNAME 레코드 설정
gcloud dns record-sets transaction start --zone=my-zone
gcloud dns record-sets transaction add CNAME c.storage.googleapis.com. \
    --name=mywebsite.com. --ttl=300 --zone=my-zone
gcloud dns record-sets transaction execute --zone=my-zone

 

 

HTTPS 보안 연결

 

Google Cloud Storage는 기본적으로 HTTP만 지원하며, HTTPS를 사용하려면 Cloud CDN과 Load Balancer가 필요하다.

HTTPS를 활성화하려면 Cloud Load Balancer를 설정하여 Cloud Storage 버킷을 백엔드로 구성하고, Cloud CDN을 활성화하여 캐싱 및 HTTPS 제공을 통해 무료 SSL 인증서를 적용하여 HTTPS 보안 연결을 구성한다.