Background

Security and sovereignty¶

Security is about making sure only the right people and systems can reach a workload and its data, and that the layers you own are kept protected. On Breqwatr Cloud, the platform gives you the controls; using them well is your part.

What the pillar covers¶

Security covers identity (who can act), access (what they can reach), the network (what traffic gets through), the systems you run (patched and hardened), and traceability (being able to tell what happened). Shared responsibility sets out which of these Breqwatr runs and which are yours.

Design principles¶

Principle	What it means in practice
Strong identity	Every person signs in as themselves, with MFA. Every tool has its own credential
Least privilege	People and tools get only the access their job needs, and lose it when the job ends
Minimal exposure	Nothing is reachable from the internet unless it has to be, and then only on the ports it needs
Defence in layers	No single control is relied on alone: identity, network rules and the guest's own firewall each limit what an attacker can do
Patch what you own	Operating systems and applications inside instances are kept current, or rebuilt from current images
Keep secrets out of code and images	Passwords and keys are supplied when needed, not stored where many people or instances can read them
Trace activity	Changes can be tied to a person or tool, and reviewed after the fact

What it looks like on Breqwatr Cloud¶

Identity and access¶

MFA for every account. Every Breqwatr Cloud account enrols in MFA at sign-up, using an authenticator app.
Roles. Each person in an organisation is a member, an org admin or the org owner. Members work in a project: they create, change and delete its resources, but can't change the project itself, such as its settings or membership. Org admins manage projects and people. The org owner can also change roles and transfer ownership.
Per-project access. An organisation can limit which projects each member can see, so people work only where they need to.
Application credentials. Tools such as the OpenStack CLI, OpenTofu and Ansible sign in with an application credential, not a person's password. Use restricted credentials, which is the default, give each tool or pipeline its own, and set an expiry where it fits: 30 days, 90 days or one year. Revoke a credential when the machine or pipeline that used it is retired.

Network exposure¶

Security groups allow traffic in only on the ports and from the sources you choose. Narrow sources beat wide ones: an office address range for RDP or SSH, not the whole internet. Networking model explains how they work.
Floating IPs make an instance reachable from the internet. Instances that only serve other instances don't need one.
Administrative access can go through a single controlled entry point instead of exposing every instance: a bastion host, or a WireGuard or OpenVPN instance that you run yourself.

Patching your own instances¶

Breqwatr keeps the platform patched. The operating system inside each instance is yours to keep current, on Windows and Linux alike.

	Windows	Linux
Install updates	Windows Update, or your own update service	The distribution's package manager, such as `apt` or `dnf`
Automate it	Group Policy or configuration management such as Ansible	Unattended upgrades or configuration management such as Ansible
Replace rather than patch	Build new instances from a current image and retire the old ones	Build new instances from a current image and retire the old ones

Rebuilding from a current image is often the cleanest way to patch, because the new instance has no leftovers from earlier changes. See Pets vs cattle.

Traceability¶

The audit log records changes to members, roles, projects and organisation settings in your organisation, with who made each change and when.
Support access is off by default. You can grant Breqwatr support access to your account for one hour, 24 hours or seven days, turn it off at any time, and see every support sign-in in the audit log.

Sovereignty¶

Sovereignty is about where data is held, and who has authority and control over it.

Data residency

Breqwatr Cloud runs in two Canadian regions: ca-central in Ontario and ca-east in Quebec.
Customer data stored on Breqwatr Cloud stays in the region the customer chooses. Breqwatr does not move it to another region or country.

Ownership

Breqwatr is a Canadian company, founded in 2014.

Legal jurisdiction

Breqwatr Cloud is subject to Canadian law.

Operational access

Breqwatr support does not access customer environments by default.
Customers can grant support access for a set period and revoke it at any time, and every support sign-in is recorded in the audit log.

Impact¶

A stolen password alone doesn't open an account, because MFA is always on.
A leaked credential is limited to one tool's access, and can be revoked without stopping anything else.
Each instance is exposed only as far as its role needs.

Common anti-patterns¶

Shared accounts or credentials: several people or tools using one login or one application credential, so nobody can tell who did what, and revoking it breaks everything at once.
Admin ports open to the world: RDP or SSH allowed from 0.0.0.0/0.
Credentials in code: an application credential secret committed to a repository or written into an image.
Access that never ends: people who have changed roles or left, and credentials for retired machines, still active.
Patch it later: instances left on old operating system versions because nobody owns updating them.