GCP service account impersonation | No credential file, No worry.

เปลี่ยนวิธีในการใช้งาน Service account แบบเดิมที่ต้องย้าย credential file ไปมาเพราะมันเสี่ยงเหลือเกินที่ credential file หลุดออกไป Public

Security สำคัญไฉน?

การใช้งานบริการ Public cloud ก็จะไม่พ้นจะต้องมีความเข้มงวดในเรื่อง Security หรือความปลอดภัยในการใช้งาน ไม่ว่าจะเป็นเรื่อง Identity permission ต่างๆ เพื่อที่จะได้ควบคุมบุคคลที่จะสามารถมาใช้งานได้ ไม่ว่าจะเป็นการพัฒนาแอพฯ หรือการเข้าไปเรียกดูข้อมูลใน Database warehouse ลองคิดตามถ้าเกิดข้อมูลเหล่านี้หลุดไปความเสียหายจะมากมายแค่ไหน😱

บทความนี้ก็เลยอยากจะแนะนำเรื่องการใช้งาน Service account ในอีกรูปแบบหนึ่งที่โดยพื้นฐานเริ่มต้นทั่วๆไปเรามักจะใช้วิธีสร้าง Service account แล้วก็โหลด Credential file มาลงที่ local แล้วก็ใช้งานจากตรงนี้ แต่ถ้าเกิดเรามีการส่งต่อๆกันไปเรื่อยๆ แล้วเกิด Credential file หลุดออกไปใครจะเอาไปใช้งานก็ได้ หรือบางทีเราอาจจะเผลอ push ขึ้น Git ทำให้เกิดปัญหาได้ยิ่งโดยเฉพาะถ้า Repository นั้นเป็น Public repo ซึ่งไม่ดีแน่ๆ ก็เลยอยากจะมาเขียนบทความเพื่อเสนออีกแนวทางหนึ่งนั้นก็คือ Service account impersonation

Service account impersonation usecase และ ใช้งานยังไง

Impersonation แปลตรงๆตัวก็คือ การปลอมตัวเป็นผู้อื่น, การปลอมตน (อังกฤษ-ไทย: ศัพท์บัญญัติราชบัณฑิตยสถาน) ก็ตามชื่อเลยก็คือการที่เราจะแปลง identity ตัวเองเป็น service account นั้นๆ ข้อดีก็คือเราไม่จำเป็นที่ต้องมี credential file ในการใช้งาน เพียงแค่เพิ่ม impersonate account เป็น service account นั้นๆ

แต่สิ่งสำคัญคือ account ของเรานั้นจะต้องมีสิทธิ์ตามนี้ เพราะเราจะต้องมีการสร้าง short-live access token จาก Service account นั้นๆ

iam.ServiceAccounts.getAccessToken

ส่วนในของ Service account นั้นจะมีอะไรก็ได้ ตามแต่งานนั้นๆ เช่น Editor, Bigquery user อะไรประมาณนั้น เพราะเราจะมาใช้สิทธิ์ของ Service account

Example usecase

จะมายกตัวอย่างการใช้งานให้เห็นภาพมากขึ้น สัก 2 กรณี

local developement and cloud deployment with cloud run เป็นการที่เราเขียน Code ที่ local ของเราแล้ว code ของเราจำเป็นจะต้องเชื่อมต่อกับ Cloud services ต่างๆ เราก็ทำการ impersonate เป็น service account นั้น โดยที่ account เราไม่จำเป็นจะต้องมีสิทธิ์อะไรอื่นนอกจาก get access token และพอเวลาที่จะต้อง Deploy บน Cloud เช่น Cloud run เราก็เพียงมอบสิทธิ์ get access token ให้กับ service account ที่เป็น woker ของ Cloud run เพียงเท่านั้น เราไม่จำเป็นจะต้องสลับไปมาระหว่าง account ต่างๆหรือ credential file

ตัวอย่างแผนภาพการใช้งาน service account impersonation ผ่าน local และ cloud run

2. User upload DAGs file and Composer(Airflow) worker do the rest เป็นอีกเคสที่อยากยกตัวอย่างเป็นการ ที่เราอยากจะให้ user มีสิทธิ์แค่การ upload DAGs file ที่ Google cloud storage เท่านั้นไม่ให้ไปยุ่งเกี่ยว service อื่นๆเลย เช่นสมมุติว่า Task ใน Dags เรานั้นมีการ Query data จาก Bigquery หรือ มีการไปเรียกใช้ Vertex AI ในการ train test machine learning model เป็นต้น

Service account impersonation ใช้งานยังไง

จาก Usecase ที่แสดงเป็นตัวอย่างไปแล้วเราอาจจะมองเห็นเป็น ภาพรวมคราวๆ ไปแล้วแต่หลายคนคงจะยังมีคำถามว่าแล้วจะใช้งานยังไง เราจะลองมาทำตามกัน🤓
โดยในตัวอย่างจะเป็นสร้าง Google cloud storage bucket ผ่าน Service account impersonation

เริ่มจากไปที่ IAM แล้วเพิ่ม Role ให้กับ User และ Service account ที่เราจะทำการ impersonate

User grant role as Service Account Token Creator

Grant service account as Storage Admin, having full control of GCS

2. หลังจากที่เพิ่มสิทธิ์ต่างๆให้กับ User และ Service account แล้วก็มาเริ่มกัน โดยในตัวอย่างที่เราจะทำคือการสร้าง Bucket ใน Google cloud storage ซึ่งเราสามารถทำได้สองทางคือ 1. ผ่าน gcloud sdk cli 2. client library ตามภาษานั้น โดยผมจะเขียนในทีนี้เป็น Python1

2.1 โดยเริ่มผ่านการสร้าง Bucket ผ่าน gcloud sdk cli โดยใช้คำสั้ง
gcloud storage buckets create

Error as we did not have storage permission

ถ้าเราทำการสร้าง Bucket โดยไม่ผ่าน Service account จะเห็นได้ว่าจะไม่สามารถทำได้เพราะ permission เราไม่มี ทีนี้มาลองทำผ่าน Service account impersonation โดยเราจะมี — impersonate-service-account ติดท้าย command ไปด้วย

gcloud storage buckets create gs://{bucket name} --location=us-central1 --impersonate-service-account {service account principle}

Bucket has created with warning show that this bucket was created by service account

2.2 ใช้งาน Service account impersonation ผ่าน Client library ในที่นี้ผมจะใช้ ภาษา Python ในการสร้าง Bucket

ในการใช้งาน Client library เราต้องเพิ่ม Service Usage Consumer ให้กับ User ด้วยเป็นสิ่งสำคัญในการใช้ Service api ต่างๆ

โดยแบบแรกคือการเขียน Python สร้าง Bucket โดยไม่ผ่าน service account โดยตัว Client library จะเรียก Token จาก account ของเราเป็น Default ซึ่งเราไม่มี Permission นั้นทำให้ไม่ควรที่จะสามารถสร้าง Bucket ได้

from google.cloud import storage
# default auth for bucket creating with python code
bucket_name = "your-new-bucket-name"
storage_client = storage.Client()
bucket = storage_client.create_bucket(bucket_name)
print(f"Bucket {bucket.name} created")

Error because my account don’t have permission to create bucket

จะเห็นได้ว่าเราจะไม่สามารถสร้าง Bucket ได้แต่ทีนี้เราจะสร้าง Bucket ผ่าน service account โดยเพิ่ม google.auth library เข้าไปด้วย

import google.auth
from google.auth import impersonated_credentials
from google.cloud import storage

# create GoogleCredentials object
credentials, project_id = google.auth.default()

# Create the impersonated credential.
impersonated_service_account = "serviceaccount@iam.gserviceaccount.com" # service account principle
scope = ["https://www.googleapis.com/auth/cloud-platform"]
target_credentials = impersonated_credentials.Credentials(
    source_credentials=credentials,
    target_principal=impersonated_service_account,
    target_scopes=scope,
)

# Create bucket
bucket_name = "your-new-bucket-name"
storage_client = storage.Client(credentials=target_credentials)
bucket = storage_client.create_bucket(bucket_name)
print(f"Bucket {bucket.name} created")

จะเห็นได้ว่าเมื่อเราเพิ่ม google.auth เข้าไปและใช้วิธีการ เพิ่ม Service account principle ไปเท่านั้น เราก็สามารถทำงานอย่างที่ต้องการได้แล้วถ้าเทียบกับการใช้งาน Service account แบบเดิม ที่เราจะต้องมี credential file แล้ว เพียงใช้วิธี Service account impersonation เราก็ไม่ต้องมี file ให้วุ่นวายเลย ✨

Service account impersonation ก็เป็นเพียงหนึ่งในวิธีการใช้งาน Service account เพื่อเพิ่มความปลอดภัยให้กับองค์กรของเราเท่านั้น แต่เรื่องความปลอดภัยยังมีเรื่องอื่นที่สำคัญ โดยเฉพาะเรื่อง Least privileged และ Zero trust

มอบสิทธิ์การใช้งานเพียงแค่เพียงพอต่อการใช้งานเท่านั้น!

Follow me here!

Clouddatalabor