Every user has a role and an application scope, every sign-in requires a second factor, every change is recorded in the audit log. Credentials are stored encrypted and never output again.
Security in Clusterward starts at sign-in: named users with a password and mandatory 2FA via TOTP, account lockout and rate limiting. RBAC sits on top of that: each role assigns one level per area, from “no access” to “manage”, plus an application scope that limits a user to their own applications and everything below them. Every route is locked by default until it is mapped to a permission. Every change writes an audit entry with person, action and object, never with secrets. And every customer gets their own workspace with its own database, its own key and its own backup bucket.
Password plus TOTP code; too many attempts lock the account.
The workspace IP allowlist applies before sign-in, using the real client address.
The route requires a level in an area; without a mapping, it is locked.
A user sees only their own applications and everything attached to them.
The change lands in the audit log; the message goes to the channel without any secret.
Not a checklist for later, but defaults you don’t have to switch off.
Two factors for everyone, invitations instead of shared passwords.
Every user sets up TOTP before they start working. The secret is stored encrypted, sign-in attempts are limited per address, and accounts lock after failed attempts.
New users get a link to set their own password. Even the first administrator of a workspace starts with an invitation.
A link resets the password; ten one-time recovery codes replace the authenticator. 2FA always remains mandatory.
An address with too many failed attempts is blocked for one hour, and for a day if it happens again. A sign-in from a new address triggers an email to the account owner.
A session ends after two hours without activity and after twelve at the latest. New passwords need at least 12 characters, new recovery codes require the current code from your authenticator app, and the cockpit accepts changes only from its own address.
Everyone may do only what they need, and every action has a name.
A role is a matrix of areas and levels. The built-in administrator has everything, every other role only what it needs; everyone grants roles, scopes and API tokens only within their own rights. A scope restricts users to their own applications, databases and buckets – including tenant runs, backups and bucket keys.
Tokens for CI pipelines carry a role, an application scope and an expiry date. They can never manage tokens, users or roles, never be administrator, and every action is recorded under their name in the audit log.
Every mutation, every dump download, every key rotation: person, time, action, object. Secret values never appear in it, only their type. Searchable and filterable in the cockpit under System → Audit log; an auditor role can read along without managing users.
The SQL console has a permission of its own that follows from no database right. It queries with its own read-only login in a read-only transaction, and every query is in the audit log with text, row count and duration – never with values. API tokens cannot use it.
Once something is saved, it never comes back out.
Scaleway keys, kubeconfigs, Git tokens and database admin credentials are verified before saving, stored encrypted and never returned. Only application variables and connection details you need to copy are readable. Entering and rotating them requires the manage level – as does any change to where a stored credential is sent.
Once saved, secrets can only be overwritten, even by administrators. If you want, they live in the Scaleway Secret Manager of your project, with versions and rotation.
Who can reach the workspace and the Kubernetes API – and what may run in the cluster.
A workspace can be restricted to address ranges; the check knows Cloudflare addresses and rejects spoofed headers. Locking out your own address is prevented.
The card on the cluster shows which addresses may reach the Kubernetes API. After an IP change, “Add my IP” saves you the trip to the Scaleway console.
One click gives an environment network policies: only the ingress controllers and its own pods get in, and the nodes’ metadata service stays out of reach. System → Security shows which environments are still open. When an ingress controller is added or removed, the policies adjust themselves; anyone with the manage level can remove the isolation again.
The cluster identity reads the cluster without secrets and writes only in the namespaces it created for your environments; policies on the cluster enforce this. Admin access for add-ons lasts one hour, and builds push with a registry-only key. From Kubernetes 1.30.
Pods with seccomp, no privilege escalation and no capabilities. Your environments’ namespaces run with Pod Security “baseline”; where a running pod still violates it, the cockpit reports it instead of stopping the pod.
Scaleway, Cloudflare and Kubernetes are addressed through their HTTP APIs; dependencies stay small.
AES-256-GCM per workspace with its own data key, wrapped by the platform key.
Separate database and backup bucket per workspace, no shared tables.
Operated on Scaleway in the EU by BitKollegen GmbH.
A role assigns exactly one level per area. On top of that comes “all applications” or a list of specific applications.
| Level | Allowed | Example |
|---|---|---|
| no access | Nothing in this area | Developer without cluster visibility |
| view | Read | Support reads deployments and logs |
| operate | Day-to-day: deploy, restart, create | Developer rolls out their application |
| manage | Delete, enter credentials, upgrades, write Helm charts | Team lead manages clusters |
| Administrator | Everything, fixed, not editable | Workspace operator |
The restricted operator identity is created by Cluster provisioning; hardened pods and NetworkPolicies are part of Deployments.
Where your data resides and why operating in the EU is a deliberate choice is explained under Digital sovereignty. Answers to GDPR questions and the data processing agreement are available via Contact.
Kapsule clusters secure by default, with Private Network and gateway.
Go to Cluster provisioningGit, container image or Helm chart – rolled out with a health check.
Go to DeploymentsWebhook, Slack, Teams or email – once per event.
Go to NotificationsCan’t find your question? Write to us – we usually reply on the same business day.
Ask a questionIn the demo, we show roles, the audit log and isolation on a real workspace and answer your questions about GDPR and the DPA.
