ออกตัวก่อนว่าเหมือนบทความที่แล้ว เราอาจจะเขียนคล้ายๆ ประมาณโน้ตส่วนตัว สรุปคร่าวๆ แบบไม่ลงรายละเอียด เพราะไม่ได้เชี่ยวชาญ

ตอนที่ 1 ว่าด้วย Network & Security ไปแล้ว ตอนนี้มาพูดถึงอีกหัวข้อที่ต่างกันมากกว่านั้นอีก ซึ่งก็คือ IAM (Network ยังมีความคล้าย แต่ IAM นี่โครงสร้างไปคนละแนวทางกันเลย)

IAM หรือ Identity and Access Management เป็นระบบที่ควบคุมว่า "ใคร" (who) สามารถ "ทำอะไร" (what) กับ "ทรัพยากรไหน" (which) บนระบบ

AWS

Account vs User

AWS แยกคำว่า Account ออกจาก User

Account หมายถึง AWS Account (หรือเรียกว่า Root Account) เป็นเจ้าของทรัพยากรทั้งหมด และเป็นตัวตนที่ใช้ในการจ่ายเงิน

• ในเคสปกติ ล็อกอินโดยใช้อีเมลที่สมัคร (ยกเว้นกรณี multi-account)
• ในเคสปกติ มีสิทธิ์สูงสุด ทำได้ทุกอย่าง (ยกเว้นถูกบล็อกด้วย Service Control Policy ซึ่งเป็นนโยบายที่ใช้ควบคุมสิทธิ์ของบัญชี)
• ใช้สร้าง admin คนแรก (หลังจากนั้นปล่อยให้ admin จัดการสร้าง user คนถัดๆ ไปเอง) และจัดการเรื่อง billing เท่านั้น ไม่แนะนำให้ใช้ในงานทั่วไป เพราะมีสิทธิ์สูงเกินไป

ส่วน User หมายถึง IAM User คือตัวตนที่ถูกสร้างขึ้นมาภายใต้บัญชี เพื่อใช้ทำงานในระบบ

• ล็อกอินโดยใช้ credentials ที่ admin สร้างให้
• มีสิทธิ์แค่ตามที่ admin กำหนดให้เท่านั้น
• ใช้ทำงานต่างๆ นอกเหนือจากการสร้าง user

AWS IAM Entities

IAM User ที่กล่าวถึงไป ก็เป็นหนึ่งใน IAM Entities ซึ่งเป็นตัวแทนคำว่า "ใคร" ใน IAM นั่นเอง

โดยที่ IAM Entities จะมี 3 แบบหลักๆ ตามนี้

• IAM User: เป็นตัวตนที่ใช้แทนคน มีข้อมูลยืนยันตัวตนแบบถาวร (permanent credentials) เช่น username/password หรือ access keys
• IAM Group: กลุ่มของ User ใช้สำหรับจัดชุดสิทธิ์ (Policy) ให้หลายคนพร้อมกัน (อันนี้ไม่สามารถล็อกอินได้)
• IAM Role: เป็นตัวตนแบบชั่วคราว ไม่มีรหัสผ่านถาวร เหมือนการขอใบรับรองชั่วคราวเพื่อใช้ทำงาน ให้สิทธิ์เข้าถึงทรัพยาการ โดยอาศัยกระบวนการที่เรียกว่า "Assume Role"

มาถึงตรงนี้ก็อาจจะยังไม่เห็นภาพว่า IAM Role (ต่อไปนี้จะเรียกแค่ Role) มีไว้ทำไม แต่เจ้า Role เนี่ยแหละที่ใช้เยอะมาก ตัวอย่างเช่น

1) ใช้สำหรับบริการ AWS (Service Role)

อันนี้เป็นกรณีที่ใช้กันบ่อยสุด คือการให้สิทธิ์กับบริการของ AWS เพื่อไปทำงานบางอย่าง

เนื่องจากว่าแต่ละบริการของ AWS ไม่ได้เรียกกันเองได้โดยอัตโนมัติ เช่น มีเครื่อง EC2 อยากจะอ่านไฟล์ใน S3 ถ้าเราไม่ทำอะไรเลยมันจะไม่มีสิทธิ์คุยกัน เราต้องสร้าง Role ที่ให้สิทธิ์อ่านไฟล์จาก S3 แล้วเอาไปผูกไว้กับ EC2 เพื่อมันสามารถทำงานของมันได้

2) ใช้สำหรับข้าม Account (Cross-Account Access)

กรณีที่มีหลายบัญชี (multi-account) เราสามารถทำให้ user จาก Account A เข้าไปทำอะไรใน Account B ได้ โดยการสร้าง Role ใน Account B โดยกำหนดให้อนุญาตให้คนจาก Account A เข้ามาได้

3) ใช้สำหรับล็อกอินจากระบบภายนอก

เช่น การล็อกอินด้วย Google, Microsoft 365 หรือบริการอื่น เพื่อเข้ามาทำงานใน AWS
ระบบจะไม่มีได้สร้าง User ให้ใน AWS แต่จะใช้การผูก Role ให้หลังจากการยืนยันตัวตนจากข้างนอก

4) ใช้สำหรับเชื่อมต่อกับระบบภายนอก

สำหรับการเชื่อมต่อการใช้บริการจากระบบภายนอก จำเป็นต้องสร้าง Role ให้กับบริการนั้นๆ

AWS IAM Policies

พูดถึง "ใคร" ในระบบ IAM ไปแล้ว มาถึง "ทำอะไร" กับ "ทรัพยากรไหน" กันบ้าง สิ่งที่กำหนดทั้ง 2 อย่างนี้ก็คือ Policy นั่นเอง

Policy เป็นเอกสารรูปแบบ JSON ที่ระบุว่า อนุญาต (Allow) หรือ ปฏิเสธ (Deny) การเข้าถึงส่วนไหนในระบบ หน้าตาอะไรประมาณนี้

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "s3:ListBucket",
      "Resource": "arn:aws:s3:::my-bucket"
    }
  ]
}

อธิบาย JSON

• Version: เวอร์ชั่นของภาษา Policy ซึ่งปัจจุบัน AWS บังคับใช้ค่าเดียวคือ 2012-10-17
• Effect: Allow หรือ Deny
• Action: ทำอะไร
• Resource: ทรัพยากรไหน

หมายเหตุ: สังเกตว่าใน 1 Policy กำหนดได้หลายสิทธิ์ (Statement เป็น list)

GCP

ทางฝั่ง GCP ก่อนจะพูดถึง IAM จะต้องว่าด้วย "ลำดับชั้นของทรัพยากร" (Resource Hierarchy) กันก่อน

เจ้าลำดับชั้นนี้ทำหน้าที่เหมือนแผนผังองค์กร ช่่วยในการจัดการกับทรัพยากรจำนวนมากโดยอาศัยการสืบทอดนโยบาย เช่น การกำหนดสิทธิ์เข้าถึง หรือว่าการตั้งค่าความปลอดภัย ที่จะสืบทอดจากชั้นบนสู่ชั้นล่าง

GCP Resource Hierarchy

1) Organization

• เป็นจุดสูงสุดของโครงสร้าง
• เชื่อมต่อกับโดเมนของบริษัท เช่น Google Workspace หรือ Cloud Identity
• ช่วยให้มองเห้นและควบคุมทรัพยากรทั้งหมดในบริษัทได้จากที่เดียว

2) Folder

• เป็นตัวเลือกเสริม จะมีหรือไม่มีก็ได้
• สามารถมี folders ย่อยซ้อนกันกี่ชั้นก็ได้
• ใช้สำหรับแบ่งกลุ่ม เช่น แบ่งตามแผนก (ฝ่ายไอที, ฝ่ายการตลาด) หรือแบ่งตามสภาพแวดล้อม (development, production)

3) Project

• เป็นหัวใจสำคัญ ทรัพยากรทุกอย่างจะต้องอยู่ภายใต้ Project เสมอ
• เป็นระดับที่ใช้ในการจัดการเรื่อง billing และการเปิดใช้ API ต่างๆ
• Project ID จะต้องไม่ซ้ำกันเลยใน GCP

4) Resource

• บริการของ GCP ที่เราใช้งานกัน

ข้อดีของลำดับชั้นนี้คือ สามารถใช้ประโยชน์จากการสืบทอดสิทธิ์ และยังช่วยให้สามารถจัดกลุ่มทรัพยากรเพื่อให้สรุปค่าใช้จ่ายได้ง่ายและมีประสิทธิภาพ

GCP IAM Principals

กลับมาที่ IAM กันต่อ ส่วนแรกของ IAM ก็คือ "ใคร" สำหรับ GCP จะเรียกว่า Principals หรือ Members

ประกอบด้วย

• Google Account: อีเมลส่วนตัว (@gmail.com)
• Service Account: บัญชีสำหรับ "แอปพลิเคชั่น" หรือ "เครื่อง" (Machine) เพื่อคุยกันเอง ไม่ต้องมีรหัสผ่าน ใช้กุญแจเข้ารหัส (Cryptographic Keys) ในการยืนยันตัวตน
• Google Group: กลุ่มของ User
• Google Workspace / Cloud Identity: บัญชีขององค์กร

GCP IAM Roles

ส่วนนี้คือตัวแทนของ "ทำอะไร" ใน IAM

เป็นชุดของสิทธิ์ในการเข้าถึงทรัพยาการ (อย่าสับสนกับ Roles ของ AWS) ซึ่งใน GCP ไม่ได้แยกเป็น permission แต่ละเรื่องย่อยๆ แต่จะมัดรวมกันอยู่ใน Role

โดยจะแบ่งออกเป็น 3 ประเภท

1) Basic Roles

เป็นพวก Role พื้นฐานของ GCP ที่ให้สิทธิ์กว้างๆ มี 3 อย่างคือ Owner, Editor, Viewer

2) Predefined Roles

เป็นพวก Role ที่ Google เตรียมไว้ให้ตามหน้าที่งาน เจาะจงไปที่แต่ละบริการ เช่น Storage Admin หรือ Compute Viewer

3) Custom Roles

เป็น Role ที่ user สร้างขึ้นเอง ใช้เมื่อต้องการสิทธิ์การใช้งานที่เฉพาะเจาะจง

GCP IAM Policy

เป็นตัวเชื่อม Principal กับ Role เข้าด้วยกัน โดยจะเป็น resource-based คือเราจะเอาไปผูกไว้กับทรัพยากร (ในขณะที่ใน AWS เราจะเอา Policy ไปผูกไว้ที่ User)

หน้าตาของ Policy ใน GCP จะเป็นประมาณนี้

{
  "bindings": [
    {
      "role": "roles/storage.admin",
      "members": [
        "user:storage-admin@example.com",
        "serviceAccount:my-app@project.iam.gserviceaccount.com"
      ]
    },
    {
      "role": "roles/viewer",
      "members": ["group:dev-group@example.com"]
    }
  ],
  "etag": "xxxx",
  "version": 1
}

หมายเหตุ: โดยปกติ GCP IAM Policy คือการ Allow เท่านั้น ถ้าต้องการ Deny จะใช้ Deny Policy แยก

สรุปความต่าง

• โครงสร้าง IAM ของ AWS โดยพื้นฐานเป็นแบบ flat (แต่สามารถสร้าง Organzation Unit ได้จากบริการ AWS Organization) ในขณะที่ GCP เป็นลำดับชั้นลงมา
• ส่วน "ใคร" ของ IAM ใน AWS เรียก Entities ส่วนใน GCP เรียก Principal
• การทำงานกับ resource ในระบบ AWS จะใช้ Role ส่วนใน GCP ใช้ Service Account
• AWS IAM Policy ใช้กำหนดส่วน "ทำอะไร" กับ "ทรัพยากรไหน" แล้วใช้ผูกกับ Entities (Identity-based) ส่วน GCP IAM Policy ใช้เชื่อม "ใคร" เข้ากับสิทธิ์อนุญาติให้ "ทำอะไร" แล้วนำไปผูกกับทรัพยากร (Resource-based)
• AWS IAM Policy สามารถกำหนดได้ทั้ง Allow หรือ Deny ส่วน GCP IAM Policy โดยพื้นฐานจะเป็น allow-only