Phân Tích Chuyên Sâu về Google Cloud Identity and Access Management (IAM)

Mục Lục Phân Tích Chuyên Sâu về Google Cloud Identity and Access Management (IAM)

Phần 1: Giới thiệu & Khái niệm Cơ bản về IAM
- 1.1. IAM là gì? Tại sao chúng ta cần nó?
- 1.2. Các Thành phần Chính của IAM
  - 1.2.1. Thành phần "Who": Danh tính (Principal / Member)
  - 1.2.2. Thành phần "What": Vai trò (Role) chứa các Quyền (Permissions)
  - 1.2.3. Thành phần "Where": Tài nguyên trong Hệ thống phân cấp Tài nguyên
- 1.3. IAM Policy (Chính sách IAM)
- 1.4. Policy Evaluation (Đánh giá Chính sách)
- 1.5. Hệ thống phân cấp Tài nguyên và Tính kế thừa (Inheritance)
Phần 2: Khám phá Chi tiết các Thành phần của IAM
- 2.1. Thành phần "Who" Chuyên Sâu: Tài khoản Dịch vụ (Service Accounts)
  - Tại sao cần Tài khoản Dịch vụ?
  - Cấu trúc và Định dạng
  - Các Loại Tài khoản Dịch vụ (User-managed, Google-managed, Default)
  - Xác thực và Ủy quyền cho Tài khoản Dịch vụ (Cấp quyền CHO SA vs. Sử dụng SA)
  - Cách Xác thực (Keys vs. Không cần Khóa: VM attached SA, API Scopes, Workload Identity)
  - Quản lý Tài khoản Dịch vụ
  - Thực hành Tốt với Tài khoản Dịch vụ
- 2.2. Phân tích Chi tiết về Vai trò (Roles)
  - 2.2.1. Vai trò Cơ bản (Primitive Roles) - Owner, Editor, Viewer, Billing User
  - 2.2.2. Vai trò Định sẵn (Predefined Roles) - Cấu trúc tên, Phạm vi, Ví dụ phổ biến
  - 2.2.3. Vai trò Tùy chỉnh (Custom Roles) - Cách hoạt động, Ưu/Nhược điểm, Tạo
  - Thực hành Tốt với Vai trò
- 2.3. Chính sách Ràng buộc có Điều kiện (IAM Conditions) - Mục đích, Cách hoạt động, Ví dụ
Phần 3: Quản lý IAM Policies và Thực Hành (Đang viết...)
- 3.1. Xem Chính sách IAM Hiện tại
- 3.2. Cấp (Thêm) Quyền - Thêm Bindings vào Policy
- 3.3. Thu Hồi (Xóa) Quyền - Xóa Bindings khỏi Policy
- 3.4. Sử dụng Google Cloud Console để Quản lý IAM
- 3.5. Sử dụng gcloud Command-Line Tool để Quản lý IAM
- 3.6. Sử dụng API và Infrastructure as Code (Terraform, Deployment Manager)
Phần 4: Các Nguyên tắc Bảo mật IAM Cơ bản và Thực Hành Tốt Nhất
- 4.1. Nguyên tắc Least Privilege (Quyền hạn Tối thiểu)
- 4.2. Separation of Duties (Phân tách Trách nhiệm)
- 4.3. Sử dụng Nhóm Google (Google Groups)
- 4.4. Tránh Khóa Tài khoản Dịch vụ (Avoiding Service Account Keys)
- 4.5. Bảo vệ Khóa SA nếu Bắt Buộc Phải Dùng
- 4.6. Sử dụng IAM Recommendations
Phần 5: Giám Sát, Kiểm Tra và Khắc Phục Sự Cố IAM
- 5.1. Cloud Audit Logs (Nhật ký Kiểm tra) cho IAM
- 5.2. IAM Policy Troubleshooter
- 5.3. Security Command Center và Web Security Scanner (liên quan đến lỗ hổng IAM)
Phần 6: IAM trong Bối cảnh Google Cloud Rộng Hơn
- 6.1. IAM và Hệ thống phân cấp Tài nguyên (Organization, Folder, Project)
- 6.2. IAM và Billing (Thanh toán)
- 6.3. IAM và Organization Policies (Chính sách Tổ chức) - Khác biệt và liên quan
- 6.4. IAM và Các Dịch vụ Khác của Google Cloud
Phần 7: Chuẩn Bị cho Kỳ thi Google Cloud Associate Cloud Engineer - Phần IAM
- 7.1. Các Chủ đề IAM Quan trọng nhất cần Nắm vững cho Kỳ thi
- 7.2. Các Dạng Câu hỏi Thường Gặp về IAM
- 7.3. Lời Khuyên Ôn Tập Hiệu Quả cho IAM

Google Cloud Identity and Access Management (IAM) là một trong những dịch vụ quan trọng nhất và cốt lõi nhất mà bạn cần nắm vững khi làm việc với Google Cloud. Nó không chỉ là một phần không thể thiếu trong việc xây dựng các hệ thống an toàn và bảo mật trên nền tảng đám mây, mà còn là chủ đề thường xuyên xuất hiện trong các bài thi chứng chỉ, bao gồm cả Associate Cloud Engineer.

Đừng lo lắng nếu bạn chưa biết gì. Chúng ta sẽ đi từ những khái niệm cơ bản nhất, từng bước một, để hiểu rõ IAM là gì, tại sao chúng ta cần nó, cách nó hoạt động và làm thế nào để sử dụng nó một cách hiệu quả và an toàn trên Google Cloud.

Mục tiêu của phần phân tích này là cung cấp cho bạn một cái nhìn toàn diện, chi tiết và chuyên sâu về IAM, đủ để bạn tự tin cấu hình, quản lý quyền truy cập trong các tình huống thực tế và quan trọng nhất là chuẩn bị tốt nhất cho phần thi liên quan đến IAM trong kỳ thi Associate Cloud Engineer.

Hãy bắt đầu hành trình khám phá IAM nhé!

Phần 1: Giới thiệu & Khái niệm Cơ bản về IAM

1.1. IAM là gì? Tại sao chúng ta cần nó?

Hãy tưởng tượng Google Cloud là một tòa nhà văn phòng khổng lồ chứa rất nhiều tài nguyên giá trị: máy chủ, dữ liệu, ứng dụng, mạng lưới... Ai cũng muốn truy cập vào đây để làm việc, nhưng rõ ràng không phải ai cũng được phép đi đến mọi nơi, mở mọi cửa, hay sử dụng mọi thiết bị.

Identity and Access Management (IAM) chính là hệ thống bảo vệ và quản lý quyền truy cập cho tòa nhà kỹ thuật số này.

Identity (Danh tính): Xác định ai là người đang cố gắng truy cập. Đây có thể là một người dùng cụ thể, một nhóm người, hoặc thậm chí là một ứng dụng/dịch vụ khác.
Access (Truy cập): Xác định những gì mà danh tính đó được phép làm. Được phép đọc dữ liệu? Được phép tạo máy chủ ảo? Được phép xóa tài nguyên?
Management (Quản lý): Là quá trình cấu hình, kiểm soát, và kiểm tra các quy tắc về danh tính và quyền truy cập này.

Tại sao chúng ta cần IAM?

Trong môi trường đám mây, tài nguyên được chia sẻ và truy cập từ khắp nơi trên thế giới. Nếu không có IAM, mọi tài nguyên sẽ hoặc là hoàn toàn công khai (rất nguy hiểm), hoặc hoàn toàn riêng tư (không thể sử dụng được).

IAM giải quyết các vấn đề cốt lõi sau:

Bảo mật: Ngăn chặn truy cập trái phép vào tài nguyên nhạy cảm. Chỉ những người hoặc dịch vụ được phép mới có thể thực hiện các hành động nhất định.
Tuân thủ: Giúp tổ chức đáp ứng các yêu cầu về bảo mật và tuân thủ quy định của ngành hoặc pháp luật (ví dụ: ai đã truy cập dữ liệu X lúc nào?).
Hiệu quả: Cho phép chia sẻ tài nguyên một cách an toàn giữa các nhóm, phòng ban hoặc thậm chí là các tổ chức khác nhau, mà không cần phải sao chép hoặc di chuyển dữ liệu.
Kiểm soát: Cung cấp khả năng kiểm soát chi tiết về quyền truy cập, giúp áp dụng nguyên tắc "least privilege" (quyền truy cập ít nhất cần thiết).
Giám sát: Ghi lại các hoạt động liên quan đến quyền truy cập, cho phép kiểm tra và phát hiện các hành động đáng ngờ.

Tóm lại: IAM là nền tảng bảo mật của Google Cloud, đảm bảo rằng đúng người/dịch vụ có đúng quyền để truy cập đúng tài nguyên vào đúng thời điểm.

1.2. Các Thành phần Chính của IAM

Để hiểu IAM hoạt động như thế nào, chúng ta cần nắm vững 3 thành phần cốt lõi:

Who (Ai): Danh tính (Principal / Member)
What (Làm gì): Vai trò (Role) chứa các Quyền (Permissions)
Where (Ở đâu): Tài nguyên (Resource) trong Hệ thống phân cấp Tài nguyên (Resource Hierarchy)

Chúng ta sẽ đi sâu vào từng thành phần này.

1.2.1. Thành phần "Who": Danh tính (Principal / Member)

"Who" là thực thể đang cố gắng truy cập tài nguyên Google Cloud. IAM gọi thực thể này là Member hoặc Principal. Có nhiều loại Member khác nhau trong Google Cloud:

Tài khoản Google (Google Account):
- Đây là tài khoản mà hầu hết chúng ta đều quen thuộc (ví dụ: ten_cua_ban@gmail.com).
- Nó đại diện cho một người dùng cá nhân.
- Tài khoản này được quản lý bởi Google.
Tài khoản Người dùng Google Workspace hoặc Cloud Identity (Google Workspace / Cloud Identity User Account):
- Đây là tài khoản được quản lý bởi một tổ chức (ví dụ: ten.ban@congtyban.com).
- Tài khoản này thuộc về một domain được quản lý bởi Google Workspace hoặc Cloud Identity của tổ chức bạn.
- Thường là cách chính để cấp quyền cho nhân viên trong một công ty.
Nhóm Google (Google Group):
- Đây là một tập hợp các Tài khoản Google hoặc Tài khoản Người dùng Workspace/Cloud Identity (ví dụ: nhom-dev@congtyban.com).
- Bạn cấp quyền cho cả nhóm thay vì từng người dùng riêng lẻ. Điều này giúp quản lý quyền hiệu quả hơn, đặc biệt với các nhóm lớn hoặc khi có sự thay đổi nhân sự. Khi một người rời nhóm, họ mất quyền của nhóm; khi một người vào nhóm, họ nhận quyền của nhóm.
- Lưu ý: Nhóm Google không có mật khẩu riêng hoặc key riêng. Quyền của nhóm chỉ áp dụng cho các thành viên của nhóm.
Tài khoản Dịch vụ (Service Account):
- Đây là một danh tính đặc biệt đại diện cho một ứng dụng hoặc máy ảo (VM), không phải một người dùng cuối.
- Chúng được sử dụng để các ứng dụng hoặc dịch vụ của bạn truy cập vào các tài nguyên Google Cloud khác (ví dụ: một ứng dụng chạy trên Compute Engine cần ghi dữ liệu vào Cloud Storage).
- Tài khoản dịch vụ được xác thực bằng cách sử dụng khóa (key) hoặc thông qua cơ chế tích hợp của Google Cloud (như attaching SA to a VM).
- Đây là một khái niệm cực kỳ quan trọng trong Google Cloud và cho kỳ thi Associate, chúng ta sẽ đi sâu hơn ở phần sau.
Domain Google Workspace / Cloud Identity (Google Workspace / Cloud Identity Domain):
- Đại diện cho tất cả người dùng trong một domain cụ thể của tổ chức bạn (ví dụ: congtyban.com).
- Việc cấp quyền cho cả domain thường được sử dụng cho các quyền truy cập rất chung chung hoặc cho các tài nguyên không nhạy cảm.
Người dùng được xác thực trên Internet (Authenticated Users):
- Đại diện cho bất kỳ người dùng nào đã đăng nhập bằng Tài khoản Google. Rất hiếm khi sử dụng cho các tài nguyên nhạy cảm.
Tất cả người dùng trên Internet (All Users):
- Đại diện cho bất kỳ ai trên Internet, có hoặc không có Tài khoản Google. Cấp quyền cho "All Users" làm cho tài nguyên trở nên công khai (public). Cực kỳ cẩn trọng khi sử dụng quyền này.

Tóm lại về "Who": IAM cần biết ai đang cố gắng truy cập để quyết định xem có nên cho phép hay không. Các "Ai" này có thể là người, nhóm người, hoặc ứng dụng/dịch vụ.

1.2.2. Thành phần "What": Vai trò (Role) và Quyền (Permissions)

"What" là hành động hoặc tập hợp hành động mà một danh tính được phép thực hiện trên một tài nguyên.

Quyền (Permission):
- Đây là các quyền hạn chi tiết nhất trong IAM. Mỗi quyền cho phép thực hiện một hành động cụ thể trên một loại tài nguyên cụ thể.
- Tên quyền thường có định dạng: {service}.{resource}.{verb}.
  - {service}: Dịch vụ Google Cloud (ví dụ: compute, storage, pubsub).
  - {resource}: Loại tài nguyên trong dịch vụ đó (ví dụ: instances, buckets, topics).
  - {verb}: Hành động được phép thực hiện (ví dụ: get, list, create, delete, update, setIamPolicy).
- Ví dụ về Quyền:
  - compute.instances.list: Cho phép liệt kê (xem danh sách) các máy ảo Compute Engine.
  - storage.buckets.create: Cho phép tạo một bucket Cloud Storage.
  - pubsub.topics.publish: Cho phép gửi tin nhắn đến một topic Pub/Sub.
  - resourcemanager.projects.delete: Cho phép xóa một dự án Google Cloud.
  - iam.serviceAccounts.create: Cho phép tạo một tài khoản dịch vụ.
- Có hàng ngàn quyền khác nhau trong Google Cloud, mỗi quyền tương ứng với một chức năng API cụ thể.
Vai trò (Role):
- Một Vai trò là một tập hợp các Quyền được đặt tên. Thay vì cấp từng quyền riêng lẻ (rất phức tạp và khó quản lý), bạn cấp cho danh tính một Vai trò.
- IAM quản lý quyền thông qua vai trò.
- Google Cloud có ba loại Vai trò chính:
  - Vai trò Cơ bản (Primitive Roles):
    - Đây là các vai trò rất rộng và được định nghĩa từ lâu. Chúng tương ứng với các cấp độ truy cập trên toàn bộ dự án:
      - Owner (Chủ sở hữu): Có tất cả quyền hạn, bao gồm cả quản lý quyền IAM và quản lý Billing. Rất mạnh.
      - Editor (Người chỉnh sửa): Có quyền tạo và chỉnh sửa hầu hết các tài nguyên trong dự án, nhưng không thể quản lý quyền IAM hoặc Billing.
      - Viewer (Người xem): Chỉ có quyền xem (read-only) hầu hết các tài nguyên trong dự án.
    - Quan trọng: Vai trò cơ bản cung cấp quyền truy cập rất rộng trên tất cả các dịch vụ trong dự án. Ví dụ, một Editor có thể chỉnh sửa máy ảo, quản lý Cloud Storage, gửi tin nhắn Pub/Sub, v.v.
    - Lời khuyên & Thực hành Tốt: Google không khuyến khích sử dụng Vai trò Cơ bản cho các hoạt động hàng ngày hoặc cho tài khoản dịch vụ trong môi trường production do phạm vi quyền hạn quá rộng của chúng. Chỉ nên sử dụng cho mục đích quản trị ban đầu hoặc trong các môi trường thử nghiệm không nhạy cảm.
    - Lý do không khuyến khích: Việc cấp quyền quá mức cần thiết vi phạm nguyên tắc "least privilege" và tăng nguy cơ bảo mật.
  - Vai trò Định sẵn (Predefined Roles):
    - Đây là các vai trò được Google tạo ra và quản lý. Chúng cung cấp quyền truy cập chi tiết hơn vào các tài nguyên cụ thể của các dịch vụ Google Cloud.
    - Ví dụ: roles/compute.instanceAdmin.v1 (cho phép quản lý các máy ảo Compute Engine), roles/storage.objectViewer (chỉ cho phép xem các object trong Cloud Storage), roles/pubsub.publisher (chỉ cho phép gửi tin nhắn đến Pub/Sub topics).
    - Tên của vai trò định sẵn thường tuân theo định dạng: roles/{service}.{role_description}. Phiên bản (v1) đôi khi được thêm vào cuối.
    - Các vai trò định sẵn là cách được khuyến khích để cấp quyền truy cập cho hầu hết các trường hợp sử dụng, vì chúng cho phép áp dụng nguyên tắc "least privilege" hiệu quả hơn vai trò cơ bản.
    - Bạn có thể xem danh sách đầy đủ các vai trò định sẵn và các quyền mà chúng chứa trong tài liệu IAM của Google Cloud. Đối với kỳ thi Associate, bạn không cần nhớ tất cả các vai trò, nhưng cần biết cách tìm kiếm vai trò phù hợp và hiểu sự khác biệt giữa các vai trò phổ biến của các dịch vụ chính (Compute Engine, Storage, VPC, SQL, Pub/Sub, IAM).
  - Vai trò Tùy chỉnh (Custom Roles):
    - Nếu các vai trò định sẵn không đáp ứng được nhu cầu cụ thể của bạn (ví dụ: bạn cần một tập hợp quyền rất đặc thù không có trong bất kỳ vai trò định sẵn nào), bạn có thể tạo Vai trò Tùy chỉnh.
    - Vai trò tùy chỉnh là tập hợp các quyền do bạn lựa chọn.
    - Bạn định nghĩa vai trò tùy chỉnh ở cấp độ Tổ chức (Organization) hoặc Dự án (Project). Vai trò tùy chỉnh được định nghĩa ở cấp độ cao hơn có thể được sử dụng ở cấp độ thấp hơn trong hệ thống phân cấp tài nguyên.
    - Việc tạo vai trò tùy chỉnh giúp bạn tuân thủ chặt chẽ nguyên tắc "least privilege".
    - Tuy nhiên, việc quản lý các vai trò tùy chỉnh có thể phức tạp hơn vai trò định sẵn.

Tóm lại về "What": Quyền là hành động cụ thể, vai trò là tập hợp các quyền. Sử dụng vai trò định sẵn hoặc tùy chỉnh là cách tốt nhất để cấp quyền dựa trên nguyên tắc "least privilege", tránh vai trò cơ bản rộng.

1.2.3. Thành phần "Where": Tài nguyên và Hệ thống phân cấp Tài nguyên

"Where" là tài nguyên Google Cloud mà danh tính đang cố gắng truy cập. IAM kiểm soát quyền truy cập vào các tài nguyên.

Tài nguyên (Resources): Đây là các "đối tượng" trong Google Cloud, ví dụ: máy ảo Compute Engine, bucket Cloud Storage, cơ sở dữ liệu Cloud SQL, mạng VPC, topic Pub/Sub, dự án (Project), thư mục (Folder), tổ chức (Organization), v.v.
Hệ thống phân cấp Tài nguyên (Resource Hierarchy): Google Cloud tổ chức các tài nguyên của bạn theo cấu trúc phân cấp hình cây:
```
Organization (Tổ chức) - Cấp cao nhất, tùy chọn
    |
    --- Folders (Thư mục) - Tùy chọn
        |
        --- Projects (Dự án) - Bắt buộc phải có
            |
            --- Resources (Tài nguyên cụ thể: VMs, Buckets, Pub/Sub Topics, v.v.)
```
- Organization: Đại diện cho một công ty hoặc tổ chức. Cấp cao nhất trong hệ thống phân cấp, thường gắn với một tài khoản Google Workspace hoặc Cloud Identity. Quyền được cấp ở cấp Organization áp dụng cho tất cả các Folder và Project bên dưới nó.
- Folders: Cung cấp một lớp nhóm giữa Organization và Projects. Hữu ích để nhóm các dự án theo đội ngũ, ứng dụng, môi trường (dev/stage/prod), v.v. Quyền được cấp ở cấp Folder áp dụng cho Folder đó và tất cả các Project bên dưới nó.
- Projects: Là đơn vị tổ chức bắt buộc cho tài nguyên. Tất cả các tài nguyên Compute Engine, Storage, Pub/Sub, v.v., đều thuộc về một Project cụ thể. Project là biên giới tính phí và thường là biên giới quản lý chính. Quyền được cấp ở cấp Project áp dụng cho tất cả các tài nguyên bên trong Project đó (trừ khi bị ghi đè ở cấp độ tài nguyên).
- Resources: Các tài nguyên cụ thể (VM, Bucket, Topic, ...). Trong một số trường hợp (không phải tất cả), bạn có thể cấp quyền IAM ở cấp độ tài nguyên cụ thể (ví dụ: cấp quyền truy cập vào một bucket Cloud Storage cụ thể).

Tóm lại về "Where": IAM kiểm soát quyền truy cập vào tài nguyên. Các tài nguyên được tổ chức theo hệ thống phân cấp (Organization -> Folders -> Projects -> Resources). Vị trí của tài nguyên trong hệ thống phân cấp ảnh hưởng đến cách các chính sách IAM được áp dụng.

1.3. IAM Policy (Chính sách IAM)

Đây là thành phần kết nối "Who", "What", và "Where".

IAM Policy: Là một tập hợp các ràng buộc (bindings) được đính kèm vào một tài nguyên (Organization, Folder, Project, hoặc một tài nguyên cụ thể như Bucket).
Binding (Ràng buộc): Là mối liên kết giữa một hoặc nhiều danh tính (Members) và một Vai trò (Role). Nói cách khác, một binding gán một vai trò cho một danh tính.
- Cấu trúc cơ bản của một binding: "Những danh tính này có vai trò này".
- Một policy có thể có nhiều bindings.
- Một binding có thể có nhiều danh tính.
- Một danh tính có thể có nhiều vai trò thông qua các bindings khác nhau trên cùng một policy hoặc các policy khác nhau trong hệ thống phân cấp.

Ví dụ về một phần IAM Policy (định dạng JSON):

json

{
  "bindings": [
    {
      "role": "roles/storage.objectViewer",
      "members": [
        "user:alice@example.com",
        "serviceAccount:my-app-service-account@my-project-id.iam.gserviceaccount.com"
      ]
    },
    {
      "role": "roles/compute.instanceAdmin.v1",
      "members": [
        "group:compute-admins@company.com"
      ]
    }
  ],
  // Các thông tin khác của policy...
}

Policy này chứa hai bindings.
Binding thứ nhất gán vai trò roles/storage.objectViewer cho hai danh tính: một người dùng (alice@example.com) và một tài khoản dịch vụ.
Binding thứ hai gán vai trò roles/compute.instanceAdmin.v1 cho một nhóm Google (compute-admins@company.com).

Policy này được đính kèm vào một tài nguyên cụ thể (ví dụ: một project). Bất kỳ ai hoặc dịch vụ thuộc các danh tính trong policy này sẽ có các quyền được định nghĩa bởi các vai trò tương ứng trên tài nguyên đó (và các tài nguyên con bên dưới nó, do tính kế thừa).

1.4. Policy Evaluation (Đánh giá Chính sách)

Khi một danh tính cố gắng thực hiện một hành động trên một tài nguyên, IAM sẽ kiểm tra các chính sách (policy) để xác định xem hành động đó có được phép hay không. Quá trình này tuân theo logic sau:

IAM kiểm tra chính sách được đính kèm trực tiếp vào tài nguyên đó.
IAM kiểm tra các chính sách được đính kèm vào các tài nguyên cha (Project, Folder, Organization) trong hệ thống phân cấp.
Các chính sách IAM có tính chất "Additive" (Cộng gộp): Tất cả các quyền mà danh tính nhận được từ các vai trò được gán cho nó (trực tiếp trên tài nguyên hoặc kế thừa từ các tài nguyên cha) sẽ được cộng gộp lại.
Kết quả: Nếu bất kỳ chính sách nào (trên tài nguyên hoặc cha của nó) cấp cho danh tính đó một vai trò chứa quyền cần thiết để thực hiện hành động, thì hành động đó sẽ được phép.

Ví dụ về tính Additive:

Bạn là thành viên của nhom-dev@company.com. Nhóm này được cấp vai trò roles/compute.viewer trên Project A.
Tài khoản người dùng của bạn (ban@company.com) được cấp vai trò roles/storage.admin trực tiếp trên Project A.
Trên Project A, bạn sẽ có cả quyền của roles/compute.viewer (qua nhóm) VÀ quyền của roles/storage.admin (trực tiếp). Tổng số quyền của bạn là tập hợp của tất cả các quyền từ cả hai vai trò này.

Hệ quả của tính Additive: Để cấp quyền, bạn thêm một binding. Để loại bỏ quyền, bạn phải xóa bỏ tất cả các bindings (trực tiếp hoặc qua nhóm/domain/kế thừa) mà cấp cho danh tính đó vai trò chứa quyền đó.

Lưu ý về Deny Policies (Chính sách Từ chối): Gần đây, Google Cloud đã giới thiệu tính năng IAM Deny Policies. Khác với chính sách "Allow" truyền thống có tính additive, Deny Policies luôn luôn ghi đè lên Allow Policies. Nếu một quyền bị từ chối bởi Deny Policy ở bất kỳ cấp độ nào trong hệ thống phân cấp, thì hành động đó sẽ bị từ chối, bất kể có bao nhiêu Allow Policies cho phép nó. Tuy nhiên, trọng tâm chính cho kỳ thi Associate vẫn là hiểu rõ cơ chế Allow truyền thống và tính additive/kế thừa. Deny Policies là một tính năng nâng cao hơn. Chúng ta sẽ đề cập ngắn gọn sau nếu cần, nhưng hãy tập trung vào mô hình Allow trước.

1.5. Hệ thống phân cấp Tài nguyên và Tính kế thừa (Inheritance)

Hiểu rõ hệ thống phân cấp và tính kế thừa là chìa khóa để quản lý IAM hiệu quả.

Các chính sách IAM được đính kèm vào một tài nguyên cụ thể (Organization, Folder, Project, hoặc tài nguyên con có hỗ trợ).
Tính kế thừa: Chính sách được thiết lập ở cấp độ cao hơn trong hệ thống phân cấp sẽ được kế thừa bởi các tài nguyên con bên dưới nó.
- Chính sách ở cấp Organization áp dụng cho tất cả Folders và Projects.
- Chính sách ở cấp Folder áp dụng cho Folder đó và tất cả Projects bên dưới.
- Chính sách ở cấp Project áp dụng cho tất cả các tài nguyên bên trong Project (VMs, Buckets, v.v.) trừ khi có chính sách cụ thể ở cấp tài nguyên đó.
Policy hiệu quả (Effective Policy): Tại bất kỳ tài nguyên cụ thể nào, policy hiệu quả là tổng hợp của:
- Chính sách được đính kèm trực tiếp vào tài nguyên đó.
- Chính sách được kế thừa từ tài nguyên cha (Project).
- Chính sách được kế thừa từ tài nguyên ông (Folder, nếu có).
- Chính sách được kế thừa từ tài nguyên cụ (Organization, nếu có).
Ví dụ về kế thừa:
- Bạn cấp vai trò roles/storage.objectViewer cho người dùng Alice ở cấp Project A. Alice có thể xem các object trong tất cả các buckets trong Project A.
- Bạn cấp vai trò roles/storage.admin cho nhóm Bob ở cấp độ một Folder chứa Project A. Bob có thể quản lý các bucket và object trong tất cả các projects trong Folder đó, bao gồm cả Project A.
- Policy hiệu quả cho Alice trên một bucket trong Project A sẽ bao gồm cả quyền xem object (từ vai trò được cấp ở cấp Project) và tất cả các quyền khác mà cô ấy có thể nhận được từ các chính sách ở cấp Folder hoặc Organization (nếu có). Policy hiệu quả cho Bob trên một bucket trong Project A sẽ bao gồm quyền quản lý storage (từ vai trò được cấp ở cấp Folder) và các quyền khác từ cấp cao hơn.

Lưu ý quan trọng: Các policy ở cấp thấp hơn không ghi đè lên các policy ở cấp cao hơn (trong mô hình Allow truyền thống). Chúng chỉ thêm vào tập hợp quyền hạn. Quyền hạn chỉ bị loại bỏ nếu binding cấp quyền đó bị xóa khỏi tất cả các policy có liên quan (trực tiếp hoặc kế thừa).

Việc hiểu cơ chế kế thừa này giúp bạn thiết kế cấu trúc IAM hiệu quả và tránh cấp quyền quá mức. Thường thì, bạn nên cố gắng cấp quyền ở cấp độ cao nhất có thể trong hệ thống phân cấp mà vẫn tuân thủ nguyên tắc "least privilege". Ví dụ, nếu một nhóm cần quyền xem tất cả các máy ảo trong tất cả các dự án trong một Folder, hãy cấp vai trò roles/compute.viewer ở cấp độ Folder thay vì cấp riêng lẻ cho từng Project. Tuy nhiên, nếu họ chỉ cần quyền trên một Project duy nhất, hãy cấp ở cấp Project.

Tuyệt vời, chúng ta tiếp tục hành trình khám phá chuyên sâu Google Cloud IAM. Ở phần trước, chúng ta đã nắm được các khái niệm cơ bản về IAM, các thành phần Who/What/Where và cách Policy hoạt động với tính kế thừa.

Giờ đây, chúng ta sẽ đi sâu hơn vào từng thành phần này, đặc biệt tập trung vào các khía cạnh quan trọng cho kỳ thi Associate Cloud Engineer.

Phần 2: Khám phá Chi tiết các Thành phần của IAM

2.1. Thành phần "Who" Chuyên Sâu: Tài khoản Dịch vụ (Service Accounts)

Như đã giới thiệu, Tài khoản Dịch vụ (Service Account - SA) là một danh tính đặc biệt. Nó không đại diện cho một người dùng cuối là con người, mà đại diện cho một ứng dụng, một máy ảo (VM), hoặc một dịch vụ khác cần thực hiện các hành động được ủy quyền trên tài nguyên Google Cloud của bạn.

Tại sao cần Tài khoản Dịch vụ?

An toàn hơn: Sử dụng Tài khoản Dịch vụ để ứng dụng truy cập tài nguyên an toàn hơn nhiều so với việc sử dụng tài khoản người dùng (vốn có thể bị lộ mật khẩu hoặc key). Tài khoản dịch vụ có cơ chế xác thực được thiết kế riêng cho máy móc/ứng dụng.
Quản lý dễ dàng hơn: Phân tách rõ ràng danh tính giữa người dùng và ứng dụng. Bạn có thể cấp quyền cụ thể cho từng ứng dụng hoặc dịch vụ thông qua Tài khoản Dịch vụ của nó.
Tuân thủ: Giúp theo dõi hành động nào được thực hiện bởi ứng dụng nào thông qua nhật ký kiểm tra (Audit Logs).

Cấu trúc và Định dạng của Tài khoản Dịch vụ:

Một Tài khoản Dịch vụ được định danh bằng một địa chỉ email. Định dạng thường là:

{tên-sa}@{project-id}.iam.gserviceaccount.com

Ví dụ: my-app-sa@my-project-123456.iam.gserviceaccount.com

Trong đó:

{tên-sa}: Tên bạn đặt cho tài khoản dịch vụ (do bạn tạo).
{project-id}: ID của project mà tài khoản dịch vụ này thuộc về.

Các Loại Tài khoản Dịch vụ:

Có ba loại chính mà bạn sẽ gặp trong Google Cloud:

Tài khoản Dịch vụ do Người dùng Quản lý (User-managed Service Accounts):
- Đây là loại mà bạn tạo ra và quản lý trực tiếp trong project của mình.
- Bạn có thể tạo bao nhiêu tùy thích (trong giới hạn quota).
- Bạn cấp vai trò (roles) cho tài khoản dịch vụ này để nó có quyền truy cập vào các tài nguyên khác (ví dụ: cấp vai trò roles/storage.objectCreator cho SA để nó ghi file vào Cloud Storage).
- Bạn có thể tạo khóa (keys) cho loại tài khoản dịch vụ này (Key JSON hoặc Key P12), hoặc sử dụng cơ chế xác thực không cần khóa.
- Đây là loại SA phổ biến nhất mà bạn sẽ làm việc cùng.
Tài khoản Dịch vụ do Google Quản lý (Google-managed Service Accounts):
- Đây là các tài khoản dịch vụ được Google tạo ra và quản lý cho các dịch vụ cụ thể của họ. Bạn không tạo ra chúng.
- Chúng thường có định dạng email khác, ví dụ: {số-project}@cloudservices.gserviceaccount.com (cho Google APIs Service Agent) hoặc {project-id}@containerregistry.iam.gserviceaccount.com (cho Container Registry).
- Google sử dụng các SA này để các dịch vụ nội bộ của họ có thể truy cập vào tài nguyên của bạn thay mặt cho bạn khi bạn sử dụng dịch vụ đó. Ví dụ, SA của Cloud Build cần quyền để ghi image vào Container Registry.
- Bạn không tạo khóa cho các SA do Google quản lý. Google quản lý việc xác thực nội bộ của chúng.
- Bạn có thể và cần phải cấp quyền cho các SA do Google quản lý để chúng có thể hoạt động đúng (ví dụ: cấp quyền cho SA của Dataflow để đọc từ Pub/Sub).
Tài khoản Dịch vụ Mặc định (Default Service Accounts):
- Đây là một trường hợp đặc biệt của Tài khoản Dịch vụ do Google Quản lý hoặc do Người dùng Quản lý tùy ngữ cảnh, nhưng chúng được tự động tạo ra khi bạn bật một số dịch vụ trong một project (đặc biệt là Compute Engine và App Engine).
- Tài khoản dịch vụ mặc định của Compute Engine: Khi bạn tạo project mới và lần đầu sử dụng Compute Engine, Google Cloud sẽ tự động tạo một tài khoản dịch vụ mặc định cho project đó.
  - Định dạng email: {project-number}-compute@developer.gserviceaccount.com
  - {project-number} là số project (khác với ID project).
  - Theo mặc định (trước đây), SA này thường được cấp vai trò Editor trên project. Vai trò này rất rộng và là một rủi ro bảo mật nếu bạn sử dụng SA mặc định này cho các VM trong production mà không giảm bớt quyền hạn của nó.
  - Thực hành Tốt & Cho kỳ thi: Không sử dụng Tài khoản Dịch vụ mặc định với vai trò Editor mặc định trong môi trường production. Hãy tạo tài khoản dịch vụ do người dùng quản lý với quyền hạn tối thiểu cần thiết (least privilege) và gán SA đó cho VM của bạn. Nếu buộc phải dùng SA mặc định (ví dụ: trong môi trường test/demo), hãy thay đổi vai trò của nó để tuân thủ nguyên tắc least privilege.

Xác thực và Ủy quyền cho Tài khoản Dịch vụ:

Đây là phần quan trọng để SA có thể thực hiện các hành động.

Cấp quyền CHO Tài khoản Dịch vụ:
- Bạn coi Tài khoản Dịch vụ như bất kỳ danh tính nào khác (người dùng, nhóm).
- Bạn thêm địa chỉ email của Tài khoản Dịch vụ vào một binding trong IAM Policy của tài nguyên mà SA cần truy cập.
- Bạn gán cho SA một hoặc nhiều vai trò (roles) chứa các quyền cần thiết.
- Ví dụ: Để một SA có thể đọc file từ một bucket Cloud Storage, bạn thêm SA đó vào policy của bucket hoặc project với vai trò roles/storage.objectViewer.
Cách Tài khoản Dịch vụ XÁC THỰC để nhận quyền:
- Sử dụng Khóa (Keys):
  - Bạn có thể tạo khóa JSON hoặc P12 cho Tài khoản Dịch vụ do người dùng quản lý.
  - Bạn tải file khóa này về và đưa nó vào ứng dụng hoặc trên VM.
  - Ứng dụng sử dụng khóa này để xác thực với Google Cloud API và chứng minh danh tính của nó là Tài khoản Dịch vụ đó.
  - Nguy cơ: Quản lý khóa rất rủi ro. Khóa có thể bị lộ, bị đánh cắp nếu không được bảo vệ cẩn thận. Việc xoay vòng (rotate) khóa cũng phức tạp.
  - Thực hành Tốt & Cho kỳ thi: Tránh sử dụng khóa SA, đặc biệt trên các tài nguyên Google Cloud như VM, Kubernetes Pods. Ưu tiên các cơ chế không cần khóa.
- Sử dụng Cơ chế Tích hợp (Recommended - Không cần Khóa):
  - Cho Compute Engine VMs: Khi tạo một VM, bạn có thể chỉ định một Tài khoản Dịch vụ sẽ được "đính kèm" (attached) vào VM đó. VM sẽ tự động có khả năng nhận dạng là SA đó mà không cần file khóa. VM sử dụng Google Cloud Metadata Server cục bộ để lấy thông tin về SA được đính kèm và tạo các token truy cập tạm thời an toàn.
    - Rất quan trọng cho kỳ thi: Hiểu cách gán SA cho VM và cách VM sử dụng metadata server (http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token hoặc đường dẫn cụ thể cho SA không mặc định) để xác thực.
    - Ngoài việc gán SA, bạn cần cấu hình API scopes cho VM. API scopes kiểm soát phạm vi quyền mà VM có thể truy cập các API của Google bằng cách sử dụng token của SA được đính kèm. Quyền hạn hiệu quả của VM sẽ là giao thoa (intersection) giữa vai trò IAM được cấp cho SA và các API scopes được cấu hình trên VM. Ví dụ: nếu SA có vai trò roles/storage.admin (có thể quản lý tất cả bucket) nhưng VM chỉ có API scope read-only cho Cloud Storage, thì VM chỉ có thể đọc object từ bucket, không thể tạo hay xóa. Nếu VM có scope full-control nhưng SA chỉ có vai trò roles/storage.objectViewer, VM chỉ có thể xem object. Vai trò IAM là cách được khuyến khích và chi tiết hơn để kiểm soát quyền; API scopes là một lớp kiểm soát bổ sung (thường được coi là cũ hơn và ít chi tiết hơn IAM Roles) khi sử dụng SA đính kèm trên VM. Đối với Associate, hiểu sự khác biệt và cách chúng kết hợp là quan trọng. Ưu tiên quản lý quyền bằng vai trò IAM được gán cho SA.
  - Cho Google Kubernetes Engine (GKE) Pods: Sử dụng Workload Identity. Đây là cơ chế hiện đại cho phép GKE Pods sử dụng một Tài khoản Dịch vụ Google Cloud cụ thể thay vì SA của VM Node. Nó liên kết Tài khoản Dịch vụ Kubernetes với Tài khoản Dịch vụ Google Cloud. Pods chạy dưới SA Kubernetes đó sẽ tự động xác thực như SA Google Cloud được liên kết mà không cần file khóa. Workload Identity là cơ chế được khuyến nghị cho GKE.
  - Cho Cloud Functions, Cloud Run, App Engine Flex: Bạn có thể chỉ định Tài khoản Dịch vụ mà dịch vụ này sẽ chạy dưới danh tính đó. Tương tự như VM, dịch vụ sẽ tự động xác thực mà không cần quản lý khóa.
  - Cho các môi trường khác (on-premises, AWS/Azure): Sử dụng Workload Identity Federation (cho phép danh tính từ IdP bên ngoài xác thực như một SA Google Cloud mà không cần khóa) hoặc Service Account Impersonation (ủy quyền tạm thời).
Ủy quyền SỬ DỤNG Tài khoản Dịch vụ (iam.serviceAccountUser role):
- Điều này khác với việc cấp quyền CHO SA. Role iam.serviceAccountUser cho phép một danh tính (người dùng, nhóm, SA khác) hành động như (impersonate) một Tài khoản Dịch vụ cụ thể.
- Khi một người dùng có vai trò iam.serviceAccountUser trên SA "SA-X", người dùng đó có thể tạm thời nhận tất cả các quyền mà SA-X có. Điều này hữu ích trong các trường hợp:
  - Cho phép người dùng chạy script hoặc ứng dụng với quyền của SA (thay vì quyền của chính họ).
  - Cho phép một SA (ví dụ: SA của một CI/CD pipeline) sử dụng quyền của một SA khác (ví dụ: SA deployment) để triển khai ứng dụng.
- Rất quan trọng cho kỳ thi: Nắm vững sự khác biệt giữa cấp quyền cho SA và cấp quyền iam.serviceAccountUser trên SA. Quyền trên SA cho phép sử dụng SA đó để thực hiện hành động với quyền của SA.

Quản lý Tài khoản Dịch vụ:

Tạo Tài khoản Dịch vụ: Thông qua Google Cloud Console (IAM & Admin -> Service Accounts), gcloud CLI (gcloud iam service-accounts create), hoặc API/Terraform.
Quản lý Khóa: Tạo, liệt kê, xóa khóa (chỉ cho SA do người dùng quản lý). Nên xoay vòng khóa định kỳ nếu bạn buộc phải sử dụng chúng. Sử dụng IAM Recommendations để phát hiện khóa đã lâu không sử dụng.
Gán Vai trò cho SA: Giống như gán vai trò cho người dùng/nhóm, thông qua policy của tài nguyên hoặc thông qua trang IAM & Admin.
Gán Quyền iam.serviceAccountUser trên SA: Cấp vai trò roles/iam.serviceAccountUser cho danh tính muốn sử dụng SA, đính kèm policy này vào chính Tài khoản Dịch vụ đó.
Xóa Tài khoản Dịch vụ: Xóa SA khi không còn cần thiết. Hãy cẩn thận vì việc này là vĩnh viễn.
Kiểm tra Quyền hiệu quả của SA: Sử dụng công cụ Policy Troubleshooter hoặc xem các policy được áp dụng cho SA và các tài nguyên mà SA cần truy cập.

Thực hành Tốt với Tài khoản Dịch vụ (Quan trọng cho thi & thực tế):

Nguyên tắc Least Privilege: Luôn cấp cho Tài khoản Dịch vụ quyền hạn tối thiểu cần thiết để thực hiện công việc của nó. Tránh cấp vai trò Editor hoặc Owner cho SA trừ khi thực sự cần thiết và chỉ trong môi trường non-production.
Tạo SA chuyên dụng: Tạo các Tài khoản Dịch vụ riêng biệt cho từng ứng dụng hoặc workload khác nhau. Điều này giúp giới hạn phạm vi rủi ro nếu một SA bị lộ và giúp quản lý quyền chi tiết hơn.
Tránh sử dụng Khóa: Ưu tiên các cơ chế không cần khóa như đính kèm SA vào VM, Workload Identity cho GKE, hoặc các tính năng tích hợp của Cloud Functions/Run/App Engine. Nếu buộc phải dùng khóa, hãy quản lý chúng cực kỳ cẩn thận (ví dụ: dùng Secret Manager) và xoay vòng thường xuyên.
Cẩn trọng với SA mặc định: Không dùng SA mặc định của Compute Engine/App Engine trong môi trường production với quyền mặc định (Editor). Hoặc tạo SA mới với quyền hạn hạn chế, hoặc thay đổi quyền của SA mặc định.
Kiểm tra định kỳ: Kiểm tra lại các SA và quyền hạn của chúng để đảm bảo chúng vẫn tuân thủ nguyên tắc least privilege.

2.2. Phân tích Chi tiết về Vai trò (Roles)

Chúng ta đã phân loại Vai trò thành Cơ bản, Định sẵn và Tùy chỉnh. Giờ hãy xem xét kỹ hơn.

2.2.1. Vai trò Cơ bản (Primitive Roles)

Owner (roles/owner): Có quyền quản lý tất cả tài nguyên trong project (bao gồm cả quản lý quyền IAM và quản lý thanh toán - Billing). Rất mạnh. Chỉ nên gán cho một số lượng rất ít người dùng/nhóm, thường là quản trị viên cấp cao.
Editor (roles/editor): Có quyền tạo và chỉnh sửa hầu hết các tài nguyên trong project. Không có quyền quản lý quyền IAM hoặc quản lý Billing (mặc dù có thể bật/tắt API, điều này có thể ảnh hưởng đến tài nguyên). Vẫn là một vai trò khá rộng.
Viewer (roles/viewer): Chỉ có quyền xem thông tin về tài nguyên trong project. Không thể tạo, chỉnh sửa hoặc xóa bất cứ thứ gì.
Billing Account User (roles/billing.user): Cho phép liên kết project với một tài khoản thanh toán (Billing Account). Cần thiết nếu bạn muốn người dùng hoặc SA tạo project mới và liên kết chúng với billing.

Lưu ý: Vai trò cơ bản được áp dụng ở cấp Project hoặc Tổ chức/Thư mục. Quyền hạn của chúng rất rộng, bao gồm nhiều dịch vụ.

Tại sao Tránh Vai trò Cơ bản trong Production?

Việc gán vai trò Editor cho một Tài khoản Dịch vụ hoặc người dùng thông thường trong môi trường production là một lỗ hổng bảo mật nghiêm trọng. Một SA bị lộ key, hoặc tài khoản người dùng bị compromised, có thể gây ra thiệt hại lớn (xóa dữ liệu, tạo tài nguyên tốn kém, v.v.) trên toàn bộ project hoặc thậm chí Organization nếu vai trò được cấp ở cấp cao hơn. Luôn luôn ưu tiên Vai trò Định sẵn hoặc Tùy chỉnh.

2.2.2. Vai trò Định sẵn (Predefined Roles)

Đây là các vai trò được Google thiết kế để cung cấp quyền hạn chi tiết hơn, tập trung vào các dịch vụ cụ thể hoặc các nhóm chức năng logic.

Cấu trúc Tên: roles/{service}.{role_description} (ví dụ: roles/compute.instanceAdmin.v1, roles/storage.objectViewer).
Phạm vi Quyền: Mỗi vai trò định sẵn chứa một tập hợp các quyền ({service}.{resource}.{verb}) liên quan đến dịch vụ hoặc chức năng mà nó đại diện.
Ví dụ về các Vai trò Định sẵn Phổ biến (Cần biết cho Associate):
- Compute Engine:
  - roles/compute.instanceAdmin.v1: Quản lý VM instances (tạo, xóa, stop, start, reset, v.v.).
  - roles/compute.networkAdmin: Quản lý mạng VPC, firewall rules, routes, v.v.
  - roles/compute.securityAdmin: Quản lý firewall rules và SSL certificates.
  - roles/compute.viewer: Xem thông tin về các tài nguyên Compute Engine.
  - roles/compute.serviceAgent: Tài khoản dịch vụ do Google quản lý cho Compute Engine.
- Cloud Storage:
  - roles/storage.admin: Quản lý các bucket và object.
  - roles/storage.objectAdmin: Quản lý các object trong bucket (nhưng không quản lý bucket itself, trừ khi có quyền storage.buckets.create).
  - roles/storage.objectCreator: Chỉ tạo object mới trong bucket.
  - roles/storage.objectViewer: Chỉ xem (đọc) object trong bucket.
- Cloud SQL:
  - roles/cloudsql.admin: Quản lý các instance Cloud SQL.
  - roles/cloudsql.client: Kết nối đến các instance Cloud SQL (cần thêm quyền IAM trên database).
- Pub/Sub:
  - roles/pubsub.editor: Quản lý topics và subscriptions.
  - roles/pubsub.viewer: Xem topics và subscriptions.
  - roles/pubsub.publisher: Chỉ gửi tin nhắn đến topics.
  - roles/pubsub.subscriber: Chỉ nhận tin nhắn từ subscriptions.
- BigQuery:
  - roles/bigquery.admin: Toàn quyền quản lý các tài nguyên BigQuery.
  - roles/bigquery.dataEditor: Đọc/ghi dữ liệu trong các bảng.
  - roles/bigquery.dataViewer: Chỉ đọc dữ liệu trong các bảng.
  - roles/bigquery.jobUser: Chạy các job BigQuery (query, load, export).
- Networking:
  - roles/networkAdmin: Quản lý mạng và cấu hình liên quan.
  - roles/networkViewer: Chỉ xem cấu hình mạng.
- IAM (Identity and Access Management):
  - roles/iam.serviceAccountAdmin: Quản lý Tài khoản Dịch vụ.
  - roles/iam.serviceAccountUser: Cho phép sử dụng (impersonate) Tài khoản Dịch vụ.
  - roles/iam.roleAdmin: Quản lý (tạo, xóa, cập nhật) Vai trò Tùy chỉnh.
  - roles/resourcemanager.projectIamAdmin: Quản lý IAM policies ở cấp Project.
  - roles/orgpolicy.policyAdmin: Quản lý Organization Policies.
- Logging & Monitoring:
  - roles/logging.viewer: Chỉ xem logs.
  - roles/monitoring.viewer: Chỉ xem dữ liệu monitoring.
  - roles/logging.logWriter: Ghi logs (thường được dùng bởi các SA của ứng dụng).
  - roles/monitoring.metricWriter: Ghi metrics (thường được dùng bởi các SA của ứng dụng).
Cách Tìm Quyền trong Vai trò:
- Google Cloud Documentation: Tra cứu danh sách các vai trò định sẵn và các quyền tương ứng của chúng. Đây là nguồn chính xác nhất.
- gcloud: Sử dụng lệnh gcloud iam roles describe [ROLE_NAME] để xem chi tiết các quyền trong một vai trò (ví dụ: gcloud iam roles describe roles/compute.instanceAdmin.v1).

2.2.3. Vai trò Tùy chỉnh (Custom Roles)

Nếu không có vai trò định sẵn nào đáp ứng chính xác nhu cầu của bạn (ví dụ: bạn cần một vai trò chỉ cho phép tạo VM nhưng không được xóa, hoặc chỉ cho phép truy cập vào một loại tài nguyên rất cụ thể), bạn có thể tạo Vai trò Tùy chỉnh.

Cách Hoạt động: Bạn chọn một tập hợp các quyền cụ thể từ danh sách các quyền có sẵn trong Google Cloud và nhóm chúng lại dưới một tên vai trò mới.
Phạm vi: Vai trò tùy chỉnh có thể được tạo ở cấp độ Project hoặc Organization.
- Vai trò tùy chỉnh cấp Project chỉ có thể được sử dụng trong project đó.
- Vai trò tùy chỉnh cấp Organization có thể được sử dụng trong toàn bộ Organization (trên tất cả các Folder và Project con).
Ưu điểm: Cho phép kiểm soát quyền rất chi tiết, giúp áp dụng chặt chẽ nguyên tắc "least privilege".
Nhược điểm: Việc quản lý có thể phức tạp hơn vì bạn phải tự định nghĩa và duy trì các tập hợp quyền này.
Tạo Vai trò Tùy chỉnh:
- Google Cloud Console: IAM & Admin -> Roles -> Create Role. Bạn cung cấp tên, ID, mô tả, và chọn các quyền muốn thêm.
- gcloud: Sử dụng lệnh gcloud iam roles create [ROLE_ID] --project [PROJECT_ID] --permissions [PERMISSIONS_LIST] (hoặc --organization [ORG_ID]).
Lưu ý khi tạo:
- Đảm bảo bạn chỉ thêm các quyền thực sự cần thiết.
- Kiểm tra lại các quyền sau khi tạo để tránh sai sót.
- Tên ID của vai trò tùy chỉnh phải duy nhất trong phạm vi Project/Organization của nó.

Thực hành Tốt với Vai trò:

Ưu tiên Vai trò Định sẵn: Bắt đầu bằng cách tìm kiếm vai trò định sẵn phù hợp nhất. Chỉ tạo Vai trò Tùy chỉnh khi không có vai trò định sẵn nào đáp ứng yêu cầu và bạn thực sự cần quyền hạn rất cụ thể.
Tuân thủ Least Privilege: Luôn chọn vai trò cấp ít quyền nhất mà vẫn cho phép danh tính thực hiện công việc cần thiết.
Hiểu Rõ Quyền trong Vai trò: Luôn kiểm tra tài liệu hoặc sử dụng lệnh gcloud để biết chính xác vai trò chứa những quyền gì trước khi cấp nó. Đừng đoán mò dựa trên tên vai trò.
Sử dụng Nhóm: Cấp vai trò cho Nhóm Google thay vì từng người dùng riêng lẻ để đơn giản hóa việc quản lý khi nhân sự thay đổi.
Xem xét Phạm vi: Quyết định cấp vai trò ở cấp độ nào trong hệ thống phân cấp (Organization, Folder, Project, Resource) dựa trên phạm vi tài nguyên mà danh tính cần truy cập.

2.3. Chính sách Ràng buộc có Điều kiện (IAM Conditions)

Đây là một tính năng nâng cao hơn của IAM, cho phép bạn chỉ định các điều kiện để một ràng buộc chính sách (policy binding) được áp dụng. Nói cách khác, bạn có thể cấp một vai trò cho một danh tính, nhưng chỉ khi điều kiện cụ thể được đáp ứng.

Mục đích: Cung cấp khả năng kiểm soát truy cập chi tiết hơn nữa dựa trên các thuộc tính của yêu cầu (request) hoặc tài nguyên (resource).
Cách Hoạt động: IAM Conditions sử dụng Common Expression Language (CEL) để định nghĩa các biểu thức logic. Biểu thức này được đánh giá tại thời điểm yêu cầu truy cập được thực hiện. Nếu biểu thức trả về true, ràng buộc chính sách sẽ có hiệu lực. Nếu trả về false, ràng buộc đó bị bỏ qua.
Các thuộc tính có thể dùng trong điều kiện:
- Thời gian (Time): Giới hạn truy cập trong khoảng thời gian cụ thể, ngày trong tuần, giờ trong ngày.
- Loại Tài nguyên (Resource type): Áp dụng vai trò chỉ cho các tài nguyên có loại cụ thể (ví dụ: chỉ cho phép quản lý VM, không cho phép quản lý Load Balancer, mặc dù vai trò compute.instanceAdmin có thể chứa quyền trên cả hai).
- Tên Tài nguyên (Resource name): Áp dụng vai trò chỉ cho các tài nguyên có tên khớp với mẫu cụ thể (ví dụ: chỉ cho phép truy cập vào bucket có tên bắt đầu bằng "internal-").
- Thuộc tính Tài nguyên (Resource attributes): Dựa trên các thuộc tính của tài nguyên, ví dụ: label của VM, loại Instance Cloud SQL, v.v.

Ví dụ về Binding với Condition (JSON format):

json

{
  "role": "roles/storage.objectViewer",
  "members": [
    "group:data-analysts@company.com"
  ],
  "condition": {
    "title": "Expires after 2024-12-31",
    "description": "Grant object viewer role only until end of 2024",
    "expression": "request.time < timestamp('2025-01-01T00:00:00Z')"
  }
}

Binding này cấp vai trò roles/storage.objectViewer cho nhóm data-analysts@company.com, nhưng chỉ cho đến hết ngày 31 tháng 12 năm 2024. Sau thời điểm đó, binding này sẽ không còn hiệu lực.

json

{
  "role": "roles/compute.instanceAdmin.v1",
  "members": [
    "user:vm-tester@company.com"
  ],
  "condition": {
    "title": "Allow access only to test VMs",
    "description": "Grant instance admin role only for VMs with label 'env: test'",
    "expression": "resource.type == 'compute.googleapis.com/Instance' && resource.labels.env == 'test'"
  }
}

Binding này cấp vai trò roles/compute.instanceAdmin.v1 cho người dùng vm-tester@company.com, nhưng chỉ áp dụng cho các tài nguyên có loại compute.googleapis.com/Instance (tức là VM) và VM đó có label env với giá trị test. Người dùng này sẽ không thể quản lý các VM không có label này hoặc có label khác.

Độ phủ: IAM Conditions không hỗ trợ cho tất cả các dịch vụ hoặc các loại tài nguyên của Google Cloud. Bạn cần kiểm tra tài liệu để biết dịch vụ nào hỗ trợ.
Relevance cho Associate Exam: Bạn cần biết rằng IAM Conditions tồn tại, hiểu mục đích chính của chúng (thêm lớp kiểm soát dựa trên điều kiện), và nhận ra các ví dụ đơn giản về cách chúng có thể được sử dụng (ví dụ: giới hạn theo thời gian hoặc loại tài nguyên/label). Bạn không cần phải là chuyên gia viết biểu thức CEL phức tạp.

Tóm lại Phần 2:

Tài khoản Dịch vụ: Danh tính cho ứng dụng/máy. Quan trọng là phân biệt loại SA (user-managed, Google-managed, default), hiểu cách xác thực (khóa vs không khóa - ưu tiên không khóa), cách gán quyền cho SA và quyền iam.serviceAccountUser trên SA. Luôn tuân thủ least privilege và tránh khóa SA trong production.
Vai trò: Tập hợp các quyền. Primitive (rộng, tránh dùng production), Predefined (chi tiết hơn, khuyến nghị), Custom (tùy chỉnh hoàn toàn). Hiểu cách tên vai trò được cấu trúc và tìm quyền trong vai trò.
Permissions: Các quyền cụ thể ({service}.{resource}.{verb}). Các khối xây dựng của vai trò.
IAM Conditions: Lớp kiểm soát bổ sung cho phép áp dụng policy binding dựa trên các điều kiện về thời gian, tài nguyên, v.v. Hữu ích cho việc giới hạn quyền chặt chẽ hơn.

Tuyệt vời! Dưới đây là mục lục chi tiết cho toàn bộ phân tích chuyên sâu về Google Cloud IAM và chỉ rõ chúng ta đã hoàn thành những phần nào. Sau đó, tôi sẽ tiếp tục với phần tiếp theo.

Phần 3: Quản lý IAM Policies và Thực Hành

Sau khi đã hiểu các thành phần cấu tạo nên IAM Policy (Ai, Vai trò, Tài nguyên) và cách chúng hoạt động (kế thừa, additive), bước tiếp theo là học cách tương tác với các policy này: xem chúng, thêm ràng buộc (cấp quyền) và xóa ràng buộc (thu hồi quyền).

Google Cloud cung cấp nhiều cách để quản lý IAM Policies:

Google Cloud Console (GCP Console): Giao diện web trực quan, phù hợp cho các thao tác thủ công hoặc kiểm tra.
gcloud Command-Line Tool: Công cụ dòng lệnh mạnh mẽ, phù hợp cho script, tự động hóa, hoặc thực hiện nhanh các tác vụ.
Client Libraries / APIs: Để tích hợp quản lý IAM vào ứng dụng hoặc dịch vụ của bạn.
Infrastructure as Code (IaC) Tools: Như Terraform, Deployment Manager, để định nghĩa và quản lý IAM Policies như một phần của hạ tầng.

Trong phần này, chúng ta sẽ tập trung vào Cloud Console và gcloud, là hai công cụ chính bạn sẽ sử dụng và được đề cập nhiều trong kỳ thi Associate.

3.1. Xem Chính sách IAM Hiện tại

Trước khi thay đổi policy, việc quan trọng là phải xem policy hiện tại trông như thế nào.

Sử dụng Google Cloud Console:

Điều hướng đến tài nguyên mà bạn muốn xem policy của nó. Thường bạn sẽ làm việc ở cấp Project:
- Đi đến trang tổng quan Project (Dashboard).
- Chọn Project mà bạn quan tâm (nếu chưa chọn).
- Mở Navigation menu (biểu tượng ba gạch ngang ở góc trên bên trái).
- Tìm và chọn "IAM & Admin".
- Chọn "IAM".
Trang "IAM" hiển thị danh sách các ràng buộc (bindings) của policy được áp dụng ở cấp độ Project hiện tại. Bạn sẽ thấy:
- Members (Danh tính): Liệt kê các người dùng, nhóm, tài khoản dịch vụ, v.v.
- Role (Vai trò): Vai trò được gán cho các danh tính đó.
- Inherited from (Kế thừa từ): Cột này cho biết ràng buộc này được định nghĩa ở cấp độ nào (ví dụ: "This project", hoặc tên của Folder/Organization cha). Điều này giúp bạn hiểu chính sách hiệu quả (effective policy).
Để xem policy của tài nguyên cụ thể (ví dụ: một bucket Cloud Storage):
- Đi đến trang quản lý tài nguyên đó (ví dụ: Cloud Storage -> Buckets).
- Chọn bucket cụ thể.
- Tìm tab hoặc mục liên quan đến Permissions hoặc Access Control.
- Tại đây, bạn sẽ thấy policy được áp dụng trực tiếp lên bucket đó. Lưu ý rằng policy hiệu quả cho bucket này sẽ là sự tổng hợp của policy trực tiếp này và các policy được kế thừa từ Project, Folder, Organization.

Sử dụng gcloud Command-Line Tool:

Bạn sử dụng lệnh gcloud get-iam-policy. Lệnh này yêu cầu bạn chỉ định loại tài nguyên và tên/ID của tài nguyên đó.

Xem policy của Project:
bash
```
gcloud projects get-iam-policy [PROJECT_ID] --format=json
```
Thay [PROJECT_ID] bằng ID của project của bạn. Thêm --format=json để xem policy dưới dạng JSON, rất hữu ích để hiểu cấu trúc.

Xem policy của Folder:

bash

gcloud resource-manager folders get-iam-policy [FOLDER_ID] --format=json

Thay [FOLDER_ID] bằng ID của folder.

Xem policy của Organization:
bash
```
gcloud organizations get-iam-policy [ORGANIZATION_ID] --format=json
```
Thay [ORGANIZATION_ID] bằng ID của organization.
Xem policy của tài nguyên cụ thể (Ví dụ: Cloud Storage Bucket):
bash
```
gcloud storage buckets get-iam-policy gs://[BUCKET_NAME] --format=json
```
Thay [BUCKET_NAME] bằng tên bucket của bạn. Cú pháp cho tài nguyên cụ thể có thể khác nhau tùy dịch vụ, bạn cần kiểm tra tài liệu gcloud cho dịch vụ đó (ví dụ: gcloud compute instances get-iam-policy [INSTANCE_NAME] --zone [ZONE]).

Output của lệnh get-iam-policy sẽ hiển thị cấu trúc JSON của policy, bao gồm các bindings (mỗi binding chứa role và danh sách members, có thể có condition), etag (một mã phiên bản để tránh xung đột khi cập nhật) và version.

3.2. Cấp (Thêm) Quyền - Thêm Bindings vào Policy

Cấp quyền cho một danh tính trên một tài nguyên có nghĩa là thêm một ràng buộc (binding) mới vào IAM Policy của tài nguyên đó. Binding này sẽ liên kết danh tính (hoặc danh sách danh tính) với vai trò mong muốn.

Sử dụng Google Cloud Console:

Điều hướng đến trang IAM & Admin -> IAM của tài nguyên (Project, Folder, Organization).
Nhấp vào nút "GRANT ACCESS" (hoặc tương tự tùy phiên bản giao diện).
Một cửa sổ hoặc panel sẽ hiện ra cho phép bạn thêm binding mới.
Trong trường "New principals" (hoặc "Add members"), nhập địa chỉ email của danh tính (người dùng, nhóm, tài khoản dịch vụ). Bạn có thể thêm nhiều danh tính cùng lúc.
Trong trường "Select a role", chọn vai trò bạn muốn gán. Bạn có thể tìm kiếm theo tên vai trò (ví dụ: "Storage Object Viewer") hoặc theo dịch vụ. Console sẽ hiển thị các vai trò phổ biến và cho phép tìm kiếm vai trò khác.
(Tùy chọn) Nhấp vào "Add condition" để thêm điều kiện IAM cho binding này.
Nhấp "SAVE".

Console sẽ cập nhật policy và hiển thị binding mới trong danh sách.

Sử dụng gcloud Command-Line Tool:

Bạn có thể thêm binding bằng hai cách chính:

Cách 1: Sử dụng add-iam-policy-binding (được khuyến nghị cho thao tác đơn giản): Lệnh này cho phép thêm một binding mới vào policy hiện tại mà không cần lấy toàn bộ policy xuống, chỉnh sửa rồi đẩy lên lại.
- Cấp quyền cho Project:
  bash
```
gcloud projects add-iam-policy-binding [PROJECT_ID] \
    --member='user:alice@example.com' \
    --role='roles/compute.instanceAdmin.v1' \
    --condition='expression=request.time < timestamp("2025-01-01T00:00:00Z"),title=expires_end_2024,description=Temporary access'
```
  - --member: Chỉ định danh tính. Định dạng: user:, group:, serviceAccount:, domain:, allAuthenticatedUsers, allUsers.
  - --role: Chỉ định tên vai trò.
  - --condition: (Tùy chọn) Thêm điều kiện. Cần cung cấp biểu thức CEL, title và description.
- Cấp quyền cho Folder:
  bash
```
gcloud resource-manager folders add-iam-policy-binding [FOLDER_ID] \
    --member='serviceAccount:my-sa@my-project.iam.gserviceaccount.com' \
    --role='roles/pubsub.publisher'
```
- Cấp quyền cho Organization:
  bash
```
gcloud organizations add-iam-policy-binding [ORGANIZATION_ID] \
    --member='group:auditors@company.com' \
    --role='roles/logging.viewer'
```
- Cấp quyền cho tài nguyên cụ thể (Ví dụ: Cloud Storage Bucket):
  bash
```
gcloud storage buckets add-iam-policy-binding gs://[BUCKET_NAME] \
    --member='allUsers' \
    --role='roles/storage.objectViewer'
```
  Lệnh này làm cho tất cả các object trong bucket có thể đọc được công khai. Cẩn trọng khi sử dụng allUsers!
Cách 2: Sử dụng set-iam-policy (cho thao tác phức tạp hoặc cập nhật nhiều binding): Lệnh này yêu cầu bạn lấy toàn bộ policy hiện tại, chỉnh sửa file JSON/YAML đó, rồi đẩy (set) policy đã chỉnh sửa lên.
1. Lấy policy hiện tại và lưu vào file:
  bash
```
gcloud projects get-iam-policy [PROJECT_ID] --format=json > policy.json
```
2. Mở file policy.json trong trình soạn thảo và chỉnh sửa cấu trúc JSON: thêm, xóa, hoặc sửa đổi các mục trong mảng bindings. Đảm bảo giữ nguyên etag để tránh ghi đè lên các thay đổi đồng thời khác (hoặc xóa etag nếu bạn biết mình đang làm việc độc lập).
3. Đặt policy đã chỉnh sửa:
  bash
```
gcloud projects set-iam-policy [PROJECT_ID] policy.json
```
Cách này mạnh mẽ hơn nhưng cũng rủi ro hơn nếu bạn chỉnh sửa file sai hoặc không quản lý etag đúng cách.

3.3. Thu Hồi (Xóa) Quyền - Xóa Bindings khỏi Policy

Thu hồi quyền có nghĩa là xóa một ràng buộc (binding) cụ thể khỏi IAM Policy của tài nguyên.

Sử dụng Google Cloud Console:

Điều hướng đến trang IAM & Admin -> IAM của tài nguyên (Project, Folder, Organization).
Tìm ràng buộc mà bạn muốn xóa (binding chứa danh tính và vai trò cụ thể).
Chọn hộp kiểm bên cạnh ràng buộc đó.
Nhấp vào nút "DELETE" (hoặc biểu tượng thùng rác).
Xác nhận hành động.

Ràng buộc sẽ bị xóa khỏi policy. Lưu ý rằng danh tính đó vẫn có thể có quyền thông qua các ràng buộc khác hoặc thông qua kế thừa từ tài nguyên cha.

Sử dụng gcloud Command-Line Tool:

Tương tự như thêm binding, bạn có thể sử dụng hai cách:

Cách 1: Sử dụng remove-iam-policy-binding (được khuyến nghị cho thao tác đơn giản): Lệnh này xóa một binding cụ thể dựa trên danh tính và vai trò.
- Thu hồi quyền cho Project:
  bash
```
gcloud projects remove-iam-policy-binding [PROJECT_ID] \
    --member='user:alice@example.com' \
    --role='roles/compute.instanceAdmin.v1'
```
  Lệnh này xóa binding gán vai trò roles/compute.instanceAdmin.v1 cho user:alice@example.com trên project này.
- Thu hồi quyền với Condition: Nếu binding có condition, bạn cần chỉ định cả condition khi xóa:
  bash
```
gcloud projects remove-iam-policy-binding [PROJECT_ID] \
    --member='user:alice@example.com' \
    --role='roles/compute.instanceAdmin.v1' \
    --condition='expression=request.time < timestamp("2025-01-01T00:00:00Z"),title=expires_end_2024,description=Temporary access'
```
- Thu hồi quyền cho tài nguyên cụ thể (Ví dụ: Cloud Storage Bucket):
  bash
```
gcloud storage buckets remove-iam-policy-binding gs://[BUCKET_NAME] \
    --member='allUsers' \
    --role='roles/storage.objectViewer'
```
  Lệnh này loại bỏ quyền truy cập công cộng read-only vào bucket đó.
Cách 2: Sử dụng set-iam-policy (cho thao tác phức tạp hoặc cập nhật nhiều binding): Lấy policy hiện tại, chỉnh sửa file JSON/YAML để xóa binding mong muốn, rồi đẩy policy đã chỉnh sửa lên.
1. Lấy policy hiện tại:
  bash
```
gcloud projects get-iam-policy [PROJECT_ID] --format=json > policy.json
```
2. Mở policy.json và xóa hoàn toàn (hoặc comment out) mục binding tương ứng khỏi mảng bindings. Cẩn thận với dấu phẩy trong JSON.
3. Đặt policy đã chỉnh sửa:
  bash
```
gcloud projects set-iam-policy [PROJECT_ID] policy.json
```

3.4. Sử dụng Google Cloud Console để Quản lý IAM

Console là giao diện phổ biến nhất cho người mới bắt đầu và các thao tác thủ công.

Truy cập: Đi đến "IAM & Admin" trong menu điều hướng.
Xem: Trang IAM hiển thị danh sách các danh tính và vai trò của họ ở cấp độ hiện tại. Cột "Inherited from" giúp bạn thấy các quyền đến từ đâu.
Cấp quyền: Nút "GRANT ACCESS". Chọn danh tính, chọn vai trò, thêm điều kiện (nếu cần).
Thu hồi quyền: Chọn binding, nhấp "DELETE".
Xem Vai trò: Chuyển sang tab "Roles" để xem danh sách các vai trò (cơ bản, định sẵn, tùy chỉnh) có sẵn trong project/organization, kèm theo mô tả và số lượng quyền.
Xem Tài khoản Dịch vụ: Chuyển sang tab "Service Accounts" để quản lý các tài khoản dịch vụ trong project. Tại đây bạn có thể tạo SA, quản lý khóa, và xem SA nào được cấp quyền gì (nhấp vào SA để xem chi tiết và tab Permissions).

3.5. Sử dụng `gcloud` Command-Line Tool để Quản lý IAM

gcloud rất mạnh mẽ và hiệu quả cho các tác vụ lặp đi lặp lại hoặc script.

Cú pháp cơ bản:
- gcloud projects ... cho các lệnh liên quan đến project.
- gcloud resource-manager folders ... cho folders.
- gcloud organizations ... cho organizations.
- gcloud iam ... cho các lệnh quản lý vai trò tùy chỉnh, tài khoản dịch vụ.
- gcloud [service] [resource] ... cho các lệnh IAM trên tài nguyên cụ thể (ví dụ: gcloud storage buckets ..., gcloud compute instances ...).
Các lệnh chính (đã đề cập):
- get-iam-policy: Xem policy.
- add-iam-policy-binding: Thêm binding.
- remove-iam-policy-binding: Xóa binding.
- set-iam-policy: Đặt toàn bộ policy từ file.
Lệnh quản lý Tài khoản Dịch vụ (gcloud iam service-accounts ...):
- create: Tạo SA mới.
- list: Liệt kê các SA trong project.
- describe: Xem chi tiết SA.
- delete: Xóa SA.
- keys create: Tạo khóa cho SA (nên tránh).
- keys list: Liệt kê khóa của SA.
- keys delete: Xóa khóa của SA.
- add-iam-policy-binding / remove-iam-policy-binding: Để cấp quyền trên Tài khoản Dịch vụ đó (ví dụ: gán vai trò iam.serviceAccountUser).
Lệnh quản lý Vai trò Tùy chỉnh (gcloud iam roles ...):
- create: Tạo vai trò tùy chỉnh.
- list: Liệt kê các vai trò định sẵn và tùy chỉnh.
- describe: Xem chi tiết quyền trong một vai trò.
- update: Cập nhật vai trò tùy chỉnh.
- delete: Xóa vai trò tùy chỉnh.

Lưu ý khi sử dụng gcloud:

Luôn chỉ định đúng --project, --folder, hoặc --organization nếu bạn đang làm việc ở các cấp độ đó.
Sử dụng --format=json hoặc --format=yaml để xem output dưới dạng cấu trúc giúp dễ dàng xử lý bằng script.
Cẩn thận với --all khi liệt kê vai trò hoặc SA.

3.6. Sử dụng API và Infrastructure as Code (Terraform, Deployment Manager)

Đối với môi trường production và quản lý hạ tầng theo phương pháp IaC, việc quản lý IAM Policy bằng API hoặc các công cụ như Terraform là cách tiếp cận tốt nhất.

IAM API: Google Cloud cung cấp API cho phép bạn thực hiện tất cả các thao tác quản lý policy và vai trò theo chương trình. Các client libraries có sẵn cho nhiều ngôn ngữ lập trình.

Terraform: Provider của Google Cloud cho phép bạn định nghĩa IAM Policy bindings, custom roles, và service accounts trong các file cấu hình (.tf). Terraform quản lý trạng thái của hạ tầng, bao gồm cả IAM policies, giúp bạn đảm bảo cấu hình nhất quán và có thể lặp lại. Đây là cách rất được khuyến khích trong thực tế cho môi trường production và là một chủ đề phụ liên quan đến IaC có thể xuất hiện trong kỳ thi.

Ví dụ cấu hình Terraform cho IAM Binding:

terraform

resource "google_project_iam_member" "storage_viewer" {
  project = "my-project-id"
  role    = "roles/storage.objectViewer"
  member  = "group:analysts@company.com"
}

resource "google_service_account" "app_sa" {
  project      = "my-project-id"
  account_id   = "my-app-sa"
  display_name = "Service Account for My App"
}

resource "google_compute_instance_iam_member" "vm_admin" {
  project  = "my-project-id"
  zone     = "us-central1-a"
  instance = "my-vm-instance"
  role     = "roles/compute.instanceAdmin.v1"
  member   = "serviceAccount:${google_service_account.app_sa.email}"
}

Deployment Manager: Công cụ IaC tích hợp của Google Cloud cũng hỗ trợ quản lý IAM resources.

Relevance cho Associate Exam: Mặc dù kỳ thi chủ yếu tập trung vào Console và gcloud, việc hiểu rằng IAM có thể được quản lý bằng API và IaC (đặc biệt là Terraform) là quan trọng. Bạn có thể gặp câu hỏi về việc sử dụng công cụ nào để tự động hóa việc quản lý quyền.

Tuyệt vời, chúng ta tiếp tục hành trình khám phá Google Cloud IAM. Sau khi nắm vững các khái niệm cơ bản, thành phần chi tiết và cách quản lý chính sách, giờ là lúc đi sâu vào các nguyên tắc bảo mật cốt lõi và thực hành tốt nhất khi làm việc với IAM. Việc áp dụng các nguyên tắc này không chỉ giúp hệ thống của bạn an toàn hơn mà còn là kiến thức cực kỳ quan trọng cho kỳ thi Associate Cloud Engineer.

Phần 4: Các Nguyên tắc Bảo mật IAM Cơ bản và Thực Hành Tốt Nhất

Cấu hình IAM không chỉ là việc gán quyền cho ai đó. Nó là việc xây dựng một nền tảng bảo mật vững chắc cho các tài nguyên đám mây của bạn. Để làm được điều đó, chúng ta cần tuân thủ một số nguyên tắc cốt lõi.

4.1. Nguyên tắc Least Privilege (Quyền hạn Tối thiểu)

Đây là nguyên tắc quan trọng nhất trong quản lý truy cập, không chỉ riêng với Google Cloud IAM mà còn trong bảo mật hệ thống nói chung.

Định nghĩa: Mỗi danh tính (người dùng, nhóm, tài khoản dịch vụ) chỉ nên được cấp quyền truy cập tối thiểu cần thiết để thực hiện công việc được giao, và không hơn.
Tại sao quan trọng?
- Giảm bề mặt tấn công: Nếu một tài khoản bị compromised, kẻ tấn công chỉ có thể truy cập và gây hại trong phạm vi quyền hạn giới hạn của tài khoản đó, thay vì có toàn quyền truy cập vào mọi thứ.
- Giảm thiểu thiệt hại do sai sót: Người dùng vô tình thực hiện hành động không mong muốn (ví dụ: xóa dữ liệu quan trọng) ít có khả năng xảy ra nếu họ không có quyền để làm điều đó.
- Tuân thủ: Nhiều quy định về bảo mật yêu cầu việc áp dụng nguyên tắc least privilege.
Cách áp dụng nguyên tắc Least Privilege trong Google Cloud IAM:
1. Sử dụng Vai trò Định sẵn (Predefined Roles) thay vì Vai trò Cơ bản (Primitive Roles): Như đã thảo luận, vai trò cơ bản (Owner, Editor) cấp quyền rất rộng trên tất cả các dịch vụ trong project. Thay vào đó, hãy tìm kiếm vai trò định sẵn cung cấp quyền cụ thể cho dịch vụ hoặc loại tài nguyên cần thiết (ví dụ: roles/compute.instanceAdmin.v1, roles/storage.objectViewer, roles/pubsub.publisher).
2. Sử dụng Vai trò Tùy chỉnh (Custom Roles) khi cần thiết: Nếu vai trò định sẵn vẫn còn quá rộng hoặc không khớp chính xác với nhu cầu, hãy tạo vai trò tùy chỉnh với tập hợp quyền chỉ bao gồm những quyền thực sự cần thiết.
3. Cấp quyền ở cấp độ Hệ thống phân cấp thấp nhất có thể:
  - Nếu một danh tính chỉ cần truy cập tài nguyên trong một project cụ thể, hãy cấp quyền ở cấp Project.
  - Nếu chỉ cần truy cập tài nguyên trong một folder cụ thể, hãy cấp quyền ở cấp Folder.
  - Nếu chỉ cần truy cập vào một tài nguyên cụ thể (ví dụ: một bucket Cloud Storage, một instance Cloud SQL - nếu dịch vụ đó hỗ trợ IAM ở cấp độ tài nguyên), hãy cấp quyền ở cấp độ tài nguyên đó. Tránh cấp quyền ở cấp Organization hoặc Folder nếu chỉ cần truy cập một vài project con.
  - Nhớ lại tính kế thừa: Quyền ở cấp cao hơn được kế thừa xuống cấp thấp hơn. Cấp quyền ở cấp thấp hơn giúp giới hạn phạm vi của quyền đó.
4. Sử dụng IAM Conditions: Để giới hạn quyền chặt chẽ hơn nữa dựa trên ngữ cảnh (thời gian, loại tài nguyên, tên, label).
5. Thường xuyên kiểm tra và xem xét lại quyền: Sử dụng IAM Policy Troubleshooter và IAM Recommendations để xác định các quyền quá mức và thu hồi chúng.
Ví dụ: Một nhà phát triển chỉ cần triển khai ứng dụng lên Cloud Run. Thay vì cấp vai trò roles/editor cho họ trên project (cho phép họ làm mọi thứ), hãy cấp các vai trò chi tiết hơn như roles/run.developer (triển khai ứng dụng) và có thể thêm roles/logging.viewer hoặc roles/monitoring.viewer nếu họ cần xem logs/metrics. Nếu họ chỉ làm việc trong một thư mục cụ thể, hãy cấp các vai trò đó ở cấp độ thư mục.

4.2. Separation of Duties (Phân tách Trách nhiệm)

Định nghĩa: Không một cá nhân hoặc dịch vụ nào nên có đủ quyền hạn để thực hiện một hành động quan trọng một mình từ đầu đến cuối, đặc biệt là các hành động có khả năng gây hại lớn (ví dụ: truy cập dữ liệu nhạy cảm và khả năng xóa logs để che dấu vết, hoặc khả năng tạo tài nguyên tốn kém và quản lý billing để che dấu chi phí).
Tại sao quan trọng?
- Ngăn chặn gian lận hoặc sai sót nghiêm trọng: Yêu cầu nhiều người (hoặc dịch vụ) cùng tham gia vào một quy trình quan trọng.
- Tăng cường kiểm soát nội bộ: Tạo ra một lớp kiểm soát bổ sung.
- Tuân thủ: Nhiều tiêu chuẩn bảo mật yêu cầu phân tách trách nhiệm.
Cách áp dụng nguyên tắc Separation of Duties trong Google Cloud IAM:
- Chia nhỏ vai trò: Không tạo một vai trò "siêu quản trị viên" duy nhất cho tất cả các khía cạnh của một dịch vụ. Ví dụ, trong quản lý mạng, có thể có vai trò compute.networkAdmin (cấu hình mạng) và compute.securityAdmin (cấu hình firewall). Gán các vai trò này cho các cá nhân/nhóm khác nhau.
- Sử dụng Tài khoản Dịch vụ khác nhau: Đối với các ứng dụng, sử dụng Tài khoản Dịch vụ riêng biệt cho các chức năng khác nhau, mỗi SA chỉ có quyền cần thiết cho chức năng đó. Ví dụ: một SA để đọc dữ liệu từ bucket, một SA khác để ghi dữ liệu vào database, một SA khác để gửi tin nhắn Pub/Sub.
- Yêu cầu phê duyệt bổ sung: Đối với các hành động cực kỳ nhạy cảm, kết hợp IAM với các quy trình kiểm soát khác (ví dụ: phê duyệt thủ công, quy trình CI/CD yêu cầu nhiều bước).
- Sử dụng IAM Conditions dựa trên thời gian hoặc ngữ cảnh: Hạn chế các quyền nhạy cảm chỉ được sử dụng trong một khoảng thời gian nhất định hoặc từ một nguồn đáng tin cậy.
Ví dụ: Bạn có dữ liệu khách hàng nhạy cảm trong Cloud Storage. Vai trò storage.objectAdmin cho phép quản lý object (bao gồm xóa). Vai trò logging.logWriter cho phép ghi logs, còn logging.viewer cho phép xem logs. Để áp dụng phân tách trách nhiệm, bạn sẽ không cấp vai trò storage.objectAdmin VÀ logging.logWriter (hoặc logging.viewer) cho cùng một cá nhân hoặc SA. Hoặc bạn có thể cấp storage.objectAdmin cho người A, và logging.viewer cho người B (người có nhiệm vụ kiểm tra log).

4.3. Sử dụng Nhóm Google (Google Groups)

Việc cấp quyền trực tiếp cho từng người dùng riêng lẻ có thể trở nên rất khó quản lý khi số lượng người dùng và project tăng lên.

Lợi ích của việc sử dụng Nhóm Google:
- Quản lý đơn giản hóa: Thay vì thêm/xóa từng người dùng khỏi hàng chục policy, bạn chỉ cần thêm/xóa người dùng khỏi một nhóm.
- Dễ kiểm tra (Audit): Bạn thấy quyền được gán cho nhóm engineering-team@company.com thay vì một danh sách dài các cá nhân. Khi một người rời công ty, việc xóa họ khỏi các nhóm Google liên quan sẽ tự động thu hồi quyền của họ thông qua các nhóm đó.
- Nhất quán: Đảm bảo tất cả thành viên của một nhóm cụ thể (ví dụ: nhóm phát triển, nhóm vận hành) đều có cùng bộ quyền cần thiết cho vai trò của họ.
Cách sử dụng Nhóm Google trong IAM:
- Tạo nhóm trong Google Workspace hoặc Cloud Identity.
- Thêm các tài khoản người dùng vào nhóm đó.
- Khi cấp quyền trong IAM Policy, sử dụng định dạng danh tính group:{group-email}.
- Ví dụ: Thay vì cấp vai trò roles/compute.viewer cho 10 người dùng riêng lẻ trên Project A, hãy tạo một nhóm network-operators@company.com, thêm 10 người đó vào nhóm, và cấp vai trò roles/compute.viewer cho group:network-operators@company.com trên Project A.
Lưu ý: Quyền hạn của nhóm chỉ áp dụng cho các thành viên tại thời điểm họ truy cập tài nguyên. Việc thay đổi thành viên của nhóm có hiệu lực gần như ngay lập tức.

4.4. Tránh Khóa Tài khoản Dịch vụ (Avoiding Service Account Keys)

Đây là một điểm cực kỳ quan trọng cho cả bảo mật và kỳ thi.

Nguy cơ của Khóa SA: File khóa (JSON hoặc P12) giống như mật khẩu tĩnh. Nếu file này bị lộ hoặc bị đánh cắp, bất kỳ ai có nó đều có thể giả danh Tài khoản Dịch vụ đó và thực hiện tất cả các hành động mà SA được phép làm. Việc quản lý, lưu trữ, và xoay vòng khóa an toàn rất khó khăn và dễ xảy ra lỗi.
Khi nào Khóa SA có thể cần thiết (và cần cẩn trọng):
- Chạy ứng dụng trên môi trường ngoài Google Cloud (on-premises, cloud khác) cần truy cập Google Cloud API.
- Các kịch bản CI/CD chạy bên ngoài Google Cloud cần tương tác với Google Cloud.
Các Cơ chế Xác thực Thay thế (KHÔNG dùng Khóa - Highly Recommended):
- Đối với Compute Engine VMs: Đính kèm Tài khoản Dịch vụ (Attach Service Account): Gán SA cho VM khi tạo. VM sẽ tự động nhận dạng là SA đó thông qua Metadata Server. Ứng dụng trên VM sử dụng thư viện client của Google Cloud, thư viện này sẽ tự động lấy token truy cập ngắn hạn từ metadata server và sử dụng token đó để gọi API. Đây là cách an toàn nhất để VM truy cập Google Cloud APIs. Phải hiểu cách gán SA cho VM và cấu hình API scopes (hoặc quyền IAM cho SA) cho kỳ thi.
- Đối với Google Kubernetes Engine (GKE): Workload Identity: Liên kết Tài khoản Dịch vụ Kubernetes với Tài khoản Dịch vụ Google Cloud. Pods chạy dưới SA Kubernetes đó sẽ tự động xác thực là SA Google Cloud được liên kết. Đây là cách an toàn nhất cho GKE.
- Đối với Cloud Functions, Cloud Run, App Engine (Standard/Flex): Chỉ định Tài khoản Dịch vụ khi triển khai dịch vụ. Các dịch vụ này sẽ chạy dưới danh tính của SA đó và tự động xác thực.
- Đối với các môi trường bên ngoài Google Cloud: Workload Identity Federation: Cho phép danh tính từ các nhà cung cấp nhận dạng bên ngoài (AWS, Azure, Okta, On-prem AD FS, v.v.) trao đổi chứng chỉ của họ để lấy token Google Cloud ngắn hạn và giả danh một SA Google Cloud. Cách này không cần tạo và quản lý khóa SA.
- Service Account Impersonation (ủy quyền sử dụng SA): Cho phép một danh tính (người dùng, SA khác) yêu cầu tạo token ngắn hạn để hành động như một SA khác. Điều này cũng tránh việc phải chia sẻ khóa SA.

Tóm lại: Đối với hầu hết các trường hợp sử dụng trong Google Cloud (VMs, GKE, serverless), luôn ưu tiên các cơ chế xác thực không cần khóa. Chỉ sử dụng khóa SA khi thực sự không có lựa chọn nào khác, và khi đó phải quản lý khóa cực kỳ cẩn thận.

4.5. Bảo vệ Khóa SA nếu Bắt Buộc Phải Dùng (Ngắn gọn)

Nếu bạn buộc phải tạo và sử dụng khóa SA (ví dụ: cho ứng dụng on-premises), hãy thực hiện các biện pháp bảo vệ nghiêm ngặt:

Lưu trữ an toàn: Không lưu khóa trong mã nguồn, file cấu hình trên đĩa, hoặc repository công khai. Sử dụng các giải pháp quản lý bí mật chuyên dụng như Google Cloud Secret Manager, HashiCorp Vault, hoặc các giải pháp tương tự.
Giới hạn quyền của SA: Đảm bảo SA mà khóa thuộc về chỉ có quyền tối thiểu cần thiết.
Xoay vòng khóa định kỳ: Tạo khóa mới, cập nhật ứng dụng để sử dụng khóa mới, và xóa khóa cũ theo lịch trình đều đặn.
Giám sát việc sử dụng khóa: Theo dõi Audit Logs để phát hiện việc sử dụng khóa SA bất thường.
Chỉ tạo khóa JSON: Định dạng P12 là định dạng cũ và ít được khuyến khích.

4.6. Sử dụng IAM Recommendations

Google Cloud cung cấp các khuyến nghị bảo mật thông qua IAM Recommender.

Mục đích: Phân tích log sử dụng quyền (Audit Logs) và so sánh chúng với các chính sách IAM hiện tại để đề xuất việc thu hồi các quyền không cần thiết hoặc quá mức.
Cách Hoạt động: Recommender nhìn vào hành động thực tế mà một danh tính đã thực hiện trong một khoảng thời gian gần đây và so sánh nó với tập hợp quyền mà vai trò được cấp cho danh tính đó cho phép. Nếu một vai trò cấp nhiều quyền mà danh tính chưa bao giờ sử dụng, Recommender có thể đề xuất thay thế vai trò đó bằng một vai trò khác hẹp hơn chỉ chứa các quyền đã sử dụng.
Lợi ích:
- Giúp tự động phát hiện các vi phạm nguyên tắc "least privilege".
- Hỗ trợ việc xem xét lại quyền định kỳ.
- Cải thiện tư thế bảo mật tổng thể mà không cần phân tích thủ công phức tạp.
Truy cập: Bạn có thể xem các khuyến nghị IAM trong Google Cloud Console tại trang IAM & Admin -> IAM. Tìm kiếm mục "Recommendations". Recommender cũng có API và hoạt động trong gcloud.
Relevance cho Associate Exam: Bạn nên biết rằng Google Cloud cung cấp công cụ để giúp bạn áp dụng least privilege và cải thiện bảo mật IAM. Biết tên tính năng (IAM Recommender) và mục đích của nó là đủ cho cấp độ Associate.

Tóm tắt Phần 4:

Phần 4 tập trung vào việc áp dụng IAM một cách an toàn và hiệu quả:

Least Privilege: Luôn là nguyên tắc hàng đầu. Sử dụng vai trò định sẵn/tùy chỉnh, cấp quyền ở cấp độ thấp nhất trong hệ thống phân cấp, và sử dụng điều kiện.
Separation of Duties: Chia nhỏ quyền hạn để không ai có thể thực hiện hành động nguy hiểm một mình. Sử dụng vai trò khác nhau, SA khác nhau.
Google Groups: Đơn giản hóa quản lý bằng cách cấp quyền cho nhóm thay vì cá nhân.
Service Accounts: Hiểu rõ tầm quan trọng của SA cho ứng dụng. Tuyệt đối tránh sử dụng khóa SA trong Google Cloud (VM, GKE, serverless) và ưu tiên các cơ chế không khóa.
IAM Recommendations: Sử dụng công cụ tự động để phát hiện và khắc phục các quyền quá mức.

Tuyệt vời! Chúng ta sẽ tiếp tục và hoàn thành phân tích chuyên sâu về Google Cloud IAM trong lần trả lời này, bao gồm các phần còn lại trong mục lục.

Mục Lục Phân Tích Chuyên Sâu về Google Cloud Identity and Access Management (IAM)

... (Mục lục các Phần 1, 2, 3, 4 đã hoàn thành) ...

Phần 5: Giám Sát, Kiểm Tra và Khắc Phục Sự Cố IAM (Đang viết...)
- 5.1. Cloud Audit Logs (Nhật ký Kiểm tra) cho IAM
- 5.2. IAM Policy Troubleshooter
- 5.3. Security Command Center và Web Security Scanner (liên quan đến lỗ hổng IAM)
Phần 6: IAM trong Bối cảnh Google Cloud Rộng Hơn (Đang viết...)
- 6.1. IAM và Hệ thống phân cấp Tài nguyên (Organization, Folder, Project)
- 6.2. IAM và Billing (Thanh toán)
- 6.3. IAM và Organization Policies (Chính sách Tổ chức) - Khác biệt và liên quan
- 6.4. IAM và Các Dịch vụ Khác của Google Cloud
Phần 7: Chuẩn Bị cho Kỳ thi Google Cloud Associate Cloud Engineer - Phần IAM (Đang viết...)
- 7.1. Các Chủ đề IAM Quan trọng nhất cần Nắm vững cho Kỳ thi
- 7.2. Các Dạng Câu hỏi Thường Gặp về IAM
- 7.3. Lời Khuyên Ôn Tập Hiệu Quả cho IAM

Phần 5: Giám Sát, Kiểm Tra và Khắc Phục Sự Cố IAM

Việc thiết lập chính sách IAM chỉ là bước đầu. Để đảm bảo môi trường an toàn và xử lý các vấn đề phát sinh, bạn cần có khả năng giám sát hoạt động liên quan đến quyền truy cập, kiểm tra hiệu lực của chính sách và khắc phục sự cố khi có người dùng hoặc ứng dụng không truy cập được tài nguyên hoặc có quyền quá mức.

5.1. Cloud Audit Logs (Nhật ký Kiểm tra) cho IAM

Google Cloud tự động ghi lại các hoạt động quản trị và truy cập dữ liệu trong Cloud Audit Logs. Đây là nguồn thông tin vô giá để theo dõi các sự kiện liên quan đến IAM.

Các loại Audit Logs chính liên quan đến IAM:
- Admin Activity logs (Nhật ký Hoạt động Quản trị): Ghi lại các thao tác "write" của admin, tức là các hành động thay đổi cấu hình hoặc metadata của tài nguyên. Các thay đổi đối với IAM Policy (thêm/xóa binding) được ghi lại trong Admin Activity logs. Các log này được bật mặc định và miễn phí.
  - Ví dụ: Ai đã thêm vai trò roles/storage.objectAdmin cho nhóm X trên project Y lúc nào? Ai đã xóa binding này?
- Data Access logs (Nhật ký Truy cập Dữ liệu): Ghi lại các thao tác "read" của admin (đọc metadata) và các thao tác "read/write" của người dùng trên dữ liệu được cung cấp bởi các dịch vụ (ví dụ: đọc object trong Cloud Storage, đọc row trong BigQuery). Log truy cập dữ liệu này không được bật mặc định vì chúng có thể tạo ra lượng log khổng lồ. Bạn cần bật chúng rõ ràng cho từng dịch vụ cụ thể nếu cần giám sát ai truy cập dữ liệu nào.
  - Ví dụ: Tài khoản dịch vụ Z đã cố gắng đọc object A trong bucket B lúc nào? Yêu cầu đó có được phép hay không? (Quyết định cho phép/từ chối được ghi lại trong log).
- System Event logs (Nhật ký Sự kiện Hệ thống): Ghi lại các hành động của Google Cloud.
- Policy Denied logs (Nhật ký Chính sách Bị Từ chối): Ghi lại các lần truy cập bị từ chối bởi Organization Policy Service (khác với IAM Deny Policies).
Thông tin quan trọng trong Audit Logs liên quan đến IAM:
- protoPayload.authenticationInfo.principalEmail: Danh tính (người dùng, SA) thực hiện hành động.
- protoPayload.methodName: API method được gọi (ví dụ: SetIamPolicy, GetIamPolicy, CreateInstance, Storage.Objects.Get).
- protoPayload.resource.type: Loại tài nguyên bị tác động (ví dụ: cloudresourcemanager.googleapis.com/Project, storage.googleapis.com/Bucket, compute.googleapis.com/Instance).
- protoPayload.resource.name: Tên tài nguyên bị tác động.
- protoPayload.response: Kết quả của hành động (đối với Admin Activity logs).
- protoPayload.authorizationInfo: Thông tin về việc kiểm tra quyền. Mục này sẽ cho biết quyền nào được yêu cầu (permission), tài nguyên nào bị kiểm tra (resource), và kết quả kiểm tra (granted - true/false). Đây là thông tin rất hữu ích để gỡ lỗi truy cập bị từ chối.
- protoPayload.status: Trạng thái của yêu cầu (OK, PERMISSION_DENIED, NOT_FOUND, v.v.).
Cách xem Audit Logs:
- Google Cloud Console: Sử dụng Cloud Logging -> Logs Explorer. Bạn có thể lọc log theo Resource type (Project, Bucket, v.v.), Log name (admin_activity, data_access, system_event), và các trường khác (principalEmail, methodName, status).
- gcloud CLI: Sử dụng lệnh gcloud logging read.
- Client Libraries/API: Truy cập logs theo chương trình.
Ứng dụng của Audit Logs cho IAM:
- Giám sát thay đổi chính sách: Theo dõi ai đã thay đổi IAM Policy trên các tài nguyên quan trọng.
- Điều tra sự cố bảo mật: Nếu có hoạt động đáng ngờ, Audit Logs giúp xác định danh tính nào đã thực hiện hành động gì.
- Khắc phục sự cố truy cập: Khi một người dùng hoặc ứng dụng báo cáo không truy cập được tài nguyên, Audit Logs (đặc biệt là Data Access logs nếu được bật) sẽ hiển thị yêu cầu bị từ chối và lý do (ví dụ: PERMISSION_DENIED).

5.2. IAM Policy Troubleshooter

Đây là một công cụ rất hữu ích để chẩn đoán tại sao một danh tính lại có (hoặc không có) quyền thực hiện một hành động cụ thể trên một tài nguyên cụ thể.

Mục đích: Giúp trả lời câu hỏi: "Tại sao Alice có thể xóa VM X?" hoặc "Tại sao tài khoản dịch vụ Y không thể ghi vào bucket Z?".
Cách Hoạt động: Bạn cung cấp các thông tin sau:
- Principal (Danh tính): Ai là người/dịch vụ (ví dụ: user:alice@example.com, serviceAccount:my-sa@my-project.iam.gserviceaccount.com).
- Permission (Quyền): Quyền cụ thể mà bạn đang kiểm tra (ví dụ: compute.instances.delete, storage.objects.create).
- Resource (Tài nguyên): Tài nguyên mà quyền đó được kiểm tra (ví dụ: project ID, tên bucket, tên VM).
Kết quả: Policy Troubleshooter sẽ phân tích tất cả các chính sách IAM được áp dụng cho tài nguyên đó và các tài nguyên cha trong hệ thống phân cấp, xem xét tất cả các vai trò được gán cho danh tính (trực tiếp, qua nhóm, qua domain), và cho bạn biết:
- Liệu quyền đó có được cấp hay không (GRANTED hoặc NOT_GRANTED).
- Lý do tại sao được cấp (hiển thị chính sách binding cụ thể trên tài nguyên nào, thông qua vai trò nào, thông qua thành viên nào - user, group, SA - đã cấp quyền đó).
- Lý do tại sao không được cấp (hiển thị các binding có liên quan nhưng không khớp, hoặc cho biết không có binding nào cấp quyền đó).
- Nó cũng xem xét các IAM Conditions và Deny Policies (nếu có) khi phân tích.
Truy cập:
- Google Cloud Console: IAM & Admin -> IAM -> Policy Troubleshooter.
- gcloud CLI: Sử dụng lệnh gcloud iam troubleshoot policy.
Ứng dụng của Policy Troubleshooter:
- Gỡ lỗi truy cập bị từ chối: Khi người dùng không thể làm gì đó, Policy Troubleshooter là công cụ đầu tiên bạn nên dùng để hiểu tại sao.
- Kiểm tra quyền quá mức: Ngược lại, nếu bạn nghi ngờ một danh tính có quá nhiều quyền, bạn có thể kiểm tra các quyền nhạy cảm để xem chúng được cấp từ đâu.
- Hiểu tính kế thừa: Công cụ này giúp bạn trực quan hóa cách các chính sách từ các cấp khác nhau trong hệ thống phân cấp ảnh hưởng đến quyền hạn cuối cùng.
Relevance cho Associate Exam: Bạn cần biết Policy Troubleshooter tồn tại và mục đích chính của nó là gì (tìm hiểu lý do được cấp/bị từ chối quyền). Bạn có thể gặp các kịch bản trong bài thi yêu cầu bạn xác định công cụ nào sẽ giúp chẩn đoán vấn đề quyền truy cập.

5.3. Security Command Center (SCC) và Web Security Scanner (liên quan đến lỗ hổng IAM)

Mặc dù SCC không phải là công cụ quản lý IAM trực tiếp, nó là một dịch vụ giám sát bảo mật có thể giúp phát hiện các lỗ hổng liên quan đến IAM.

Security Command Center (SCC): Là một nền tảng quản lý rủi ro và bảo mật tập trung cho Google Cloud. Nó tổng hợp các kết quả quét và phát hiện từ nhiều nguồn khác nhau (bao gồm cả các trình quét của Google Cloud và các tích hợp của bên thứ ba).
- SCC có thể phát hiện các vấn đề liên quan đến IAM như:
  - Tài khoản dịch vụ có khóa đã lâu không được sử dụng (phát hiện bởi Security Health Analytics, một dịch vụ tích hợp của SCC).
  - Các bucket Cloud Storage được cấu hình công khai (allUsers hoặc allAuthenticatedUsers).
  - Vai trò cơ bản (Owner, Editor) được gán cho số lượng lớn người dùng hoặc tài khoản dịch vụ.
  - Các chính sách IAM phức tạp hoặc bất thường.
- SCC cung cấp cái nhìn tổng quan về tư thế bảo mật của bạn, bao gồm cả các vấn đề về quản lý danh tính và truy cập.
Web Security Scanner: Một dịch vụ tích hợp trong SCC (hoặc có thể chạy độc lập) giúp tìm lỗ hổng bảo mật trong các ứng dụng web. Mặc dù không trực tiếp quét IAM policies, nó có thể phát hiện các lỗ hổng trong ứng dụng có thể dẫn đến việc rò rỉ thông tin đăng nhập hoặc khóa SA, từ đó ảnh hưởng đến bảo mật IAM.
Relevance cho Associate Exam: Bạn nên biết SCC là nơi tập trung các phát hiện bảo mật và nó có thể cảnh báo về các cấu hình IAM không an toàn (ví dụ: bucket công khai, khóa SA cũ).

Phần 6: IAM trong Bối cảnh Google Cloud Rộng Hơn

IAM không hoạt động độc lập. Nó tương tác và liên quan chặt chẽ với các khía cạnh khác của Google Cloud. Hiểu các mối quan hệ này là cần thiết để có cái nhìn toàn diện.

6.1. IAM và Hệ thống phân cấp Tài nguyên (Organization, Folder, Project)

Chúng ta đã thảo luận về tính kế thừa của policy trong hệ thống phân cấp (Organization > Folder > Project > Resource). Đây là mối quan hệ cốt lõi nhất của IAM.

Quyền được kiểm tra dựa trên hệ thống phân cấp: Khi một danh tính cố gắng thực hiện một hành động trên một tài nguyên, Google Cloud kiểm tra policy trên tài nguyên đó và policy trên tất cả các tài nguyên cha của nó lên đến đỉnh (Organization).
Thiết kế chính sách dựa trên cấu trúc phân cấp: Bạn nên thiết kế cấu trúc Organization/Folder/Project của mình sao cho phù hợp với cấu trúc tổ chức hoặc ứng dụng của bạn, điều này sẽ giúp việc quản lý IAM dễ dàng và logic hơn. Cố gắng nhóm các tài nguyên có yêu cầu truy cập tương tự vào cùng một Project hoặc Folder.

6.2. IAM và Billing (Thanh toán)

IAM kiểm soát ai có thể xem và quản lý thông tin thanh toán của bạn.

Billing Account: Là nơi bạn thiết lập phương thức thanh toán và theo dõi chi phí. Một Billing Account có thể liên kết với một hoặc nhiều Projects.
IAM Policy cho Billing Account: Billing Account có policy IAM riêng, độc lập với policy của Organization/Folders/Projects.
- Các vai trò liên quan đến Billing:
  - roles/billing.viewer: Chỉ xem thông tin billing (chi phí, báo cáo).
  - roles/billing.costManager: Xem thông tin billing và quản lý chi phí (đặt ngân sách, export dữ liệu).
  - roles/billing.user: Liên kết project với Billing Account. Cần vai trò này trên cả Billing Account và Project để liên kết chúng.
  - roles/billing.admin: Toàn quyền quản lý Billing Account (thêm/xóa người dùng, cấu hình phương thức thanh toán, đóng tài khoản).
Liên kết Project với Billing Account: Để một project phát sinh chi phí vào một Billing Account cụ thể, project đó phải được liên kết với Billing Account đó. Người thực hiện việc liên kết cần có vai trò roles/billing.user trên Billing Account VÀ trên Project đó.

6.3. IAM và Organization Policies (Chính sách Tổ chức)

Đây là hai dịch vụ bảo mật khác nhau nhưng bổ sung cho nhau.

IAM: Ai (Principal) có thể làm gì (Role/Permissions) trên tài nguyên nào (Resource). IAM quản lý ủy quyền.
Organization Policy Service: Đặt ra các giới hạn hoặc ràng buộc về cấu hình cho các tài nguyên trong Organization, Folders, Projects. Nó định nghĩa những gì được phép/không được phép cấu hình trong môi trường của bạn, bất kể ai đang thực hiện cấu hình đó.
- Ví dụ về Organization Policy:
  - Giới hạn các loại máy ảo được phép tạo.
  - Chỉ cho phép sử dụng một tập hợp các Image VM được phê duyệt.
  - Ngăn chặn việc tạo các địa chỉ IP công cộng tĩnh.
  - Ngăn chặn việc cấu hình bucket Cloud Storage là công khai (constraints/storage.publicAccessPrevention). Đây là một ví dụ quan trọng liên quan đến IAM, nơi Organization Policy có thể ngăn chặn một cấu hình mà IAM có thể cho phép (ví dụ: người dùng có vai trò storage.admin có thể cố gắng đặt bucket công khai, nhưng Organization Policy sẽ từ chối hành động này).
Mối liên hệ: Organization Policies hoạt động như một lớp kiểm soát thứ cấp. IAM kiểm soát ai có quyền thực hiện hành động. Organization Policy kiểm soát liệu hành động đó có được phép về mặt chính sách cấu hình của tổ chức hay không. Nếu cả hai đều cho phép, hành động sẽ được thực hiện. Nếu một trong hai từ chối, hành động sẽ bị từ chối (Organization Policy Deny ghi đè lên IAM Allow).
Relevance cho Associate Exam: Bạn nên biết sự khác biệt cơ bản giữa IAM (quản lý truy cập dựa trên danh tính) và Organization Policy (quản lý cấu hình dựa trên quy tắc của tổ chức) và biết rằng Organization Policy có thể giới hạn các hành động mà IAM cho phép.

6.4. IAM và Các Dịch vụ Khác của Google Cloud

Hầu hết các dịch vụ Google Cloud đều tích hợp với IAM.

Mỗi dịch vụ có một tập hợp các loại tài nguyên và quyền cụ thể của riêng nó (ví dụ: compute.instances.create, storage.buckets.list, pubsub.topics.publish, sql.instances.delete).
Các vai trò định sẵn được thiết kế cho từng dịch vụ (ví dụ: roles/compute.admin, roles/storage.objectAdmin, roles/pubsub.editor, roles/cloudsql.admin).
Tài khoản Dịch vụ thường được sử dụng để một dịch vụ này truy cập dịch vụ khác (ví dụ: Cloud Functions cần quyền để gọi Cloud Vision API; một VM cần quyền để truy cập Cloud Storage). Việc gán đúng vai trò cho SA của dịch vụ/VM là rất quan trọng.
Một số dịch vụ hỗ trợ IAM ở cấp độ tài nguyên con (ví dụ: Cloud Storage buckets, Pub/Sub topics/subscriptions, BigQuery datasets/tables).

Tóm tắt Phần 6:

IAMPolicy tuân theo hệ thống phân cấp tài nguyên (Org > Folder > Project > Resource) với tính kế thừa cộng dồn.
IAM kiểm soát quyền truy cập vào thông tin và quản lý Billing Account thông qua các vai trò Billing chuyên biệt.
Organization Policies là lớp kiểm soát bổ sung đặt ra các giới hạn cấu hình, hoạt động độc lập và có thể ghi đè IAM Allows.
IAM tích hợp sâu với hầu hết các dịch vụ Google Cloud, cung cấp các quyền và vai trò dành riêng cho từng dịch vụ.

Phần 7: Chuẩn Bị cho Kỳ thi Google Cloud Associate Cloud Engineer - Phần IAM

IAM là một chủ đề lớn và chắc chắn sẽ xuất hiện trong kỳ thi. Đây là cách bạn nên ôn tập.

7.1. Các Chủ đề IAM Quan trọng nhất cần Nắm vững cho Kỳ thi

Dựa trên cấu trúc bài thi và tài liệu ôn tập của Google Cloud, các chủ đề IAM sau là trọng tâm cho cấp độ Associate:

Các khái niệm cơ bản: Hiểu rõ "Who", "What", "Where" (Principal/Member, Role/Permissions, Resource Hierarchy).
IAM Policy: Hiểu Policy là gì, Binding là gì. Cách Policy được đính kèm vào tài nguyên.
Hệ thống phân cấp Tài nguyên: Hiểu cấu trúc Org/Folder/Project/Resource và tính kế thừa của Policy.
Các loại danh tính (Principals/Members): Đặc biệt là Tài khoản Dịch vụ (Service Accounts) (User-managed vs. Google-managed, cách xác thực không dùng khóa - VM attached SA & API Scopes là quan trọng, Workload Identity - biết tên và mục đích). Biết định dạng email của SA.
Các loại Vai trò (Roles): Phân biệt Primitive, Predefined, Custom. Biết tại sao nên ưu tiên Predefined/Custom và tránh Primitive roles trong production. Biết các vai trò định sẵn phổ biến cho các dịch vụ cốt lõi (Compute, Storage, Pub/Sub, SQL).
Permissions: Hiểu cấu trúc tên quyền {service}.{resource}.{verb}.
Cách quản lý IAM Policy:
- Sử dụng Google Cloud Console để xem, thêm, xóa bindings.
- Sử dụng gcloud CLI (get-iam-policy, add-iam-policy-binding, remove-iam-policy-binding, set-iam-policy). Biết các lệnh quản lý SA và Custom Roles bằng gcloud.
Các nguyên tắc bảo mật: Nguyên tắc Least Privilege là cực kỳ quan trọng. Hiểu cách áp dụng nó bằng cách chọn vai trò hẹp, cấp quyền ở cấp thấp nhất. Biết các nguyên tắc khác như Separation of Duties, sử dụng Google Groups, tránh khóa SA.
Công cụ khắc phục sự cố: Biết mục đích và cách sử dụng IAM Policy Troubleshooter.
Mối liên hệ với các dịch vụ khác: Hiểu SA được sử dụng như thế nào để các dịch vụ tương tác với nhau.
IAM vs Organization Policy: Hiểu sự khác biệt cơ bản.

7.2. Các Dạng Câu hỏi Thường Gặp về IAM

Câu hỏi về IAM trong kỳ thi Associate thường theo dạng kịch bản (scenario-based) hoặc hỏi về công cụ/lệnh cụ thể.

Kịch bản về cấp quyền: "Một nhóm người dùng cần có khả năng X trên tài nguyên Y. Bạn nên cấp vai trò nào cho ai ở cấp độ nào trong hệ thống phân cấp để tuân thủ nguyên tắc least privilege?"
- Bạn cần phân tích: Họ là ai (người dùng, nhóm)? Họ cần làm gì (quyền/vai trò nào)? Trên tài nguyên nào (cấp độ nào trong hệ thống phân cấp)?
- Chọn vai trò định sẵn phù hợp nhất, hoặc xác định cần vai trò tùy chỉnh.
- Xác định cấp độ phù hợp (Project, Folder, Organization, hoặc tài nguyên cụ thể nếu được hỗ trợ).
- Quyết định có nên dùng nhóm Google hay không.
Kịch bản về Tài khoản Dịch vụ: "Ứng dụng chạy trên VM cần truy cập Cloud Storage. Cách an toàn nhất để cấp quyền là gì?"
- Đáp án mong đợi: Tạo SA với quyền storage.object* cần thiết, đính kèm SA đó vào VM, KHÔNG tạo và sử dụng khóa SA.
- Câu hỏi có thể bao gồm cả API scopes trên VM và mối quan hệ của nó với IAM Roles.
Kịch bản về khắc phục sự cố: "Người dùng X không thể thực hiện hành động Y trên tài nguyên Z. Công cụ nào giúp bạn chẩn đoán vấn đề này?"
- Đáp án mong đợi: IAM Policy Troubleshooter.
- Câu hỏi có thể hỏi về cách sử dụng Audit Logs để xem lịch sử thay đổi policy hoặc các yêu cầu bị từ chối.
Câu hỏi về công cụ/lệnh gcloud: Hỏi lệnh cụ thể để thêm/xóa binding, tạo SA, xem policy, v.v.
Câu hỏi về nguyên tắc bảo mật: Hỏi về lý do áp dụng least privilege, lợi ích của việc sử dụng nhóm, nguy cơ của khóa SA.
Câu hỏi về Organization Policy: Hỏi sự khác biệt giữa IAM và Organization Policy, hoặc kịch bản policy nào phù hợp để ngăn chặn một hành động cấu hình cụ thể.

7.3. Lời Khuyên Ôn Tập Hiệu Quả cho IAM

Học Lý thuyết và Thực Hành: Đọc tài liệu chính thức của Google Cloud về IAM. Sau đó, tạo một Project thử nghiệm và tự thực hành các thao tác:
- Tạo người dùng giả (nếu bạn có quyền quản lý Cloud Identity/Workspace) hoặc sử dụng các danh tính khác.
- Tạo nhóm Google và thêm thành viên.
- Tạo Tài khoản Dịch vụ do người dùng quản lý.
- Tạo vài tài nguyên (VM, bucket, topic).
- Sử dụng Cloud Console và gcloud để:
  - Xem policy của project, bucket, SA.
  - Cấp vai trò định sẵn (Compute Admin trên project, Storage Object Viewer trên bucket) cho người dùng, nhóm, SA.
  - Thu hồi các quyền đó.
  - Thử đính kèm SA vào VM và cấu hình scopes.
  - Tạo vai trò tùy chỉnh với một vài quyền đơn giản và gán nó.
- Xem Audit Logs sau khi thực hiện các thay đổi policy.
- Thử sử dụng Policy Troubleshooter để phân tích quyền hạn của một danh tính.
Tập Trung vào Tài khoản Dịch vụ và Cơ chế Không Khóa: Đây là chủ đề rất quan trọng trong các kỳ thi của Google Cloud. Hiểu sâu về SA, cách chúng được sử dụng bởi các dịch vụ khác, và các phương pháp xác thực an toàn thay thế cho khóa.
Nắm Vững Tính Kế thừa: Vẽ sơ đồ hệ thống phân cấp tài nguyên của bạn và hình dung các policy từ cấp trên được kế thừa xuống như thế nào. Thực hành kiểm tra policy hiệu quả bằng cách xem xét policy ở các cấp khác nhau.
Học các Vai trò Phổ biến: Không cần nhớ tất cả các vai trò, nhưng hãy làm quen với các vai trò cơ bản và các vai trò định sẵn phổ biến nhất cho Compute Engine, Cloud Storage, Networking, Pub/Sub, BigQuery, và tất nhiên là IAM itself. Quan trọng là biết cách tìm kiếm vai trò phù hợp trong tài liệu hoặc Console.
Luyện Giải Quyết Kịch bản: Đọc các kịch bản và tự trả lời các câu hỏi "Ai cần quyền gì trên đâu?". Điều này giúp bạn áp dụng lý thuyết vào tình huống thực tế.
Sử dụng Tài nguyên Ôn Tập Chính Thức: Khóa học trên Coursera/Google Cloud Skills Boost, tài liệu chính thức, các bài kiểm tra thử (practice exams) của Google Cloud.

Kết luận: Nắm vững IAM

IAM là nền tảng bảo mật của Google Cloud. Việc hiểu sâu sắc cách nó hoạt động không chỉ giúp bạn vượt qua kỳ thi Associate Cloud Engineer mà còn là kỹ năng bắt buộc để làm việc an toàn và hiệu quả trên nền tảng này. Hãy đầu tư thời gian để học các khái niệm, thực hành cấu hình, và làm quen với các công cụ quản lý và gỡ lỗi.

Với kiến thức chi tiết và chuyên sâu về các thành phần, nguyên tắc và công cụ IAM như đã trình bày, bạn đã có một nền tảng vững chắc để tự tin ôn tập và chinh phục các câu hỏi về IAM trong kỳ thi Associate Cloud Engineer.

Chúc bạn ôn tập tốt và thành công!

Phân Tích Chuyên Sâu về Google Cloud Identity and Access Management (IAM) ​

Phần 1: Giới thiệu & Khái niệm Cơ bản về IAM ​

1.1. IAM là gì? Tại sao chúng ta cần nó? ​

1.2. Các Thành phần Chính của IAM ​

1.2.1. Thành phần "Who": Danh tính (Principal / Member) ​

1.2.2. Thành phần "What": Vai trò (Role) và Quyền (Permissions) ​

1.2.3. Thành phần "Where": Tài nguyên và Hệ thống phân cấp Tài nguyên ​

1.3. IAM Policy (Chính sách IAM) ​

1.4. Policy Evaluation (Đánh giá Chính sách) ​

1.5. Hệ thống phân cấp Tài nguyên và Tính kế thừa (Inheritance) ​

Phần 2: Khám phá Chi tiết các Thành phần của IAM ​

2.1. Thành phần "Who" Chuyên Sâu: Tài khoản Dịch vụ (Service Accounts) ​

2.2. Phân tích Chi tiết về Vai trò (Roles) ​

2.3. Chính sách Ràng buộc có Điều kiện (IAM Conditions) ​

Tóm lại Phần 2: ​

Phần 3: Quản lý IAM Policies và Thực Hành ​

3.1. Xem Chính sách IAM Hiện tại ​

3.2. Cấp (Thêm) Quyền - Thêm Bindings vào Policy ​

3.3. Thu Hồi (Xóa) Quyền - Xóa Bindings khỏi Policy ​

3.4. Sử dụng Google Cloud Console để Quản lý IAM ​

3.5. Sử dụng gcloud Command-Line Tool để Quản lý IAM ​

3.6. Sử dụng API và Infrastructure as Code (Terraform, Deployment Manager) ​

Phần 4: Các Nguyên tắc Bảo mật IAM Cơ bản và Thực Hành Tốt Nhất ​

4.1. Nguyên tắc Least Privilege (Quyền hạn Tối thiểu) ​

4.2. Separation of Duties (Phân tách Trách nhiệm) ​

4.3. Sử dụng Nhóm Google (Google Groups) ​

4.4. Tránh Khóa Tài khoản Dịch vụ (Avoiding Service Account Keys) ​

4.5. Bảo vệ Khóa SA nếu Bắt Buộc Phải Dùng (Ngắn gọn) ​

4.6. Sử dụng IAM Recommendations ​

Tóm tắt Phần 4: ​

Phần 5: Giám Sát, Kiểm Tra và Khắc Phục Sự Cố IAM ​

5.1. Cloud Audit Logs (Nhật ký Kiểm tra) cho IAM ​

5.2. IAM Policy Troubleshooter ​

5.3. Security Command Center (SCC) và Web Security Scanner (liên quan đến lỗ hổng IAM) ​

Phần 6: IAM trong Bối cảnh Google Cloud Rộng Hơn ​

6.1. IAM và Hệ thống phân cấp Tài nguyên (Organization, Folder, Project) ​

6.2. IAM và Billing (Thanh toán) ​

6.3. IAM và Organization Policies (Chính sách Tổ chức) ​

6.4. IAM và Các Dịch vụ Khác của Google Cloud ​

Tóm tắt Phần 6: ​

Phần 7: Chuẩn Bị cho Kỳ thi Google Cloud Associate Cloud Engineer - Phần IAM ​

7.1. Các Chủ đề IAM Quan trọng nhất cần Nắm vững cho Kỳ thi ​

7.2. Các Dạng Câu hỏi Thường Gặp về IAM ​

7.3. Lời Khuyên Ôn Tập Hiệu Quả cho IAM ​

Kết luận: Nắm vững IAM ​

Phân Tích Chuyên Sâu về Google Cloud Identity and Access Management (IAM)

Phần 1: Giới thiệu & Khái niệm Cơ bản về IAM

1.1. IAM là gì? Tại sao chúng ta cần nó?

1.2. Các Thành phần Chính của IAM

1.2.1. Thành phần "Who": Danh tính (Principal / Member)

1.2.2. Thành phần "What": Vai trò (Role) và Quyền (Permissions)

1.2.3. Thành phần "Where": Tài nguyên và Hệ thống phân cấp Tài nguyên

1.3. IAM Policy (Chính sách IAM)

1.4. Policy Evaluation (Đánh giá Chính sách)

1.5. Hệ thống phân cấp Tài nguyên và Tính kế thừa (Inheritance)

Phần 2: Khám phá Chi tiết các Thành phần của IAM

2.1. Thành phần "Who" Chuyên Sâu: Tài khoản Dịch vụ (Service Accounts)

2.2. Phân tích Chi tiết về Vai trò (Roles)

2.3. Chính sách Ràng buộc có Điều kiện (IAM Conditions)

Tóm lại Phần 2:

Phần 3: Quản lý IAM Policies và Thực Hành

3.1. Xem Chính sách IAM Hiện tại

3.2. Cấp (Thêm) Quyền - Thêm Bindings vào Policy

3.3. Thu Hồi (Xóa) Quyền - Xóa Bindings khỏi Policy

3.4. Sử dụng Google Cloud Console để Quản lý IAM

3.5. Sử dụng `gcloud` Command-Line Tool để Quản lý IAM

3.6. Sử dụng API và Infrastructure as Code (Terraform, Deployment Manager)

Phần 4: Các Nguyên tắc Bảo mật IAM Cơ bản và Thực Hành Tốt Nhất

4.1. Nguyên tắc Least Privilege (Quyền hạn Tối thiểu)

4.2. Separation of Duties (Phân tách Trách nhiệm)

4.3. Sử dụng Nhóm Google (Google Groups)

4.4. Tránh Khóa Tài khoản Dịch vụ (Avoiding Service Account Keys)

4.5. Bảo vệ Khóa SA nếu Bắt Buộc Phải Dùng (Ngắn gọn)

4.6. Sử dụng IAM Recommendations

Tóm tắt Phần 4:

Phần 5: Giám Sát, Kiểm Tra và Khắc Phục Sự Cố IAM

5.1. Cloud Audit Logs (Nhật ký Kiểm tra) cho IAM

5.2. IAM Policy Troubleshooter

5.3. Security Command Center (SCC) và Web Security Scanner (liên quan đến lỗ hổng IAM)

Phần 6: IAM trong Bối cảnh Google Cloud Rộng Hơn

6.1. IAM và Hệ thống phân cấp Tài nguyên (Organization, Folder, Project)

6.2. IAM và Billing (Thanh toán)

6.3. IAM và Organization Policies (Chính sách Tổ chức)

6.4. IAM và Các Dịch vụ Khác của Google Cloud

Tóm tắt Phần 6:

Phần 7: Chuẩn Bị cho Kỳ thi Google Cloud Associate Cloud Engineer - Phần IAM

7.1. Các Chủ đề IAM Quan trọng nhất cần Nắm vững cho Kỳ thi

7.2. Các Dạng Câu hỏi Thường Gặp về IAM

7.3. Lời Khuyên Ôn Tập Hiệu Quả cho IAM

Kết luận: Nắm vững IAM