Tasmanian Cloud documentation
Security services
Security boundaries and access controls for Tasmanian Cloud workloads
This page describes the security boundaries used by Tasmanian Cloud. It does not claim ISO certification, an SLA, or a 24/7 support service.
The access boundary
Management traffic MUST use an authenticated private path. SSH, database administration, cluster control, runner configuration, and operator interfaces MUST NOT be reachable on a public IP for normal operation.
The managed default uses a zero-trust mesh. Customer-owned mesh options and an audited bastion path can be used where they fit the customer environment.
Three checks
Access is layered:
- the peer joins an authenticated mesh
- mesh ACLs decide which identity can reach which deployment
- the workload or service performs its own authentication
Joining the mesh is not permission to reach every service. A bastion grant can narrow access to a specific deployment and port.
Secrets and capabilities
Kleis carries encrypted references and scoped expressions. A workflow can request an operation without copying a provider token, database password, webhook key, or mail credential into every template and .env file.
Dialkeys provide service identity and discovery. They help a permitted system find a service. They do not replace tenant authorisation.
Events and evidence
Resource changes, deployment runs, access decisions, webhook deliveries, and patch findings can be represented as state and events. Customers can use those events to connect the platform to their own audit, remediation, and incident workflows.
Customer responsibility
Customers remain responsible for application configuration, guest operating system state, credentials they manage directly, data retention decisions, and access granted inside the workload. Patch reports describe observed package state. They do not certify that a workload is secure.