Calm Automation and RBAC for an NC2 Burst Environment
A financial services firm runs an 8-node AHV cluster on premises and a 4-node Nutanix Cloud Clusters (NC2) environment in AWS us-east-1 for quarterly batch bursts. Both are registered to one Prism Central. Calm blueprints deploy a three-tier payments application. Active Directory groups are AppDev, CloudOps, and Security. AppDev must deploy only into a project named Payments-Dev with a quota of 40 vCPU and 160 GB memory, and must not see production workloads. CloudOps must manage clusters and NC2 lifecycle but should not read application data. Security must audit all actions and retain logs for one year. The NC2 cluster costs about $18,000 per quarter if left running and should be stopped outside burst windows. The firm wants automation for deployment and cost control without granting broad Super Admin rights.
1. Design the RBAC and project model. Specify AD group mappings, roles, scopes, and quotas, and explain how you prevent AppDev from seeing production.
Read the worked answer
Configure AD in Prism Central. Create project Payments-Dev and attach it only to the NC2 cluster (or the dev cluster), with quota 40 vCPU/160 GB. Map AppDev to the project-scoped Developer role (or a custom role that can launch blueprints and manage only project VMs); do not give cluster-wide Prism Admin. Use categories such as Environment:Dev and Project:Payments so blueprints and policies land in the right scope.
Map CloudOps to a cluster-scoped infrastructure role for NC2 lifecycle and cluster management, but not to the Payments project. Map Security to Prism Viewer plus audit-log access. Prevent AppDev from seeing production by not granting any cluster-wide or production-project role; projects and quotas do not by themselves hide all inventory if the user also has Prism Viewer. Test with a non-admin account: list VMs, try to deploy outside project, and confirm denial. Note that a hypervisor infrastructure admin can access VM disks; separation of duties and audit are required, not just RBAC.
2. Automate NC2 start/stop and Calm deployment. What can Calm do directly, what must be external, and how do you sequence to avoid failed deployments?
Read the worked answer
Calm can deploy the three-tier blueprint to the NC2 cluster once it is registered and healthy; it cannot start or stop the NC2 cluster itself because NC2 lifecycle is controlled from the NC2 console/AWS. Use external orchestration: an AWS EventBridge schedule or Lambda calls the NC2/AWS API to start the cluster at the burst window, waits for Prism Central to report the cluster healthy, then triggers the Calm blueprint/runbook. At the end, Calm deletes the application VMs after a backup/export, then external automation verifies zero project VMs and stops the NC2 cluster.
Sequence matters: never launch the blueprint while the cluster is stopped or still initializing. Put a pre-check task in the runbook for cluster health, Prism Central connectivity, and quota. Use idempotent scripts and tags so reruns do not create duplicates. Log every transition to SIEM. This separates app automation (Calm) from infrastructure lifecycle (NC2/AWS) instead of forcing Calm to do something it does not own.
3. Design audit and security controls for the blueprint, including secrets and logs, and define what to monitor for cost and compliance.
Read the worked answer
Store credentials in the Calm credential store or an external vault, not in blueprint text; use a least-privilege service account for NC2/Prism operations. Enable Prism Central audit logs to syslog/SIEM and retain 12 months; include blueprint launches, project/quota changes, role changes, failed logins, and NC2 start/stop events. Enforce AD authentication and a break-glass local account in the vault. Use project quota alerts at 80% and 100%. Tag NC2 resources for cost allocation.
Monitor: NC2 running hours versus the quarterly window, failed blueprint deployments, quota breaches, Super Admin use, and any AppDev access outside Payments-Dev. Review weekly. If CloudOps needs infrastructure access, accept that hypervisor admins can reach VM disks and compensate with audit, background checks, and separation from application credentials. This gives cost control and audit evidence without granting broad Super Admin.