Skip to content
Console

Security model

Security on SdV Cloud works at three levels: proving who you are, controlling what you can do once you’re in, and keeping tenants’ running workloads apart from each other.

Signing in proves you’re you. On top of a password, an organization can require two-factor authentication (2FA) — a code from an authenticator app — before anyone can sign in. This can be turned on for an entire organization at once: everyone without 2FA confirmed gets notified and is required to set it up before continuing to use the account.

2FA protects the sign-in step. It doesn’t change what you can do once you’re in — that’s governed by roles, covered in Organizations and projects.

Every action — viewing a project, triggering a deployment, inviting a teammate — is checked against your role in the organization and, where relevant, the project. Roles are the only mechanism for granting or restricting access; there’s no separate permissions list to manage on top of them.

Each organization’s service containers run apart from every other organization’s. A running service container can reach the public internet and other service containers within its own project, but not other organizations’ service containers, and not SdV Cloud’s own internal infrastructure. This is a structural boundary, not just a permission check.

This means that even if your organization’s application has a vulnerability, it can’t be used as a stepping stone into another tenant’s workloads or into SdV Cloud’s own infrastructure.