Security, User Management, and Auditing
This domain tests least-privilege access across two planes: the NDB control plane (who can provision, clone, or delete) and the database engine plane (who can read or change data). Auditing must cover both.
Rules
- NDB authenticates users through local accounts or directory services such as LDAP/Active Directory, then applies role-based access control scoped by project and entity.
- Built-in roles follow a hierarchy: Viewer for read-only visibility, Operator for lifecycle actions, Admin for configuration and user management. Confirm exact role names in your release.
- Database users are separate. An NDB Operator does not automatically get database DBA rights, and a database DBA does not automatically get NDB Admin rights.
- Encryption at rest is provided by the Nutanix platform; TLS protects client and API traffic. Audit logs must be retained according to policy.
Worked example
A contractor needs read-only access to one database's performance data but must not see other projects or change data. Assign a Viewer role scoped to that project, not a global Admin role, and do not create a database user. Reasoning: the requirement is control-plane visibility, not data access. Project scoping limits blast radius; Viewer prevents lifecycle changes. Enable and retain NDB audit logs so the access can be reviewed later.
Traps
- Granting Admin or DBA for convenience.
- Using shared service accounts with no individual attribution.
- Disabling audit logging to improve performance.
- Assuming NDB roles grant database object privileges.
- Forgetting that clones inherit data and may expose production data to test users.