Why Crossplane Fits a Regulated Multi-Tenant Platform

▶ Watch (0:09)

Baloise is a Swiss insurance company running a highly regulated, multi-tenant environment. Self-service for developers is hard there because many resources, like DNS or virtual networks, have shared usage but no shared responsibility. Crossplane reuses existing Kubernetes tooling: Kyverno, OPA Gatekeeper, admission policies, and the same RBAC already applied to application deployments. That reuse gives one control plane for both application and infrastructure changes, and the same GitOps promotion flows apply to both.

Implementation Flexibility: From YAML to General-Purpose Code

▶ Watch (1:00)

Crossplane does not force one implementation style. Teams can start with YAML-level patch-and-transform compositions, then move to Go templates (familiar from Helm), and eventually write functions in Go, TypeScript, or Python for logic that templating cannot handle. Provider coverage spans every major cloud. At Baloise, provider-upjet-azure is one the speaker maintains directly. The on-ramp stays shallow while the ceiling stays high.

DNS Ownership Without Shared Responsibility

▶ Watch (2:27)

Most cloud DNS products give no built-in validation of which tenant owns which record. Any tenant can overwrite another. Crossplane fixes this by exposing a composite resource that limits each tenant to a safe subset of DNS operations. The platform enforces ownership at the API layer, so developers cannot create or modify records outside their boundary. Baloise built this capability without patching the cloud provider or building a custom controller from scratch.

Extending Cloud Provider Products With Custom Functions

▶ Watch (3:05)

Cloud provider API gateways ship with fixed feature sets. When a compliance or domain requirement falls outside that set, Crossplane compositions written in Go or TypeScript can fill the gap. Baloise uses this to add policy caching and to fetch resources the cloud provider does not natively surface. The result is a platform built on top of the cloud provider platform, adding domain-specific behavior without forking or duplicating the underlying service.

One Flag Provisions SSO Across Multiple Providers

▶ Watch (3:40)

Baloise built an abstraction that deploys an application to Kubernetes and, when a developer sets a single flag called sso_enabled, creates every resource needed for authentication. That includes gateway API objects inside the cluster and records in the external identity provider. Two providers, Kubernetes and the cloud identity provider, get reconciled together. The developer writes one simple resource with no knowledge of the internals and gets a safely deployed application.

Notable Quotes

self-service in highly regulated multi-tenant environment is tricky uh you have a lot of resources that have shared usage but no shared responsibility Jonasz Łasut-Balcerzak · ▶ 01:31

crossplane is really good at abstracting the platform complexity for the developers and it allows you to build guard rails to just enable developers to move way quicker and way safer at the same time Jonasz Łasut-Balcerzak · ▶ 04:37

developer can just do one really simple resource without any knowledge about the internals and get a safe safely deployed application Jonasz Łasut-Balcerzak · ▶ 04:26

Key Takeaways

  • Crossplane reuses Kubernetes RBAC and admission policies for infrastructure deployments, not just applications.
  • Tenant-scoped composite resources enforce DNS ownership that cloud provider APIs do not provide natively.
  • A single sso_enabled flag can trigger multi-provider provisioning across Kubernetes and an identity provider.

About the Speaker(s)

Jonasz Łasut-Balcerzak is a Platform Engineer at Baloise with a focus on Kubernetes and declarative, unified APIs. He maintains the provider-upjet-azure and provider-upjet-azuread Crossplane providers.