CNI & network policies
Cilium or an appropriate CNI, namespace boundaries, default deny, required flows and network observability.
Ingress & gateway
Traefik, ingress-nginx or Gateway API with load balancing, TLS, redirects and controlled exposure.
DNS & certificates
cert-manager, DNS automation, internal and public zones and a traceable certificate lifecycle.
NetBird for private services
Routing peers and network resources for cluster API, dashboards, internal applications and contractor access.
SSO, MFA & RBAC
Map identity providers, groups and roles consistently across Kubernetes, platform tools and private access.
Network visibility
Monitor flows, errors, latency, certificates and reachability so root causes remain discoverable.
Kubernetes networking and secure access
WZ-IT connects cluster networking, ingress and gateway, DNS and TLS with identity-based access through NetBird. Public services are exposed safely while internal services avoid unnecessary internet exposure.
Three network layers
Separate cluster networking, public endpoints and private access
Kubernetes networking and secure access solve different problems. We design their transitions intentionally so internal admin and business services stay private while public applications receive a controlled entry point.
Inside the cluster
CNI, services, network policies, namespaces and egress rules govern communication within the platform.
Public exposure
Ingress or Gateway API, load balancers, DNS, certificates, rate limits and optional upstream protection.
Private reachability
Cluster API, dashboards and internal services through NetBird routing peers, network resources and access policies.
Identity & responsibility
OIDC, groups, roles, devices and contractor access are bound to concrete resources and purposes.
Network capabilities
What we implement around Kubernetes reachability
From packet flow inside the cluster to the browser or administration device, we consider the complete path and its responsibility boundaries.
In addition to the cluster, applications need defined processes for delivery, access, observability, recovery and technical ownership.
Delivery
GitOps, CI/CD, separate environments, approvals and reproducible rollbacks.
Network
CNI, network policies, ingress or gateway, DNS, TLS and private access.
Security
OIDC, RBAC, secrets, image validation, policies and traceable changes.
Observability
Metrics, logs, traces, alerting and SLOs for platform and applications.
Backup & restore
Cluster state, persistent data, restore tests and a documented recovery path.
Lifecycle
Updates, CVE assessment, capacity, costs and an agreed operating model.
Access architecture
From a service to controlled reachability
Users, locations, services, protocols and traceability requirements define the access model. Ingress, private networks, NetBird policies and administrative access paths follow from it.
Classify services
Separate public, partner, internal, administrative and cluster infrastructure.Trust boundaries
Separate identities, networks, tenants, sites and data flows.Exposure design
Choose ingress/gateway or private NetBird access for each service.Policies & identity
Implement RBAC, network policies, SSO/MFA and NetBird policies consistently.Observe & revoke
Monitor access, certificates, routes and changes and keep them revocable.Starting pointOngoing operations
Boundaries
NetBird for access identity, Kubernetes for cluster networking
CNI and network policies govern workload communication. NetBird creates a private, identity-based access path to selected resources. For publicly reachable applications, ingress or Gateway API remains the regular production path.
Internal dashboards and cluster APIs become reachable specifically for authorized identities and networks · Private services can be made selectively reachable without a classic full tunnel · Public and private exposure paths receive separate policies and monitoring
Frequently asked questions
Clear answers on architecture, delivery, responsibilities and ongoing operations.
- Yes. Routing peers and network resources can expose selected services or networks to authorized NetBird users. Identities and policies limit who can access each resource.
- No. A CNI provides the pod and service network and implements network policies inside the cluster. NetBird complements the design with private access from users, devices or sites to selected resources.
- Typically through a load balancer and ingress controller or Gateway API, combined with DNS, TLS, rate limits and, where required, WAF or DDoS protection. Internal administration services receive a separate private access path.
- Yes. Depending on infrastructure and cluster design, the API endpoint can be limited to management networks or NetBird. Access is additionally protected by Kubernetes authentication and RBAC.
- Yes. NetBird, WireGuard and classic routing or site-to-site designs can connect locations and private networks. Routes, access policies, DNS and failure behavior are designed together.
Knowledge base
In-depth guides for this building block
Knowledge base
One platform. Six entry points.
Select infrastructure and operating model deliberately
Reviews & projects
Operations that visibly relieve customers
Customer feedback on monitoring, updates, maintenance, support and stable production systems.
WZ-IT moved our studio infrastructure from decentralised individual devices to a central platform: every site is securely connected via VPN, new devices are onboarded automatically and an entire site is provisioned from a template, without manual steps on location. What impressed me most is the breadth and depth of their knowledge: Timo and Robin are not a typical IT provider who sets up a server and leaves. The two of them think their way into highly complex infrastructure and software topics, work through every requirement we put in front of them, and build networking, provisioning and operations so that everything fits together in the end. WZ-IT is an excellent partner for complex software, network and architecture projects.
Steve KirchnerManaging Director, nextGYM GmbH
International
Built in Germany's Ruhr Valley. Running worldwide.
WZ-IT designs, develops and operates infrastructure and software for clients in Germany and internationally. We deliver projects remotely and continue supporting them in ongoing operations after go-live.
Selected projects
- LiveRemote access platform for distributed water treatment plantsABCO Water Systems · Australia · Secure Access & OT
- 81%AWS migration with substantially lower operating costsEVA Real Estate · UAE · Cloud exit & infrastructure
- 98%Provision new sites in minutes instead of hoursnextGYM GmbH · Germany · Automation & IoT
Read client reviews
- Secure your Proxmox & backup setup
- Virtualize with Managed Proxmox
- Build a high-availability Proxmox cluster
- Modernize your infrastructure - sovereign
- Plan a sovereign open-source stack
- Integrate a local AI solution
- Modernize your legacy software
- Cut cloud cost - up to −81%
- Design an open-source AI architecture
- Get collaboration fully managed
- Ship your prototype to production
- Connect sites and clusters securely
Enquiry
Which Kubernetes services need to be reachable?
We classify public, internal and administrative access and derive the network, exposure and identity policies.
- Straight with Timo and Robin - no sales team, no pitch
- A professional assessment of your situation
- Concrete next steps for infrastructure, software or AI
The conversation is free and non-binding.
WZ-IT's advice on our Azure migration was technically sound and completely non-binding right from the intro call - we took away a great deal.
Jakob ÖschlbergerInno7 GmbH
WZ-IT's advice on our Azure migration was technically sound and completely non-binding right from the intro call - we took away a great deal.