Least-Privilege Console Access for a Project Contractor
Prism Central manages three AHV clusters with 180 VMs. Categories are applied as Project=Atlas and Project=Borealis. A contractor supporting Atlas needs console access to 15 Atlas VMs and read-only access to alerts. The contractor must not see Borealis VMs, storage, or network policies. Today the contractor is in an AD group assigned the built-in Prism Viewer role globally, so the contractor can see every VM. The security team requires least privilege and quarterly access recertification. The platform team has Prism Central RBAC available and directory services integrated. There are 5 VMs in Atlas with no category, and 2 Atlas VMs also carry Project=Borealis due to a tagging mistake. The contractor starts Monday. No local Prism Central users are allowed by policy.
1. Why is the current built-in Prism Viewer assignment unacceptable, and what is the least-privilege design?
Read the worked answer
Reasoning: The built-in Viewer role is assigned globally, so it grants visibility across all three clusters and both projects. That violates the requirement that the contractor not see Borealis VMs, storage, or network policies. The replacement should be a custom role containing only the permissions the contractor needs, such as VM view and console access plus read-only alert visibility, assigned at a category scope for Project=Atlas.
Use the existing AD group, not a local user, and remove the global Viewer assignment. Category scope only works if every intended VM is labeled correctly, so the tagging defects must be fixed before access is granted. The design should fail closed: an uncategorized VM should not become visible through an overly broad fallback role.
2. How would you handle the 5 uncategorized Atlas VMs and the 2 cross-tagged VMs before granting access?
Read the worked answer
Reasoning: Do not grant access while the category model is inconsistent. The 5 uncategorized VMs might be invisible under a category-scoped role, which could break support, or they might be exposed if a broad role is used as a workaround. The 2 VMs tagged both Atlas and Borealis are worse: a Project=Atlas scope could expose a Borealis-tagged workload, or a future Borealis policy could affect an Atlas VM.
Correct the data first. Identify owners, apply Project=Atlas to the intended VMs, and remove the incorrect Borealis tag after confirming the workload's real project. Re-run a query or API report to prove every Atlas VM has exactly one correct project category and no Borealis overlap. Then test with a non-production account before the contractor starts. Document the cleanup as part of the access request.
3. How would you verify and recertify the contractor's access?
Read the worked answer
Reasoning: Verification should be evidence-based, not just a role assignment screenshot. Sign in as a test account in the same AD group and confirm the contractor can see and console to the 15 Atlas VMs, cannot see Borealis VMs, and cannot modify storage or network policies. Review Prism Central audit logs for the test actions.
For recertification, tie the review to AD group membership and the category scope, not to an individual user's memory. Each quarter, confirm the contractor still supports Atlas and that the 15 VM list is current. Remove access when the engagement ends, and check for stale group membership. Also verify that no local Prism Central account was created as a workaround, because policy forbids it.