Oasis Stack Oasis Stack A CloudHost Initiative
EN
Talk to us
Architecture · Security & sovereignty

How the platform
is secured.

Security in Oasis Stack is a layer every module honours, not a product bolted beside them. This page sets out what the platform enforces, who is responsible for what, and how to reach us about a vulnerability.

Talk to our team Compliance and evidence
Enforced before provisioningKeys inside your boundaryAuditable by default
One engine, every service
With the Governance, Security & Compliance module, identity, access and policy are applied to a VM, a cluster, a GPU job or a marketplace item identically.
Enforced, not reviewed
Policy is applied at order time, not discovered in an audit months later.
Custody stays yours
Keys and the boundary they protect are held where the operator decides, not where we do.
Everything leaves a record
Who ordered, approved, changed and accessed what — as an immutable trail.
Scope

The deployment and its infrastructure.

This page covers the security of the partner’s physical deployment: the platform and the complete infrastructure it runs on. What a customer runs inside its own tenancy is secured by that customer.

VirtueSuite
Identity and access management: LDAP, SAML, and single sign-on with Microsoft Entra and Google Workspace; privileged access and key custody controls.
Observa
Monitoring and observability across the infrastructure, with its health, performance and security signals.
Oditr
Compliance as a service: controls checked and evidenced continuously.
Third-party controls
Where a deployment needs additional third-party security controls, they are integrated and supported on request, as additional scope.
Shared responsibility

Three parties. Clear lines between them.

Incidents tend to happen where each party assumed the other was covering it. CloudHost can appear in two roles: as the platform vendor, and as the operator when you choose to have CloudHost run the platform. What the admin centre can reach is set out below. This is where the lines actually fall.

Oasis Stack
secures the platform
The security of the platform code and its releases
The identity, policy and audit engine every module honours
Encryption in transit and at rest as a platform function
Vulnerability handling and security fixes in the product
The operator
secures the cloud
The infrastructure, the sites and the physical security around them
Key custody and where keys are held
Who is granted access, and to what
The certification of their own deployment
The customer
secures their tenancy
What they put in the cloud and how it is classified
Their own users, roles and credentials
The configuration of the services they order
Their obligations to their own regulator
What the platform enforces

The same controls, everywhere they apply.

These are functions of the platform, which is why they reach a marketplace listing as readily as a virtual machine.

Identity
Your directory, your credentials, your authentication decisions — federated where you choose. Through VirtueSuite: LDAP, SAML, and single sign-on with Microsoft Entra and Google Workspace; local and national identity providers are integrated per region, as part of the deployment setup.
Access
Role and attribute-based access applied per tenant, project and environment.
Encryption
In transit and at rest, with key custody held inside the boundary the operator defines.
Policy
Guardrails applied before provisioning: regions, sizes, images, spend and data classes.
Audit
An immutable record of who ordered, approved, changed and accessed what.
Monitoring
Platform signals watched continuously, with Amin surfacing drift and exposure.
Hardening
Baselines applied to the services the platform provisions, not left to each team.
Incident response
Detection, alerting and defined escalation paths between operator and platform.
Keys and data

Custody is the part that cannot be delegated.

A cloud is only as private as the answer to one question: who can decrypt it. Oasis Stack is built so that the operator holds that answer — key custody, the location of the data and the identities that unlock it all sit inside the boundary the operator defines. Keys are held locally in each deployment; custody is the operator’s decision, and the admin centre link does not carry them.

The seven layers of sovereignty
Keys stay in the boundary
Custody sits with the operator, under the jurisdiction they operate in.
Data movement is a decision
Nothing moves between zones or between federated clouds as a default behaviour.
Workloads do not depend on us
Running workloads do not depend on a connection to CloudHost. The admin centre link carries licences, releases, central service management and the financial and contractual transactions between locations.
The admin centre

What CloudHost can reach, and why.

Transparency starts with the vendor. Each deployment, except an air-gapped one, has a backend link to the Oasis Stack admin centre, hosted by CloudHost across multiple locations in redundancy.

What the link is for
Platform licences, installing modules, rolling out signed version upgrades with a software bill of materials, central service management, and the financial and contractual transactions between locations and clouds, through the Oasis Federation Core. Actions for services offered in the federation are not approved one by one, so federation service levels can be met.
What it does not carry
Your workloads or their data. They run on your infrastructure and keep running if the management plane is unavailable. Keys, identity, Amin and Noura run locally, in the deployment.
What you decide
Key custody, who is granted access, and what your cloud publishes to others stay with the operator. Upgrades can be deferred, and refused by a deployment outside the federation network; a deployment in it cannot refuse them.
Sovereignty controls

Residency is one question. Sovereignty is seven.

Data, infrastructure, operations, identity, security, governance and technology: each layer of control is held locally, shared under agreement, or delegated. It is a decision, not a setting.

DataInfrastructureOperationsIdentitySecurityGovernanceTechnology
The seven layers, and how each is verified
What comes with what

Oasis Core, and the Governance module.

Every deployment has the controls in Oasis Core. The Governance, Security & Compliance module adds more, when a deployment adopts it.

In every deployment
Oasis Core: sign-in, permissions and governed workflows, tenancy with quotas and isolation, and the local federation connection.
With the Governance module
Policy evaluated before provisioning, the audit trail, threat detection, privileged-access controls and HSM-backed key custody — through VirtueSuite, Observa and Oditr, with keys and secrets managed by OpenBao.
Air-gapped deployments
Licences, updates and patches are carried in by Oasis Stack team members, on USB or as encrypted files, and VirtueSuite, Observa and Oditr run fully inside the deployment. There is no federation and no link to the admin centre. Data moves between classification levels only through workflows configured at deployment, to the programme’s rules and permissions.
Reporting a vulnerability

Tell us, and we will tell the operators.

If you believe you have found a security issue in Oasis Stack, we want it before anyone else does.

How to reach us

Send it through the contact page with “Security report” in the subject. We will acknowledge it, tell you what we find, and coordinate the fix with any operator affected.

If you would rather use a dedicated address or encrypt the report, ask and we will arrange it.

What we ask
Report privately first, before any public disclosure
Give us enough detail to reproduce it
Do not access, alter or exfiltrate anyone else’s data while testing
Do not run tests that degrade a live operator’s service

Operators run their own deployments, so an issue in a specific cloud should also go to that operator. We coordinate the fix across the platform.

Who builds what

Built in-house. Extended with alliances.

The controls are enforced by the platform. The hardware and records they rely on come from where you already hold them.

Built in-house
  • One identity, policy and audit engine every module honours
  • Policy evaluated before provisioning
  • The two-person rule and session recording on privileged actions
CloudHost products, integrated
  • VirtueSuite — identity and access management
  • Observa — monitoring and observability
  • Oditr — compliance as a service
Built with alliances
  • HSM-backed key custody, powered by OpenBao secrets management
  • The directory and national identity provider you already run
  • Security event and configuration records, through the REST API
How alliances join
Secure. Compliant. Auditable.

Bring your security team.

We will walk the control model, the responsibility split and the evidence trail against your own framework.

Talk to our team Compliance and evidence