You're developing the incident response plan for your company. You need to define the access strategy that your DevOps team will use when reviewing and investigating a deployment issue in your Google Cloud environment. There are two main requirements:
✑ Least-privilege access must be enforced at all times.
✑ The DevOps team must be able to access the required resources only during the deployment issue.
How should you grant access while following Google-recommended best practices?
To ensure least-privilege access and temporary access are both enforced, creating a service account with limited list/view permissions and then giving the Service Account User Role on this service account to the DevOps team is the best practice. This allows the team to utilize the service account only when needed during a deployment issue, and their access can be easily revoked afterwards. By granting roles to the service account rather than individual users, you maintain a higher degree of control and flexibility in managing access.
I think the answer should D. Option B gives them "Always On" permissions but the question asks for "Just in time" permissions. So, this is possible only with a Service Account. Once the incident response team resolves the issue, the service account key can be disabled.
You can create "Just in time" permissions with IAM conditions.
answer should be D
D. Create a service account, and grant it limited list/view permissions. Give the Service Account User Role on this service account to the DevOps team.
D is right
ans is D
I think its B, option D lacks Service Account Token Creator Role so the DevOps team can't impersonate the SA.
Should be D, as the service account user role can impersonate. Service Account User (roles/iam.serviceAccountUser): This role includes the iam.serviceAccounts.actAs permission, which allows principals to indirectly access all the resources that the service account can access. For example, if a principal has the Service Account User role on a service account, and the service account has the Cloud SQL Admin role (roles/cloudsql.admin) on the project, then the principal can impersonate the service account to create a Cloud SQL instance.
Too many ifs' bro with B as they said custom role we just put a condition to the role
Too many ifs' bro with B as they said custom role we just put a condition to the role
I will go to B, since only with custom roles you can have Least-privilege access enforced at all times. And you can create "Just in time" permissions with IAM conditions.
I go with B, if we consider D we need to assume too many things and B is simple custom role with JIT condition can address all the issues.
Between B and D, I choose D Because option B Granting IAM roles to the DevOps team directly would give them ongoing, not temporary, access.
B follows the google best practices
B or D, I prefer B because of traceability, impersonating an account is harder to audit in relation to using personal account.
B is more relvant
The real answer shouldn be 'breakglass' tool.
Answer should be B
Answer is B, it sets least-privilege access.
Its (D) according https://cloud.google.com/iam/docs/best-practices-service-accounts "Some applications only require access to certain resources at specific times or under specific circumstances....In such scenarios, using a single service account and granting it access to all resources goes against the principle of least privilege"
i vote B. Options A and C grant broader permissions than necessary, which does not align with the least-privilege principle. Option D involves using a service account, which is not the best practice for granting temporary access to human users. By creating a custom IAM role, you ensure that the DevOps team has the precise permissions needed for their tasks, and you can easily adjust or revoke these permissions as necessary
IAM role to DevOps team member is wrong - not fulfill least privilege principle Service account with "limited list/view permissions" to DevOps team member is correct - least privilege principle - more flexibility
B is right answer.
I go with D, While B seems to allows defining specific permissions, it adds complexity to the access control strategy and might still grant more access than necessary.
Any DevOps Engineer knows verywell, it is D
D. -Least Privilege: By creating a service account with restricted permissions (limited list/view access to specific resources), you adhere to the principle of least privilege. The DevOps team can only access the information needed for investigation without broader project-level control. -Temporary Access: Service accounts are not tied to individual users. Once the investigation is complete, you can simply revoke access to the service account from the DevOps team, effectively removing their access to the resources. This ensures temporary access for the specific incident.
D. This approach allows the creation of a service account with specific limited permissions necessary for investigating deployment issues. The DevOps team can then be granted the Service Account User role on this service account. This setup ensures that the DevOps team can use the service account with appropriate permissions only when needed, fulfilling both requirements of least-privilege access and temporary access
D. Create a service account, and grant it limited list/view permissions. Give the Service Account User Role on this service account to the DevOps team. This option allows you to create a service account with limited access rights (list/view), and the DevOps team will be able to use this service account only when needed. This is consistent with the principle of least privilege and incident-only access.
D. Create a service account, and grant it limited list/view permissions. Give the Service Account User Role on this service account to the DevOps team. This option allows you to create a service account with limited access rights (list/view), and the DevOps team will be able to use this service account only when needed. This is consistent with the principle of least privilege and incident-only access.
Why Option D is Best: Least-Privilege Access: Permissions are limited to only what is necessary for the investigation by tailoring the service account’s IAM role. Controlled Access: By managing the service account or its impersonation permissions, you can ensure the DevOps team can access the resources only during deployment issues.
It follows best practices and has traceability