Least-Privilege RBAC and Encryption Across Three Business Units
Fabrikam has three business units sharing one Prism Central that manages four clusters. Finance, AD group FIN-OPS, must see only its 40 VMs and cannot delete them. Audit, AD group AUD-READ, needs read-only visibility across all clusters plus audit log export. Contractors, AD group CTR-OPS, need console access to 10 development VMs but must not change power state or delete anything. Security has enabled cluster lockdown and requires data-at-rest encryption for Finance. A recent incident occurred when a contractor used a shared local Prism admin account to delete a development VM. The contractor also used that account to disable an alert.
1. Design the role, project, and identity model to meet these requirements. Be specific about what each group can and cannot do.
Read the worked answer
Use Prism Central projects, categories, custom roles, and AD group mapping rather than shared accounts.
- FIN-OPS. Create a Finance project scoped by a category such as BU=Finance. Assign a custom role that includes VM view, console, power operations if approved, and configuration changes, but explicitly excludes VM delete, project delete, and cluster settings. If Finance must not delete, do not give Project Admin; build a role from the minimum privilege set. Test that delete is denied at the API, not just hidden in the UI.
- AUD-READ. Assign a read-only role at the Prism Central level or across all four clusters, with audit log view and export. Do not give cluster admin. Confirm the role can read events and tasks but cannot mutate. Export should go to a controlled syslog or SIEM destination, not a local download by the auditor.
- CTR-OPS. Scope a Contractors project to the 10 dev VMs by category. Grant console access only; exclude power operations, delete, snapshot, and network changes. If console access inherently allows actions inside the guest OS, document that the guest OS itself must have separate controls; Prism RBAC cannot prevent in-guest changes.
- Identity. Map AD groups directly to Prism roles. Disable the shared local admin account and any other shared local accounts. Require named accounts, MFA through the identity provider, and session logging. Keep one break-glass local account with a sealed credential and alerting on use.
- Separation. Do not let the contractor group and the Finance group share a project. Do not grant cluster-wide roles to project-scoped users.
2. How do you enforce encryption for Finance and cluster lockdown without breaking normal operations?
Read the worked answer
Encryption and lockdown both fail if they are switched on without an operational plan.
Encryption. Nutanix data-at-rest encryption is configured at the cluster level with a key management server. You cannot encrypt only one project's VMs unless you use a separate cluster or a storage policy that supports the requirement. Decide first whether Finance needs a dedicated encrypted cluster or whether the whole cluster will be encrypted. If the whole cluster, plan the KMS integration, key rotation, and recovery process before enabling. Confirm the KMS is reachable from every node and that key availability survives a site failure. Test that a node reboot does not leave volumes inaccessible. Document who can administer keys; Prism admin should not automatically be a KMS admin.
Cluster lockdown. Lockdown enforces STIG-like controls and restricts SSH and console access. It can interfere with troubleshooting, LCM, and support workflows. Before enabling, verify the AOS version and LCM compatibility, confirm alternate support access, and document the temporary unlock procedure with approval and expiration. Do not let lockdown be disabled silently by an admin; alert on changes.
Operational safety. Stage both changes in a non-production cluster. Create a rollback plan for encryption (key escrow and recovery) and for lockdown (approved break-glass). Verify monitoring, backups, and DR still work after the change. If Finance encryption requires a separate cluster, treat it as a migration project, not a checkbox.
3. What controls prevent a repeat of the shared-admin deletion and alert-disabling incident?
Read the worked answer
The root cause is credential sharing plus excessive privilege, so technical and procedural controls must address both.
- Eliminate shared accounts. Disable the shared local Prism admin. Map contractors to individual AD accounts in CTR-OPS. If a vendor requires a service account, make it non-interactive, scoped, rotated, and monitored.
- Least privilege. The contractor role should not include delete, alert configuration, or cluster settings. Alert changes should require a separate operations role. Verify with negative tests: attempt delete and alert-disable as the contractor and confirm denial.
- MFA and conditional access. Require MFA for all interactive Prism logins, especially contractors. Restrict contractor access by network location or VPN if possible.
- Audit and alerting. Forward Prism audit logs to the SIEM. Alert on VM delete, alert configuration changes, local account use, and role changes. Review alerts weekly, not only after an incident.
- Break-glass controls. Any local administrative account should be sealed, checked out with approval, and generate an immediate alert. Log the session.
- Change management. Deletions in shared environments should require a ticket or approval. For dev VMs, use a soft-delete or snapshot policy where feasible.
- Contractor lifecycle. Set account expiry, require manager attestation, and revoke access automatically at contract end. Include contractors in access reviews.
- Incident follow-up. Confirm the deleted VM is recoverable from backup or snapshot, and document the recovery time. Use the incident to test whether the new controls actually block the same action.