Skip to content

Background

Shared responsibility

Breqwatr runs the cloud. You run what you put on it. Breqwatr looks after everything underneath your instances, and you look after everything inside them, plus how you set up the cloud services you use.

Where the line sits

On a traditional platform, one organisation owns every layer: the building, the hardware, the hypervisor, the operating systems and the applications. On an infrastructure as a service cloud such as Breqwatr Cloud, the provider takes the lower layers and you keep the upper ones. Some layers in the middle are shared: Breqwatr supplies the tool, and you decide how to use it.

Layer Breqwatr You
Data centre facilities: power, cooling, physical security Runs
Physical servers, storage hardware and network fabric Runs and replaces
Cloud platform: the software that runs instances, volumes, networks and load balancers Runs, upgrades and patches
Cloud APIs and the Breqwatr Cloud Portal (Strata) Runs and releases updates Uses
Public images Provides Chooses one, and keeps the operating system patched after launch
Guest operating system, Windows or Linux Updates, hardens and configures
Applications and middleware Installs, configures and patches
Your data Stores on the platform Owns, protects, backs up and controls access to
Identity and access Provides MFA (mandatory for every account), roles and application credentials Manages members, roles and credentials, and rotates credentials
Network access Provides networks, routers, security groups, floating IPs and load balancers Decides what is reachable, from where
Backup and recovery Provides volume snapshots and backups Decides what to protect and how often, and tests restores
Software licences Provides Windows Server images with the licence included, and other licensed operating system images on request Licenses the software you install
BKS management cluster, which provisions BKS clusters Runs
BKS clusters: control plane, worker nodes and workloads Own the whole cluster, control plane and worker nodes included, and everything running on it

BKS is not managed Kubernetes. Breqwatr runs the management cluster that creates BKS clusters. Once a cluster exists, all of it is yours, including its control plane.

How Breqwatr keeps the platform current

Breqwatr applies platform releases to every deployment itself, so there is nothing on the platform for you to upgrade.

  • Releases are regular and scheduled, each carrying a small set of changes. The release model describes how they're made.
  • Fixes ship in the next release rather than being back-ported, so no deployment is left on an unsupported version.
  • Every change is peer reviewed, security reviewed and tested automatically before release. Third-party dependencies are scanned for known vulnerabilities and upgraded monthly, and independent penetration tests run periodically.
  • On the public cloud, Breqwatr upgrades to each release. Private hosted and on-premises deployments are upgraded quarterly, or on request.

What this does not cover is the operating system inside your instances. A platform release does not patch Windows or Linux on an instance; that stays with you.

When Breqwatr support needs access

Breqwatr support does not sign in to your account by default. If you're working through a problem with support, you can grant access to your account for one hour, 24 hours or seven days from your profile, and turn it off at any time. Each support sign-in is recorded in your organisation's audit log.

Deployment models

The table above describes the Breqwatr public cloud. Private hosted and on-premises deployments follow the same split for the platform software, which Breqwatr still runs and upgrades. Who owns the facilities and hardware can differ, and your agreement with Breqwatr sets that out.

Impact

  • Your team no longer owns hardware refresh, hypervisor patching or platform upgrades.
  • Your team still owns everything inside each instance. Moving a workload to the cloud does not change who patches it.
  • Security is shared in practice, not just on paper. MFA, roles, security groups and the audit log protect a workload only when they're set up for it.

Common anti-patterns

  • Assuming the provider backs up your data: Breqwatr provides snapshot and backup tools. Deciding what to protect, and checking that a restore works, sits with you.
  • Assuming the provider patches the guest: a public image is patched when it's published. From the moment an instance boots, its operating system updates are yours.
  • Open by default: security group rules that allow RDP or SSH from anywhere, added to get something working and never narrowed.
  • One credential for everything: a single application credential shared by several people and tools. Nobody can tell who made a change, and revoking it stops everything at once.

Further reading