The SC//HyperCore™ HyperVisor has one admin surface, and it is kept narrow on purpose. That surface is an HTTPS web interface and a REST API, and both are protected by authenticated user accounts. There is no general-purpose shell, no SSH service for admins to harden, and no external management server to attack. This page explains how authentication, role-based access, and audit logging work together to keep cluster access in your hands.
HTTPS access and certificates
You reach the SC//HyperCore cluster in a browser over HTTPS. The SC//HyperCore web interface ships with a default certificate. You can also use your own certificates to match your company’s PKI. All admin traffic uses the same authenticated, encrypted channel. That includes the REST API used by automation and third-party integrations.
Management is built into the cluster itself. So you don’t need to deploy or maintain a separate management server, controller VM, or “external brain” to control the cluster. The cluster is a secure, self-contained appliance.
Authentication
Only authenticated user accounts can access the web interface and REST API. You can manage accounts in either of two ways:
- Local accounts kept on each cluster, useful for small sites or for break-glass cases.
- OpenID Connect (OIDC) Single Sign-On integration, which extends SC//HyperCore authentication to a central identity provider.
OIDC integration supports providers such as Microsoft Entra ID (formerly Azure AD) and ADFS. When you use OIDC, the identity provider can enforce more access policies. These include multi-factor authentication (MFA), conditional access, session policies, and password rules. Role assignments on the cluster can then come from group membership or other attributes in the central directory. You don’t have to keep them up to date on each cluster.
See Single Sign On for SSO setup steps. See User Access Control for a full list of what each built-in role can and can’t do.
Role-Based Access Control (RBAC)
SC//HyperCore Role-Based Access Control (RBAC) lets you limit user accounts to a specific set of tasks and actions. Common patterns include:
- Read-only accounts that allow view and monitoring access to the web interface and REST API only. They can’t create new VMs or change existing VMs or cluster settings.
- Backup-purpose accounts used with third-party backup products (for example, Acronis) that connect to the cluster through the API.
- Operator accounts scoped to power controls, VM lifecycle, or cluster configuration changes, without full admin rights.
Combine RBAC with OIDC group-based assignment to set your access model as policy in your identity provider. That model might use least privilege, separation of duties, or on-call elevation. You then avoid one-off local settings on each cluster.
Audit logging and SIEM integration
The SC//HyperCore cluster log records security events and system actions. You can send the cluster log to outside systems in two ways:
- Syslog export to a central log aggregator.
- REST API access for security information and event management (SIEM) tools, for central analysis, alerting, and long-term retention.
So the events you use to run the cluster are also open to your security operations team. They include admin logins, configuration changes, VM lifecycle actions, replication status, and so on. The team can use them for monitoring, alerting, and audit evidence.
Self-contained, autonomous operation
To access or control the cluster across a network link, the SC//HyperCore software needs no external management server, controller VM, or other outside dependency. That makes the access model itself more resilient. All cluster management, monitoring, and access happen in web interfaces built into the software itself.
Because it runs on its own, the cluster keeps healing itself and keeps data and applications available. This holds even when the link to SC//Fleet™ Manager is down. It can also send tightly scoped, efficient updates to SC//Fleet Manager without depending on it for ongoing control. The result is an access model that is simple to understand and audit. It keeps working correctly even when the network is degraded.