Nutanix NCP-NS study materials
Nutanix NCP-NS study resources

Nutanix NCP-NS cheat sheet

Nutanix NCP-NS · Keep the key ideas within reach.

Quick reference

Security Fundamentals and Nutanix Security Architecture

  • Nutanix AOS runs on AHV (a KVM-based hypervisor) with one Controller VM (CVM) per node; security-relevant services run in the CVM, the AHV host, and the Prism management plane.

  • Nutanix separates three layers: management plane (Prism UI/API), control plane (CVM services such as Stargate), and data plane (AHV hosts and local disks); a control must be applied and audited at the correct layer.

  • Flow Network Security is a distributed firewall enforced inside AHV's Open vSwitch at each VM's virtual NIC, so filtering happens on the host before packets reach the guest.

  • Categories are key:value labels attached to VMs and are the scoping primitive shared by Flow policies, protection policies, and category-scoped RBAC roles.

  • Prism Element manages a single cluster; Prism Central provides multi-cluster services including Security Central, Flow policy authoring, protection policies, and global RBAC.

  • Security Central in Prism Central aggregates posture and compliance findings for registered clusters and surfaces drift from hardening baselines.

  • Cluster Lockdown restricts CVM SSH and API access to an IP allowlist and is a baseline hardening step; it does not replace Prism RBAC.

  • Every administrative and API action is written to the Prism audit log with user, timestamp, operation, and target resource.

  • Default local admin accounts should be superseded by directory- or SAML-backed RBAC, with local accounts held only as break-glass.

Quick reference

Identity, Authentication, and Access Control (Directory Services, RBAC, SAML/SSO)

  • Supported authentication sources are local Prism users, an Active Directory/LDAP directory, and SAML 2.0 single sign-on; a Prism Element cluster is bound to one directory at a time.

  • In SAML SSO, Prism is the service provider: the identity provider authenticates the user and asserts identity, and Prism then authorizes that identity through its own role assignments.

  • An RBAC assignment is the combination of principal (user or group) + role (permission set) + scope; scope is either global or limited to VMs matching specified categories.

  • Built-in roles follow least privilege tiers, for example a full administrator role, an operator role for limited operations, and a read-only viewer role for auditors.

  • Roles should be mapped to directory groups rather than individual accounts so that joiners, movers, and leavers are handled by directory membership.

  • SAML-authenticated users do not need matching local Prism accounts; local accounts remain only for break-glass when the IdP or directory is unreachable.

  • Permission checks are enforced by Prism for all interfaces, so nCLI, REST API, and UI calls are subject to the same RBAC evaluation.

  • Accounts used for automation should be dedicated service accounts with the narrowest role and scope that still satisfies the integration.

  • Local account policy (password complexity, session timeout, lockout) is configured per cluster and should be reviewed during hardening.

Quick reference

Network Segmentation and Flow Network Security Policy Design

  • Flow Network Security uses a whitelist model: once a VM is in scope of an enforced policy, all traffic not explicitly allowed is dropped.

  • Policy anatomy is scope (categories) + source/destination (categories, address groups, service groups) + application/port + action (allow or deny).

  • An isolation policy denies all traffic to and from the scoped VMs except explicit exceptions and is the standard mechanism for quarantining a suspected-compromised workload.

  • Isolation policies take precedence over application (microsegmentation) policies, so a quarantined VM cannot be re-opened by a broader allow rule.

  • New policies can be published in monitor mode first to log would-be allowed and denied flows; review Flow hitlogs and visualization before enforcing.

  • Category-based scoping means the policy follows the VM through IP address changes and migrations, unlike VLAN or static ACL-based segmentation.

  • Distributed microsegmentation with Flow requires AHV; workloads on other hypervisors are not protected by the AHV-enforced distributed firewall.

  • Service groups hold reusable port/protocol sets and address groups hold reusable IP sets, so a port change is made once and inherited by all referencing policies.

  • Flow hitlogs record source, destination, port, action, and timestamp per matching connection, and can be forwarded to a syslog collector for retention.

Quick reference

Data-at-Rest Encryption and Key Management

  • Native data-at-rest encryption (DARE) encrypts cluster disk data with AES-256 in XTS mode at the AOS storage layer, transparently to guest VMs and their file systems.

  • DARE requires a key management server; the cluster stores only wrapped data encryption keys and never persists plaintext keys on disk.

  • Key management is KMIP-based, so external KMIP servers (for example Thales, Fortanix, or Utimaco) or a Nutanix-provided key server can be used.

  • If the KMS is unreachable, running nodes continue with cached keys, but a node that reboots may be unable to unwrap its keys and may fail to come online.

  • Encryption is configured per cluster; a healthy cluster is a prerequisite and enabling encryption on existing data is a background re-encryption operation.

  • Self-encrypting drives can be used in addition to software encryption; their drive keys are also managed through the key management server.

  • Key rotation is initiated from the key management side; superseded keys must be retained until data written under them has been re-encrypted or deleted.

  • DARE protects data on disk only; replication traffic and backups need separate protection such as encrypted links, VPNs, or encryption enabled at the target.

  • Losing access to the key management server permanently means the encrypted cluster data is unrecoverable, so key backup and KMS redundancy are mandatory design elements.

Quick reference

Cluster Hardening, Certificates, and Trusted Boot/Secure Boot

  • Cluster Lockdown restricts CVM SSH and API access to an explicit IP allowlist; enable it only from a known-good management network so the cluster is not locked out.

  • TPM 2.0 measured boot records boot measurements in platform configuration registers; attestation compares them to expected values and reports tampering.

  • UEFI Secure Boot validates bootloader and kernel signatures on AHV hosts and can be enabled individually for guest VMs that support it.

  • Prism and CVM certificates are self-signed by default; replace them with CA-issued certificates and import the issuing chain into the cluster trust store so nodes trust each other.

  • Prism Central maintains its own certificate separately from the certificates of the clusters it manages; both must be replaced and tracked for expiry.

  • Reduce attack surface by disabling or restricting unused services such as outbound telemetry (Pulse) and by pointing SNMP and syslog at internal collectors.

  • Enforce local account password complexity, session timeout, and account lockout, and disable or tightly scope local accounts once directory or SAML auth is in place.

  • Run NCC (Nutanix Cluster Check) and LCM regularly to detect configuration drift and to stay current on AOS/AHV security fixes.

  • Nutanix publishes security configuration guides mapping cluster settings to CIS-style and STIG-style controls; Security Central reports drift from those baselines.

Quick reference

Security Monitoring, Auditing, and Compliance Reporting

  • The Prism audit log captures user, timestamp, operation, and affected resource for every management and API action, and is the primary evidence for access reviews.

  • Configure external syslog collectors in Prism to forward audit, alert, and system logs, because on-cluster retention is bounded and insufficient for long-term audit.

  • Alerts must be routed: configure SMTP for email notification and SNMP traps for the monitoring platform, with severity thresholds matched to escalation policy.

  • Flow hitlogs provide network-level evidence of allowed and denied connections, complementing the administrative audit trail.

  • Security Central findings and compliance dashboards provide posture evidence against hardening baselines and can be exported for auditors.

  • Nutanix Files auditing (Data Lens) exports file-level access events to syslog or object storage for regulated data sets.

  • All CVMs and hosts must synchronize to consistent NTP sources; clock skew invalidates certificate checks and breaks cross-system log correlation.

  • Correlating audit records requires consistent identity naming, so directory- or SAML-backed accounts are preferable to shared local accounts.

Quick reference

Workload and Data Protection Security (Replication, Backup, Recovery)

  • Protection domains (Prism Element) and protection policies (Prism Central, category-scoped) define snapshot and replication schedules, which in turn set the achievable RPO.

  • Asynchronous replication is the default DR mechanism; NearSync provides a much shorter RPO by scheduling frequent snapshots to the remote cluster.

  • Metro Availability uses synchronous replication across a stretched cluster to deliver a zero RPO, at the cost of requiring low-latency links between sites.

  • Snapshots are point-in-time and immutable while retained; for ransomware and regulatory resilience, use immutable/WORM retention where the workload supports it.

  • Nutanix Leap recovery plans orchestrate failover in Prism Central and can be validated with a non-disruptive test run that powers on VMs at the target site.

  • Data-at-rest encryption does not protect replication streams or backup payloads in transit; use encrypted links, VPNs, or encryption enabled at the target.

  • Snapshot and protection-policy deletion is a privileged, destructive action and must be restricted by RBAC role and scope to a small administrator group.

  • Backup integrations (Nutanix Mine and third-party agents) should be tested with periodic restores, not just successful job completion, to prove recoverability.

  • Remote clusters used for replication must be registered and trusted in Prism, and their own hardening, certificates, and encryption settings must match production standards.