An organization is analyzing its automated continuous deployment pipeline, which uses Cloud Build to deploy microservice updates to a Google Kubernetes Engine (GKE) cluster and store images in Artifact Registry. An architecture review reveals that the pipeline currently uses the default Cloud Build service account with broad broad-spectrum project access, violating security compliance guidelines. Which IAM configuration strategy should the cloud architect recommend to secure the CI/CD pipeline while adhering to the principle of least privilege?
- Configure Cloud Build to execute using a dedicated user-managed service account, and assign only granular predefined roles such as Kubernetes Engine Developer for GKE deployments and Artifact Registry Writer for container image uploads.Cevap
- BAssign the primitive Editor role to the default Cloud Build service account at the organization node to ensure all present and future build steps execute without permission failures.
- CGrant the Service Account Admin role to the development team submitting builds so that Cloud Build can dynamically elevate permissions during deployment execution.
- DStore deployment release configurations and environment state files locally inside the Cloud Build workspace directory to bypass project-level IAM authorization checks.
Cevap
Configure Cloud Build to execute using a dedicated user-managed service account, and assign only granular predefined roles such as Kubernetes Engine Developer for GKE deployments and Artifact Registry Writer for container image uploads.
Configuring Cloud Build to run as a user-managed service account with fine-grained roles (Kubernetes Engine Developer and Artifact Registry Writer) follows Google Cloud security best practices. It ensures the pipeline has necessary operational privileges for GKE deployments and artifact pushes while restricting unnecessary project-level access.
Adım Adım Çözüm
Anahtar Kavram
CI/CD Pipeline Security and Service Account Governance in GCP