Skip to content

Platform security under Kubernetes Restricted

In short: every Capitality application service runs under the Kubernetes Pod Security Standard Restricted — without administrator rights, on a read-only system, with redundant sign-in and hosting in the EU. There is nothing to configure on your side.

Last reviewed: 10 October 2026.

Your clients, owners, properties and deals are the core of your business. Capitality protects them where it matters most: in the software that processes them. Since October 2026, every Capitality application service — the web app, the API behind it, sign-in and messaging — runs under Restricted, the strictest of the three security profiles that Kubernetes defines for workloads. For a real-estate CRM that handles client, owner and property data every day, that is not a detail but the foundation.

The Kubernetes project publishes three Pod Security Standards: Privileged, Baseline and Restricted. Restricted follows current pod-hardening best practice and is the profile security teams ask for. For Capitality it means:

  • No administrator rights. Every service runs as an ordinary, unprivileged user. Not even our own software can act as the system administrator.
  • No way to gain more. Privilege escalation is switched off, and every optional operating-system privilege is removed.
  • Filtered system access. A system-call filter blocks rarely needed, risky operations at the boundary to the operating system.
  • Read-only by design. The running software cannot be altered. Each service has one temporary scratch area and nothing else it can write to, so nothing an intruder leaves behind survives a restart.
  • Lean by design. Each service ships only what it needs to run — no general-purpose tools an intruder could put to use.
  • Current foundations. The services run on a current, maintained operating-system base.
  • Verified identities between services. When a Capitality service asks the identity service who you are, both sides prove who they are with certificates, over an encrypted connection.

Sign-in runs as two independent copies spread across our servers. Updates roll out one copy at a time, so you can sign in while we ship improvements.

Production workloads run in the EU. Capitality is built and operated by Capkrea GmbH in Germany.

These measures are part of the hosted product — there is nothing to configure on your side. If your IT department or data-protection officer needs details for a vendor assessment or for your technical and organisational measures, write to [email protected].

What your office itself owes under the GDPR — processing agreements, information duties, retention periods — is explained in our German guide DSGVO für Immobilienmakler.

To report a vulnerability, see Security & privacy.

Does Capitality meet the Kubernetes Restricted Pod Security Standard?

Section titled “Does Capitality meet the Kubernetes Restricted Pod Security Standard?”

Yes. Since October 2026 every Capitality application service — the web app, the API, sign-in and messaging — runs under Restricted, the strictest of the three Kubernetes Pod Security Standards.

Does Capitality run with root or administrator rights?

Section titled “Does Capitality run with root or administrator rights?”

No. Every application service runs as an ordinary, unprivileged user. Privilege escalation is switched off and every optional operating-system privilege is removed.

No. The application services are read-only. Each has one temporary scratch area and nothing else it can write to, and nothing written there survives a restart.

Production workloads run in the EU. Capitality is built and operated by Capkrea GmbH in Germany.

No. These measures are part of the hosted product.

Who do I contact for a vendor security assessment?

Section titled “Who do I contact for a vendor security assessment?”

Write to [email protected] — for questionnaires, technical and organisational measures (TOM), or a vulnerability report.