สวัสดีครับ สำหรับบทความนี้เราจะมาทำความรู้จัก Service Account บท Google Cloud Platform ซึ่งผมคิดว่าเป็นเครื่องมือ Authentication ตัวนึงที่สำคัญมากในการ Develope อะไรต่าง ๆ ที่เกี่ยวข้องกับ Google Cloud Platform ว่ามันคืออะไร เอาไว้ใช้งานแบบไหน ซึ่งบางคนอาจจะเคยใช้มาก่อนแต่ก็งงว่ามันคืออะไรกันแน่ และวิธีการใช้ที่ถูกต้องต้องใช้แบบไหน วันนี้เรามาทำความเข้าใจกันครับ

ก่อนจะไปดูเรื่อง Service Account ควรไปทำความเข้าใจเรื่อง Cloud IAM ก่อนครับ

Link : https://cloud.google.com/iam/docs/overview

สำหรับหัวข้อหลัก ๆ ที่ ผมจะอธิบายในวันนี้ครับ

• Service Account คืออะไร?
• Service Account Keys คืออะไร?
• ใช้ Service Account ตอนไหนดี?
• วิธีการสร้าง Service Account
• ช่องโหว่ของการใช้ Service Account
• การป้องกันช่องโหว่ในการใช้งาน Service Account
• ถ้า Service Account หลุดไปแล้วทำอย่างไร?
• Best Practice ของการใช้งาน Service Account

ทำความรู้จักกับเทคโนโลยีอื่นๆ บน Google Cloud กับกิจกรรม webinar

ลงทะเบียนเข้าร่วมฟรี ! คลิกที่นี่

Service Account คืออะไร?

ถ้าจะให้อธิบายง่าย ๆ เรามาทำความเข้าใจ Google Account ที่เราเคยใช้กันที่เป็น Email กันก่อน หรือ เราเรียก Account แบบนี้ว่า User ซึ่งเราก็สามารถใช้ Google Cloud Resource ต่างๆ ตาม Permission กับ Role ใน IAM ได้ แต่เจ้าตัว Service Account จะเป็น Account แบบพิเศษที่จะไม่ได้แสดงถึง User หรือ Google เรียกว่าการใช้งานแบบ Non-user

แล้วการใช้งานแบบ Non-user เป็นแบบไหน ? ก็ประมาณว่าถ้าเรามีการเรียกใช้ Service Google Cloud ที่ On-premise หรือบน Cloud โดยที่ User ไม่ได้เรียกใช้เองแบบที่มี Oauth2 เด้งขึ้นมาลองนึกเวลาเราใช้ Email Authentication อะไรซักอย่างนั่นแหละ เช่น การเขียน Cron Script. Terraform, เขียนโปรแกรมเชื่อมต่อ API ของ Google Cloud ส่วนก็จะใช้ Service Account ทั้งนั้น

Service Account Keys คืออะไร?

ตัว Service Account Keys เป็น Private/Public RSA Key pair ที่ใช้ในการ Authenticate เข้าใช้ Google Cloud APIs ซึ่งจะแบ่งเป็น 2 แบบ คือ

1. Google Managed Key จะเป็น Service Account ที่ Google จัดการโดยที่เราไม่ต้อง Generate Keys ขึ้นมาเอง มีความปลอดภัยสูง และใช้งานง่าย
2. User Managed Key เป็น Service Account ที่ User ต้องดูแลเอง สามารถ Download ออกมาได้เป็น JSON เมื่อ Download มาแล้ว User ต้องดูแลความปลอดภัยเอง และ ยอมรับความเสี่ยงให้ได้ Service Account แบบ User Managed Keys นั้นจะใช้ก็ต่อเมื่อเรามี Application ที่ใช้งานอยู่นอก Google Cloud Platform (AWS,Azure,Public Cloud,Private Cloud,Local Cloud,On-premise)

ใช้ Service Account ตอนไหนดี?

• เมื่อเรามี Application ที่จะต้องรันโดยที่เวลาทำงานกับ Google Cloud APIs จะไม่เด้ง Oauth2 มาให้กด Authenticate เช่น Test Google Cloud APIs ที่ Colab, On-premise Server, Hybrid Cloud, Muti Cloud. Service Account ก็สามารถนำมาใช้ได้หมด
• Background process ต่าง ๆ ที่จะต้องเชื่อมต่อกับ Google Cloud APIs.
• Server to Server
• Grant permission แบบ Least privilege โดยที่ไม่ต้อง Add User เข้าไปที่ Organization บน Google Cloud ก็สามารถทำได้ ประมาณว่าให้ Service Account ไปใช้เลย

ก่อนที่เราจะเรียกใช้ Service Account เราควรเข้าใจก่อนว่า

1. จะใช้ Service Account เข้าไปใข้งาน Service หรือ Resource อะไรบน Google Cloud
2. เราจะให้ Permission (สิทธิการเข้าถึง) Service Account ที่ระดับไหน หรือ ให้สิทธิอะไร
3. จะใช้ Service Account ที่ไหน Google Cloud หรือ On-premise

ทีนี้เรามาดูรูปภาพ Flow นี้ประกอบจะได้เข้าใจง่ายยิ่งขึ้น

ยกตัวอย่างสมมติเราจะใช้ Service Account ที่ On-premise และต้องการเพิ่ม Permission แบบเฉพาะเจาะจง หรือเรียกว่า least privilege ถ้าดูจาก flow นี้ เราจะได้ใช้ Serivce Account แบบ User Managed Keys และ ใช้ IAM แบบ Predefined Role.

Predefined Role กับ Primitive Role แตกต่างกันอย่างไร?

Primitive roles จะมีผลต่อ Google Cloud resource ทั้งหมด แต่ Predefined role จะมีผลต่อ Service แบบเฉพาะเจาะจง ใน Google Cloud สามารถดู Document ของ Google Cloud เพิ่มเติมได้ที่ : https://cloud.google.com/iam/docs/understanding-roles

วิธีการสร้าง Service Account? แบบใช้ Google Cloud Web interface

1. Log in ไปที่ Google Cloud Platform Console.

2. ดูว่าเราเลือก Project ถูกต้องมั้ย

3. ไปที่ Hamburger menu ที่ตำแหน่งบนซ้าย แล้วเลือกหา Identity > Service accounts

4. คลิ๊กที่ + CREATE SERVICE ACCOUNT

5. สร้าง Service Account ตั้งชื่อ มี Concept ประมาณนี้ทำ <team name>-<resources accessed>-<what your app does> ทำให้สามารถเข้าใจได้ง่ายยิ่งขึ้น และ สามารถใส่คำอธิบายเพิ่มเติมไปด้วยได้ที่ช่อง Description

6. กด Create จากนั้นเราต้องทำการให้ สิทธิ Service Account ตามที่เราต้องการ ยกตัวอย่างเช่น ทีม Cath ต้องการทำ Data pipeline โดยใช้ Cloud Storage และ BigQuery ในการทำ เราก็ให้ Role ที่เกี่ยวข้องไป

7. กด CONTINUE ต่อมาจะเป็นเกี่ยวกับให้สิทธิการเข้าถึง จัดการ หรือ ใช้ Service Account ตัวนี้เราสามารถเลือก User ที่เป็น Email หรือ Service Account ก็ได้

8. ถึงตอนนี้เราก็สร้าง Service Account ที่สามารถใช้ได้บน Google Cloud Platform เป็น Google Managed ที่นี้เราอยากนำไปใช้นอก Google Cloud Platform เป็น User Managed ทำยังไง เริ่มที่กลับไปที่หน้าแรกของ Service Account : Identity > Service accounts

9. กดที่ปุ่ม ... ด้านขวา แล้วกด > Create Key

10. กดสร้าง Private Key เลือก Key type เป็น JSON

11. การใช้งานก็สามารถนำไปใส่ใน Coding ได้หลากหลาย Language สามารถดู Library ได้โดยกดที่ link Google Cloud’s Client Libraries เช่น ต้องการใช้ Google Cloud APIs BigQuery โดยใช้ Pyhon

ต่อมาเมื่อเราเริ่มใช้ Service Account ที่เป็น User Managed แล้วเราต้องระวังในการใช้ให้มากขึ้นทีนี้เรามาดู ช่องโหว่ของการใช้ Service Account กัน

ช่องโหว่ของการใช้ Service Account

ตอนที่ใช้งาน บางคน หรือ บางบริษัท คงไม่ได้ลงทุน หรือ ศึกษาขั้นตอนการทำ Secret Management Solution ทำให้มีโอกาสที่จะทำให้ Service Account หลุดออกไปยังภายนอก Organization หรือ Environment ของเราได้ ซึ่งสามารถเหตุที่พบเจอได้บ่อยๆ เช่น เผลอ Push code ไปที่ Git repositoies ที่เป็น Public ซึ่งจะทำให้ Service Account ของเราหลุดออกไปโดยใช้เวลาไม่นาน เปิดอีกที Google Cloud เราจะถูกสร้าง VM Instance ที่ลงโปรแกรม Miner Cryptocurrency ไปแล้ววันถัดเราอาจดูเก็บค่าใช้งานไปเป็นล้านๆ ก็เป็นไปได้

การป้องกันช่องโหว่ในการใช้งาน Service Account

• พยายามอย่าใช้ Service Account ถ้าไม่จำเป็นจริงๆ
• พยายามใช้ Google Managed Service Account แทนที่จะใช้ User Managed Account
• ห้าม Upload Service Account ไปที่ที่เป็น Public
• ห้าม Push Service Account ไปที่ Git ที่เป็น Public
• ใช้ Secret Management Service จัดการ Service Account เช่น GCP Secret Manager , HashiCorp Vault
• อย่าให้ Role : Service Account User(ให้การเข้าถึงแบบ Indirect ไปที่ Resource ตามที่ Service Account นั้นๆ ได้รับ), Service Account Token Creator(สร้าง Service Account ได้) และ Project Owner(จัดการทรัพยากรใน Project นั้นๆ ได้หมด) กับใครถ้ายังไม่เข้าใจหลักการทำงาน
• ทำการตั้ง Condition ที่ Cloud IAM เช่น ตั้งเวลาทำงานของ Service Account ระบุว่าใครทำอะไรได้บ้างแบบ Least Priviledge

ถ้า Service Account หลุดไปแล้วทำอย่างไร?

1. Delete Service Account นั้นโดยทันที
2. ตรวจสอบ audit log เพื่อตรวจสอบผลกระทบที่เกิดขึ้น
3. เมื่อรู้ผลกระทบที่ได้รับแล้วควรไปปิดหรือลบ Service หรือ Resource นั้นๆ ออกไปโดยเร็วที่สุดเพื่อที่จะไม่ต้องถูกคิดเงินเพิ่ม
4. ติดต่อ Google หรือ partner เพื่อตรวจสอบและให้คำแนะนำต่อไป

Best Practice ของการใช้งาน Service Account

• ระบุว่าใครจะเป็นใช้ Service Account ตัวนั้นๆ แบบเจาะจง โดยใช้ Role : Service Account User
• ให้ Permission ของ Service Account ตามการใช้งานของมัน(Least Priviledge) ไม่ควรให้แบบ Primitive Role เช่น ไม่ควรให้ Role : Owner หรือ Edit ใน Service Account
• ใช้ Display Name และ Description ในการตั้งชื่อ Service Account เช่น Team Name - Service - Purpose
• ทำการ Implement process แบบการจัดการ Service Account แบบ Automate เช่น เมื่อใช้ Service Account เสร็จแล้วทำการ Trigger และ ลบ Service Account นั้นแบบอัตโนมัติ
• ทำการ Monitor Service Account อย่างสม่ำเสมอ โดยใช้ serviceAccount.keys.list() หรือ ดูในหน้า Log viewer ก็ได้
• ห้ามลบ Service Account ที่กำลังทำงานอยู่ เช่น เราใช้ Service Account ใน Backgroup process ที่ On-premise ถ้าเราลบ Service Account ออก process ทั้งหมดจะทำงานไม่ได้

ตอนนี้ก็จะได้เข้าใจว่า Service Account มันคืออะไร ทำงานแบบไหน กันแล้วนะครับ จะเห็นว่า Service Account เนี่ยมีทั้งประโยชน์ และ โทษ เลยใช่ไหมครับ ขอเตือนอีกครั้งนะครับการที่ Service Account leak ออกไปนี่อันตรายมาก ๆ นะครับเสียหายกันมาเยอะแล้ว แต่ถ้าประสบปัญหานี้อยู่สามารถติดต่อ Support ของ Google ได้นะครับ เดี๋ยวเค้าจะให้แนวทางการช่วยเหลือมาครับ หรือสามารถติดต่อ Partner ที่เราใช้บริการ Billing อยู่ก็ได้ครับ นอกจากตัว Service Account บน Google Cloud Platform ยังมีอะไรอีกหลายอย่างที่น่าเอามาอธิบายครับ เดี๋ยวจะเอามาเขียนเรื่อยๆ ครับ ถ้าว่างนะครับฮ่าา

บทความนี้ถ้าผิดพลาด หรือ ตกหล่นอะไรไป ขออภัยนะครับ มีความคำถามหรือสงสัยอะไรคอมเม้นกันได้ครับ

ขอบคุณครับ

Written by Thanatip Suwanchundee

Cloud Ace Thailand

Make It Now!

หากคุณสนต้องการคำปรึกษา Cloud Ace Thailand พร้อมให้บริการที่จะสนับสนุนคุณตั้งแต่ การให้คำปรึกษา จนถึงการออกแบบระบบ ติดตั้งระบบ ย้ายระบบ ในฐานะ Google Cloud Partner ที่มีความเชี่ยวชาญ และได้รับรางวัล Service partner of the year ในปี 2019

ติดต่อเรา th_sales@cloud-ace.com

Subscribe to us