INFITX Builds Zero-Touch Kubernetes Networking with NetBird

Company: INFITX
Headquarters: Ebene, Mauritius
Industry: Inclusive Financial Services Technology and Operations
Solution Architect: David Fry

Challenges:

• Providing secure ingress and egress access across dozens of Kubernetes clusters.
• Maintaining a fully open-source, license-compatible stack.
• Eliminating Kubernetes-distribution-specific networking logic.
• Managing NetBird configuration without manual scripts.
• Scaling private networking as clusters are provisioned multiple times per day.

Key Results:

• Zero-touch private networking for every new Kubernetes cluster.
• Distro-independent ingress via the NetBird Kubernetes Operator.
• Fully declarative NetBird configuration using Crossplane.
• Near-zero operational overhead for private network management.
• Unified networking model across on-prem and AWS environments.

Technologies Used: Kubernetes, AWS, Crossplane, Helm, Istio, Zitadel, NetBird Kubernetes Operator, NetBird API, NetBird Crossplane Provider

The Challenge: Private Networking at Kubernetes Scale

When you're managing dozens of Kubernetes clusters across on-premises data centres and the cloud, private networking quickly becomes one of the hardest problems to scale.

That was the reality facing the Mojaloop platform team at INFITX.

They needed to give Kubernetes clusters secure, private access to internal services like Vault, databases, monitoring, and object storage, while also allowing operators to securely connect into those clusters.

Everything had to be:

• Kubernetes-native
• Infrastructure-as-Code driven
• Fully open source
• Consistent across on-prem and AWS

And all this with a total lack of VPN tickets, manual bootstrapping and cloud-specific networking hacks.

Where Things Broke Down

Private networking was already partially automated, but not in a scalable way.

Kubernetes Ingress Provisioning

Before

• NetBird clients were installed directly on Kubernetes nodes using Ansible.
• The implementation was Kubernetes-distribution dependent.
• MicroK8s required different logic than EKS.
• Changes were brittle and difficult to generalise.

After

• NetBird router pods are provisioned via the NetBird Kubernetes Operator.
• The operator is deployed using Helm and Kubernetes Custom Resources.
• The solution is fully Kubernetes-native and distro-independent.

NetBird Server Configuration

Before

• NetBird was bootstrapped using Ansible scripts.
• Configuration changes were procedural and external to Kubernetes.
• Networking state lived outside the cluster control plane.

After

• All NetBird configuration is managed declaratively via a NetBird Crossplane provider.
• Networks, groups, policies, users, setup keys, and DNS are Kubernetes resources.
• Networking is continuously reconciled infrastructure, just like pods or services.

As clusters began spinning up multiple times per day, these limitations became impossible to ignore.

Networking needed to scale the same way Kubernetes does: declaratively, automatically, and repeatably.

The NetBird Architecture: Private Networking as a Platform Capability

At the centre of the design is a Control Center cluster.

Each Control Center:

• Runs a NetBird instance.
• Manages private access for associated clusters.
• Provisions infrastructure and networking declaratively using Crossplane.

Every environment cluster:

• Runs the NetBird Kubernetes Operator.
• Automatically joins the private mesh.
• Receives ingress and egress access based on identity and policy.

Istio ServiceEntries and waypoints are used to route specific workloads through NetBird, enabling fine-grained service-level egress control.

The result is a secure, identity-based private mesh spanning:

• Control Center clusters
• Environment clusters
• On-prem storage clusters
• AWS private services
• Operator endpoints

All without exposing sensitive infrastructure publicly.

Figure: NetBird provides a shared, identity-based private network connecting control planes, Kubernetes clusters, operators, and private services across on-prem and AWS.

Zero-Touch Provisioning with Crossplane

The most powerful outcome of this design is that networking is provisioned the same way as infrastructure.

David Fry, the architect behind the implementation, built a NetBird Crossplane provider that allows the platform to automatically create and manage:

• Accounts and service users
• Groups and RBAC mappings
• Networks and network resources
• Policies and routes
• Setup keys and access tokens
• DNS configuration

When a new environment cluster is created:

1. Crossplane provisions the required NetBird resources.
2. The NetBird Operator is deployed via Helm.
3. Router pods join the mesh automatically.
4. Ingress and egress access is enforced by identity-based policy.
5. Operators gain secure access instantly.

No manual steps, environment-specific logic or networking tickets.

Figure: Infrastructure automation powered by Kubernetes, Crossplane, and NetBird - from declarative custom resources to zero-touch mesh enrollment.

Scale in Practice

Today, the platform operates at meaningful scale:

• Up to 30 clusters per Control Center
• 5 Control Centers currently, with up to 20 planned
• Multiple clusters provisioned per day
• Hybrid deployments across private data centres and AWS

Despite this scale:

“Ops effort is almost zero due to automation.”

Networking is no longer a bottleneck, it’s simply part of cluster provisioning.

An Unexpected Win: Identity Done Right

One of the most significant (and unexpected) benefits came from identity.

The original plan was to use GitLab as an identity provider. But after working with NetBird’s self-hosted deployment and its Zitadel integration, the team adopted Zitadel as their IdP/IdM solution.

That shift:

• Simplified RBAC across environments.
• Integrated cleanly with NetBird’s policy model.
• Became foundational to the platform’s Zero Trust approach.

What began as a networking initiative evolved into a broader identity and access transformation.

Lessons Learned

The hardest part of the journey was converting early “getting started” scripts into a fully Kubernetes-native, declarative model.

This required:

• Reverse-engineering bootstrap processes.
• Translating imperative scripts into reconciled resources.
• Automating machine users for API-driven provisioning.
• Building the initial IaC components for both NetBird and Zitadel Helm deployments.

That effort, led by David Fry, not only enabled zero-touch networking but also produced the open-source NetBird Crossplane provider - a contribution now available to the broader community.

Figure: From distribution-specific scripts and node installs to declarative, Kubernetes-native, identity-based networking.

The Business Impact

By combining NetBird’s identity-based mesh networking with Kubernetes Operators and Crossplane automation, INFITX transformed private networking from a scaling risk into a platform strength.

Networking is now:

• Declarative
• Auditable
• Repeatable
• Secure by default
• Fully integrated into Kubernetes

Private access is no longer a special case - it becomes a part of the platform.

Conclusion

NetBird enabled the Mojaloop team at INFITX to treat private networking as code.

What was once a brittle, script-driven process is now a policy-driven, identity-based system that scales naturally with their Kubernetes environments.

As the number of clusters and environments continues to grow, the networking model grows with it, without increasing operational overhead.

Zero-touch networking isn’t an aspiration anymore, it’s the default!