FAQ

This page gives quick answers about the CerberusD access model: how resources connect, what a person sees, how sessions open, how access closes, and which records remain. Longer explanations continue in the linked docs.

What access problem does CerberusD solve?

CerberusD turns access to existing computers, servers, terminals, and Kubernetes work surfaces into a resource-scoped operation. A person sees the assigned resource instead of broad network access; work opens through a session; access can be revoked; decision, closure, and evidence stay in one flow.

How is resource access kept scoped?

The daily user experience is not built around joining a broad private network. Resources stay behind controlled reachability, while the person sees only the assigned resource and the work surface that passed the session decision.

How is CerberusD different from screen-sharing tools?

Screen-sharing tools focus on opening a remote view quickly. CerberusD starts from the access decision: who is assigned, which resource is ready, how long the work can run, how access closes, and which evidence remains.

How does CerberusD govern RDP, SSH, and VNC?

CerberusD governs those paths as part of the product model. RDP, VNC, SSH, terminal, and suitable Kubernetes work paths can open through the browser or controlled private access. The launch decision, credential custody, closure, and evidence flow remain around the protocol.

How are resource ports kept out of the normal user surface?

The product model avoids making resource ports the normal user-facing access surface. A person works with an assigned session surface instead of a raw resource address and target password. Resource-network rules and agent or gateway health remain part of the operating model.

Where is the Windows Agent used?

For Windows resources, the Agent is the main path for machine readiness, health signals, local account behavior, and connection preparation. For non-Windows resources, the current model can use a gateway, Headscale/Tailscale-compatible private network, or manual resource definition. Native non-Windows agent scope is handled as a separate product direction.

Does Agent setup prepare the Tailscale client?

For resources that need private-network access, the Windows Agent setup flow can prepare the Tailscale client and bind network settings to the CerberusD operating model. That layer produces reachability; the session decision still comes from CerberusD assignment, policy, readiness, and record flow.

What does the private access layer do?

Private resources can use a dedicated access layer for reachability between CerberusD and the resource. That layer moves traffic. Authority still comes from the CerberusD decision model: identity, assignment, policy, session state, and audit record.

How does SSO become a complete access decision?

SSO proves who is signing in. CerberusD also evaluates workspace membership, role responsibility, resource assignment, readiness, duration, session policy, and record context. Authentication starts the access decision; the session decision completes it.

Which protocols are supported?

RDP, VNC, SSH, terminal, and Kubernetes work paths are part of the product model. Clipboard, file transfer, recording, reconnect, and observation scope can differ by protocol behavior and enabled features.

Is agentless access possible?

Yes, for suitable resources. In that model the target needs to be reachable through the managed access path or join the private network through a gateway. CerberusD manages resource definition, assignment, session decision, closure, and records; endpoint readiness signals may be less rich than a Windows Agent path.

Can a small team use it?

Yes. The smallest useful loop is one resource, one assigned person, one browser session, one closure event, and one record. The value grows as more resources, roles, and temporary access cases are added.

Can it run inside private networks?

Yes. CerberusD can be used inside private environments to keep access resource-scoped, identity-aware, and auditable even when resources are not public internet targets.

Does the user see the password?

The goal is to open the assigned session without handing the target credential to the person doing the work. Credential custody separates the visible access decision from secret storage and unwrap behavior. Local account, rotation, and secret infrastructure details follow the active service configuration.

What is the session lifecycle and video scope?

Access decisions, connection events, and closure records are part of the audit flow. Video session recording, playback, and export depend on deployment, policy, and product readiness; lifecycle records alone do not imply video evidence.

What happens when access is revoked?

Revocation closes the path for new sessions and leaves a closure record in the product model. How an active session ends depends on the protocol, gateway behavior, and active session policy.

How are CerberusD packages evaluated?

Packages are evaluated by concurrent active sessions, record retention, security, and support scope. The clearest starting point is which resources connect, who needs access, and which evidence level is expected.