On-Demand Workspaces via Flux Operator with Granular RDP/SSH & Kubeconfig Access

[suse-coder]

Before posting

• I searched existing discussions and issues for similar requests.
• I checked the documentation to confirm this is not already supported.
• This is a product idea or enhancement request, not a support question.
• I removed or anonymized sensitive details from examples and screenshots.

Product area

Kubernetes / Operator

Problem or use case

As a Platform Engineer / IT Administrator,
I want to offer developers a self-service, one-click portal within the NetBird UI to spin up secure, ephemeral workspaces (Kubernetes Pods or KubeVirt VMs) that are instantly connected to the NetBird network, while maintaining strict control over cloud costs and data exfiltration.

Because currently, managing remote developer environments requires stringing together multiple disconnected tools. While Coder provides a great workspace paradigm, it relies heavily on Terraform to orchestrate resources. Managing Terraform state and external providers inside a strictly declarative, API-managed environment like Talos Kubernetes is overly complex. Furthermore, giving developers self-service access to compute (especially AI/GPU nodes or full KubeVirt VMs) often leads to runaway cloud costs if there is no built-in way to enforce quotas, track runtime credits, or restrict expensive templates to specific user groups.

Proposed solution

We propose integrating a Workspace Management Engine within NetBird. However, instead of utilizing Terraform (like Coder), NetBird should use the Kubernetes-native Flux CD / Flux Operator with ResourceSets. This engine will feature robust resource governance, template access control, and a credit-based tracking system.

1. Flux-Powered Workspace Provisioning (UI & Engine)

• Flux Operator Integration: NetBird integrates with the Flux Operator to deploy workspaces as standard Kubernetes Pods or KubeVirt VMs using the ResourceSet App Definition pattern instead of managing complex Terraform state engines.
• Standardized NetBird Helm Chart: NetBird provides a baseline Helm chart that packages:
  • The workspace container (an image pre-loaded with developer tooling like VS Code/Jupyter and the NetBird agent client).
  • Necessary Gateway API/HTTPRoute resources for routing traffic.
• Zero-Trust Network Isolation (No Pod-to-Pod Communication): The ResourceSet definition must automatically enforce strict isolation (e.g., via generated NetworkPolicies). The workspace pod is restricted so it cannot communicate with other pods in the cluster (no east-west pod-to-pod traffic). All network access is strictly forced through the secure NetBird client interface.
• Dynamic UI Forms: The NetBird UI parses the .inputs schema from the Flux ResourceSet and automatically generates a form in the UI for the user (e.g., choosing CPU/RAM, choosing custom environment variables, or disk size).
• Template Marketplace: A catalog in the NetBird UI containing:
  • Default Templates: VS Code (code-server), Jupyter/AI Notebooks (Python, TS, Rust), and standard Linux environments.
  • Custom Templates: Private Helm charts/git repos for KubeVirt VMs (e.g., a SUSE Linux or Windows VM with NetBird pre-installed).

2. Template Access Control, Limits, and Cost Accounting (Credits)

To prevent resource abuse and manage costs, we need governance features built directly into the NetBird workspace UI:

• Group-Based Template Access: Admins can restrict templates to specific NetBird Groups (e.g., the "AI Notebook" template is only visible to and launchable by the data-science group; the "Windows VM" template is restricted to it-admins).
• Credit-Based Cost Accounting:
  • Admins can assign a "Credit Cost per Hour" to each template (e.g., a lightweight VS Code pod costs 1 credit/hour, while a GPU/KubeVirt VM costs 10 credits/hour).
  • NetBird tracks active workspace runtimes and calculates usage, providing admins with clear cost-accounting reports showing how many credits each user/group has consumed.
• Allocation & Quotas:
  • Admins can set limits per user or group (e.g., Group externals is limited to a maximum of 1 active workspace and a quota of 100 credits per month).
  • Auto-off/Shutdown policies to automatically stop/pause workspaces after a period of inactivity to save credits.

3. Automatic Networking & Client Injection

• Native Peer Registration: When a workspace is spun up, the NetBird client is automatically injected (via a sidecar, daemon, or startup script) and registered to the NetBird network using an ephemeral setup key linked to the creating user.
• Gateway API & HTTPRoute: Automatically configure Kubernetes Gateway API / HTTPRoutes so the user's local NetBird client can securely route traffic directly to the workspace Pod/VM.
• Kubeconfig Injection: For IDE-based workspaces (like VS Code), NetBird automatically generates and injects a scoped, secure kubeconfig into the workspace, allowing developers to safely interact with allowed Kubernetes resources directly over NetBird.

4. Granular Access & DLP Policies (RDP/SSH)

• Access Control: Enable/disable in-browser SSH or RDP access to these workspaces on a per-user or per-group basis.
• Data Loss Prevention (DLP): Within NetBird's Access Policies, introduce toggles to restrict capabilities during RDP/SSH sessions:
  • Disable Clipboard Copy/Paste (Inbound, Outbound, or Both).
  • Disable File Transfer (preventing users from uploading/downloading files from the remote workspace to their local machine).

Alternatives or workarounds considered

Currently, organizations have to use Coder alongside NetBird. However:

• Terraform Overhead: Coder's reliance on Terraform templates requires managing state files and external infrastructure providers. Replacing this with a native FluxCD ResourceSet GitOps model fits perfectly into modern Kubernetes architectures.
• We have to manage two entirely separate platforms, user bases, and access control lists.
• Connecting external workspace pods securely to internal corporate networks via WireGuard requires complex manual sidecar setups.
• Standard tools lack built-in Data Loss Prevention (clipboard/file-transfer blocking) tied directly to network identity groups.
• External cost tracking for Kubernetes namespaces requires separate FinOps tools (like Kubecost) rather than having simple, credit-based quotas at the developer self-service level.

Community impact and priority

• Number of users/teams/peers affected: This would massively benefit enterprise and medium-sized software teams, MSPs, and educational institutions looking for an all-in-one secure remote development platform.
• Deployment type: Self-hosted on API-driven, bare-metal/immutable distributions like Talos Kubernetes where standard OS-level access is restricted and declarative GitOps pipelines are preferred.
• Frequency: Daily (developers logging into their workspaces).
• Blocking production adoption? No, but it would elevate NetBird from a "VPN replacement" to a complete "Secure Enterprise Workspace Platform."

Examples from other tools or products

• Coder: For the workspace template marketplace, self-service provisioning, user/group-based quotas, active runtime tracking, and template variables.
• Flux Operator (fluxoperator.dev): Specifically for utilizing the ResourceSet and App Definition spec to define input parameters and deployment dependencies.
• Kasm Workspaces / Teleport: For browser-based remote access with built-in clipboard/file-transfer restriction policies.

Security, privacy, and compatibility considerations

• DLP via RDP/SSH: Since NetBird can leverage Rust-based RDP libraries such as IronRDP, DLP policies can be enforced directly by the client agent or web UI handler. Instead of running a heavy proxy, the connection handler can dynamically strip or reject clipboard (cliprdr) and drive/file redirection virtual channels from the IronRDP session negotiation based on the logged-in user's NetBird Group permissions.
• Resource Exhaustion (Security): The credit and quota system is critical to prevent malicious or accidental resource exhaustion (e.g., a compromised developer account spinning up 100 high-performance KubeVirt VMs).
• Talos Kubernetes Compatibility: Because Talos Kubernetes is an immutable, minimalist, API-only OS (without SSH or host-level package managers), the declarative approach of using the Flux Operator to build workspaces via ResourceSets is the ideal paradigm, keeping the host OS secure.

Implementation ideas

• Provisioning Engine: Utilize the ResourceSet CRD from the Flux Operator. NetBird's backend translates UI inputs into Kubernetes manifests applied via the operator.
• Cost Accounting Database: Introduce a lightweight time-series tracking table in the NetBird database to track workspace state changes (started/stopped) to calculate credit consumption metrics per user/group.
• DLP Routing Layer: Implement policy enforcement inside the NetBird connection client/web interface natively using IronRDP (or similar SSH-session libraries) to prune clipboard and file transfer channels directly from the transport stream.

Are you willing to help?

Not at this time.

Additional context

I was talking with Jack Carter at Gitext Europe 2026 already about this idea.