Soru

Zorluk: ZorIdentity and Access Management (IAM) Roles and Resource Hierarchy

An automotive IoT company structures its Google Cloud resource hierarchy with an Organization node containing an Autonomous Vehicles folder. Within this folder are two projects: telemetry-ingest, which hosts automated telemetry processing microservices on Compute Engine, and telemetry-storage, which contains a centralized Cloud Storage bucket for long-term diagnostic logs. The ingestion microservice requires read-only access to objects in the centralized bucket. Additionally, developer identity group members need to launch compute instances that execute as the ingestion service account without gaining administrative control over service accounts. Following Google-recommended security practices of least privilege and resource hierarchy management, which set of role assignments should you configure?

  1. Grant Storage Object Viewer (roles/storage.objectViewer) on the centralized bucket to the ingestion service account, and grant Service Account User (roles/iam.serviceAccountUser) on the ingestion service account to the developer identity group.Cevap
  2. B
    Grant Editor (roles/editor) at the Autonomous Vehicles folder level to the ingestion service account, and grant Service Account User (roles/iam.serviceAccountUser) at the telemetry-ingest project level to the developer identity group.
  3. C
    Grant Storage Object Admin (roles/storage.objectAdmin) on the telemetry-storage project to the ingestion service account, and grant Service Account Admin (roles/iam.serviceAccountAdmin) on the ingestion service account to the developer identity group.
  4. D
    Grant Storage Admin (roles/storage.admin) at the folder level to the ingestion service account, and rely on IAM permissions alone to restrict data copying outside the organization without perimeter controls.

Cevap

Grant Storage Object Viewer (roles/storage.objectViewer) on the centralized bucket to the ingestion service account, and grant Service Account User (roles/iam.serviceAccountUser) on the ingestion service account to the developer identity group.
The correct solution follows the principle of least privilege by binding the fine-grained predefined role 'Storage Object Viewer' directly to the destination Cloud Storage bucket rather than inheriting broad permissions from a project or folder level. Furthermore, granting 'Service Account User' specifically on the service account resource permits developers to bind the identity to instances without granting administrative privileges over service account management.

Adım Adım Çözüm

1
Determine the minimal required role for reading Cloud Storage objects.
Identify roles/storage.objectViewer as the predefined role granting read access to bucket objects without administrative privileges.
Principle of least privilege requires avoiding broad primitive roles (Editor/Owner) or administrative roles (Storage Admin).
2
Determine the resource hierarchy scope for the bucket access.
Apply the IAM binding directly on the centralized Cloud Storage bucket rather than at the project or folder level.
Inheritance down the resource hierarchy means folder- or project-level roles apply to all storage resources within those containers.
3
Identify the required IAM role for attaching a service account to Compute Engine instances.
Select roles/iam.serviceAccountUser bound directly to the target service account resource.
Developers require the ability to run instances as the service account without needing administrative control (roles/iam.serviceAccountAdmin) over service account lifecycles.

Anahtar Kavram

Fine-Grained IAM Scoping and Service Account Impersonation via Resource Hierarchy
Bu soruyu puanla