Prepare Unbounded Kubernetes for CNCF Sandbox application

[emma-clawdbot]

Objective

Prepare Unbounded Kubernetes for a CNCF Sandbox application and maintain an evidence-backed, public-safe worksheet before opening the final application in cncf/sandbox.

This issue is the public project-side coordination point. Do not submit the final CNCF Sandbox issue until the proposed application has been approved by the project maintainers and the authorized contributing or sponsoring entity.

This is a public issue. Record only public-safe facts, decisions, and approval status here. Do not post personal data, confidential legal advice, internal approval records, credentials, non-public asset inventories, security configuration, recovery contacts, access methods, or transfer procedures. The final CNCF application is also public, so designated contacts must consent before their information is published.

Sources and status

Evidence was checked on 2026-07-29 UTC against:

• Current CNCF Sandbox application form
• CNCF Sandbox process
• CNCF project lifecycle and process
• CNCF IP policy
• CNCF dependency-license allowlist
• CNCF Sandbox support and marketing expectations
• llm-d Sandbox application example
• Unbounded repository, documentation, source, releases, issues, and project policy files

Status terms used below:

• Verified: directly supported by a linked public source.
• Proposed: issue-ready wording inferred from verified sources; maintainers must approve it.
• Owner input required: the public record does not establish the answer. The responsible role and source of truth are named.

Evidence-backed application worksheet

Project summary

Status: Proposed

Unbounded Kubernetes extends a conformant Kubernetes control plane with worker nodes across remote infrastructure, on-premises environments, bare metal, and edge sites, with integrated node provisioning and cross-site networking.

Evidence: README: What is Unbounded Kubernetes? and Project Overview.

Public routing owner: @Azure/unbounded-dev, the repository-wide CODEOWNER team. CODEOWNERS is not itself proof of CNCF maintainer status; the current project owner must identify the people authorized to approve this wording.

Name confirmation required: the README uses Unbounded Kubernetes, while some documentation uses Project Unbounded or Unbounded. The project owner and trademark counsel must confirm the official contribution and trademark name before the final application.

Project description

Status: Proposed

Unbounded Kubernetes extends a conformant Kubernetes control plane so worker nodes can run across on-premises environments, bare metal, edge sites, and remote infrastructure while remaining part of one cluster. It addresses node provisioning and pod networking when workers do not share the control plane's VPC or LAN.

The project provides a node bootstrap agent; a Kubernetes controller for SSH provisioning; a PXE, Redfish, and TPM-based bare-metal path; and a multi-site CNI and networking system. The networking layer allocates pod CIDRs and connects sites using WireGuard, GENEVE, VXLAN, IPIP, direct routing, and an eBPF dataplane. The project also exposes Kubernetes custom resources for machines, sites, gateway pools, and site peering. A separate cloud-API/Karpenter provisioning path is documented as intended architecture that is still being designed and built.

The implementation uses Kubernetes APIs and controller-runtime, containerd, OCI artifacts, Prometheus metrics, and standard Kubernetes node components. Its goal is to let operators add heterogeneous compute capacity to an existing Kubernetes control plane without operating a separate Kubernetes cluster at each location.

Evidence: Project Overview, Architecture, README features, and Go dependencies.

Approval owner: @Azure/unbounded-dev.

Organization repository URL

Status: Verified answer

N/A. The application is not for all repositories in the Azure organization.

Reason: the CNCF form requests an organization URL only when all repositories under that organization are in scope. The proposed primary scope is the single repository below.

Confirmation owner: @Azure/unbounded-dev must confirm that this is the intended scope.

Primary project repository URL

Status: Verified

https://github.com/Azure/unbounded

Additional repositories in scope

Status: Proposed answer, maintainer confirmation required

N/A based on the current public tree. PR #49 merged the former unbounded-net codebase into this repository. Networking code is now present under api/net, cmd/unbounded-net-controller, cmd/unbounded-net-node, internal/net, and deploy/net.

The README still links to the former Azure/unbounded-net repository, which does not currently resolve publicly, and the architecture source still describes networking as a “separate repo.” Both should be corrected before submission: README component link and architecture source.

Confirmation owner: @Azure/unbounded-dev; repository owners must identify any additional code, documentation, package, or website repositories intended for contribution.

Website URL

Status: Verified

https://unbounded-cloud.io

The repository homepage points to this domain, and the former GitHub Pages URL redirects to it. Documentation is published there.

Evidence: repository metadata, documentation, and README documentation section.

Roadmap

Status: Owner input required

No dedicated public roadmap or GitHub milestone was found. The open issue list and designs/ show active work, but neither is explicitly designated as the project roadmap.

Required action: publish a stable roadmap URL that states priorities, intended outcomes, and time horizons without exposing confidential commitments.

Owner: @Azure/unbounded-dev. The maintainers should approve the roadmap; component leads should provide their planned work. If an internal roadmap exists, the project owner should publish a public-safe version rather than linking internal planning systems.

Roadmap context

Status: Owner input required

Interim public evidence shows an early-development project with ongoing work in node bootstrap, networking, operator lifecycle, GPU support, release upgrades, storage, image distribution, and management UX. The repository explicitly warns that it is suitable for experimentation and prototyping and may make breaking changes.

Evidence: README early-development notice, open issues, and design documents.

Owner: @Azure/unbounded-dev must turn this evidence into an approved roadmap narrative and explain the intended project direction.

Contributing guide

Status: Verified

https://github.com/Azure/unbounded/blob/main/CONTRIBUTING.md

The guide documents issue reporting, pull requests, build and test expectations, and the Microsoft CLA process.

Code of Conduct

Status: Verified

https://github.com/Azure/unbounded/blob/main/CODE_OF_CONDUCT.md

The project currently adopts the Microsoft Open Source Code of Conduct.

Adopters

Status: Owner input required

No ADOPTERS.md or equivalent public adopter list was found. GitHub contributors, issue reporters, stars, or forks are not sufficient evidence of production adoption.

Where to find the answer: verifiable public deployment references, public talks, case studies, or adopter statements approved by the adopting organizations.

Owner: @Azure/unbounded-dev should ask known users for consent and open a PR adding ADOPTERS.md. Each entry should be supplied or confirmed by the adopter. If no public adopters can be verified, leave this optional CNCF field blank rather than infer adoption.

Maintainers file

Status: Owner input required

The repository has a CODEOWNERS file assigning all paths to @Azure/unbounded-dev, but it does not identify individual maintainers, roles, affiliation, selection process, or emeritus status. CNCF asks for a maintainers file or .project repository.

Required action: publish MAINTAINERS.md or a .project repository with the current maintainers and roles.

Owner: the current @Azure/unbounded-dev team and Azure repository administrators. Only current project owners can authoritatively name maintainers; commit counts must not be used as a substitute.

Governance

Status: Owner input required

No public governance document was found. The public record establishes code ownership but not how decisions are made, maintainers are added or removed, conflicts are resolved, or organizational neutrality is protected.

Required action: publish a governance document covering decision-making, roles, maintainer lifecycle, voting or consensus rules, conflicts of interest, and dispute resolution.

Owner: @Azure/unbounded-dev and the current project owner. The contributing entity's open source program office should review the document for consistency with the proposed foundation contribution.

Security policy

Status: Verified, CNCF-readiness review still required

https://github.com/Azure/unbounded/blob/main/SECURITY.md

The policy directs vulnerability reporters to Microsoft's security reporting process and prohibits public issue reports. Before submission, maintainers should compare it with the CNCF security guidance and templates and decide whether project-specific supported versions, response expectations, and disclosure handling need to be documented.

The public architecture documentation also identifies an unresolved readiness issue: SSH host-key verification is currently disabled using InsecureIgnoreHostKey; a fingerprint status field exists but verification is not enforced. Security maintainers should resolve or explicitly risk-assess this before submission.

Owner: project security maintainer(s) named in the future maintainers file, with the contributing entity's security response team.

Standard or specification?

Status: Proposed answer

N/A. The public repository implements software and project-specific Kubernetes CRDs; it does not present those APIs as an independent industry standard or specification.

Evidence: CRD overview and api/.

Confirmation owner: @Azure/unbounded-dev. If maintainers intend any API to be a portable standard independent of this implementation, they must describe that scope and governance.

Business product or service to project separation

Status: Proposed factual baseline; contributing-entity input required

The repository is hosted in the Azure GitHub organization, its core license carries Microsoft copyright, and its contribution process uses the Microsoft CLA. At the same time, the public project states that it works with conformant Kubernetes control planes including AKS, EKS, GKE, kubeadm, and k3s. The current source registers machine-operation providers for Azure VMs and OCI instances; broader cloud-API provisioning is documented as planned architecture.

Evidence: LICENSE, CONTRIBUTING, and README features.

The public record does not establish the project's relationship to a specific commercial product, staffing independence, roadmap independence, or future neutral governance. The final answer must explain any related products or services and how branding, governance, development, releases, and roadmaps are separated.

Owner: the project owner plus the authorized contributing or sponsoring entity's open source program office and product/legal representatives. Publish only the approved public-safe answer.

Why CNCF?

Status: Proposed

Unbounded is built around Kubernetes node lifecycle, container runtime, OCI artifact, observability, and networking primitives. CNCF stewardship could provide a neutral venue for collaboration among Kubernetes users, infrastructure providers, hardware vendors, and adjacent cloud native projects; make governance and ownership independent of a single vendor; and help the project align with CNCF expectations for security, legal hygiene, community growth, and project sustainability.

Evidence boundary: this is a proposed rationale, not evidence of existing neutral governance. The final wording must be approved by maintainers and the contributing entity.

Benefit to the cloud native landscape

Status: Proposed

Unbounded addresses a specific gap between single-cluster node lifecycle and multi-location infrastructure: adding real Kubernetes worker nodes from remote infrastructure, on-premises environments, bare metal, and edge sites to one conformant control plane, while also provisioning cross-site pod connectivity. Its current public implementation combines SSH and PXE/Redfish/TPM provisioning, node bootstrap, machine operations for Azure VMs and OCI instances, and multi-site networking behind Kubernetes APIs. Cloud-API/Karpenter provisioning is planned, not yet a shipped differentiator.

Its proposed differentiator is the combined treatment of remote-node provisioning and intra-cluster cross-site networking. This should be validated with users and compared explicitly with the projects below before submission.

Evidence: Project Overview and Architecture.

Approval owner: @Azure/unbounded-dev; external users should validate the problem statement.

Cloud native fit

Status: Proposed

Unbounded is Kubernetes-native: desired state is represented with custom resources; controllers reconcile machines, sites, gateways, and networking; the provisioned hosts join as Kubernetes Nodes; and deployment is reconciled by an operator. It extends declarative Kubernetes APIs to infrastructure and network lifecycle across dynamic, heterogeneous environments.

A likely CNCF Landscape fit is Provisioning / Automation & Configuration, with substantial overlap with Runtime / Cloud Native Network. The current CNCF Landscape taxonomy and TAG Infrastructure scope should be used to confirm categorization.

Evidence: Architecture and CRDs.

Cloud native integration

Status: Verified technical evidence; maintainer review required for completeness

• Kubernetes: the project uses Kubernetes APIs, CRDs, kubelet, kubeadm bootstrap, client-go, controller-runtime, and the aggregated API machinery. Sources: architecture, go.mod, and api/.
• containerd: provisioned worker nodes run containerd; the project directly depends on containerd APIs and libraries. Sources: agent overview and go.mod.
• Prometheus: project components expose Prometheus metrics and directly use prometheus/client_golang. Sources: published networking operations source and go.mod.
• OCI / ORAS: the project consumes and publishes OCI artifacts and directly uses oras-go and Open Containers image specifications. Sources: architecture netboot OCI images, go.mod, and release artifacts.
• Karpenter ecosystem (planned, not a current integration): the Cloud API guide explicitly says this path is still being designed and built; it describes intended Karpenter-based provisioning for unschedulable pods. Do not claim a shipped Karpenter integration until implementation and tests are linked.
• Azure VM and OCI instance machine operations: the current machine-operations controller registers Azure VM and OCI instance providers for host lifecycle operations. Source: cmd/machine-ops-controller/main.go.
• Existing CNIs: docs state that clusters with an existing CNI such as Cilium or Calico can set manageCniPlugin: false; Unbounded can also serve as the CNI when none exists. Source: architecture network section.

Do not claim integration with an entire project solely because a similarly named library appears in go.mod. Maintainers should confirm which integrations are tested and supported.

Cloud native overlap

Status: Proposed comparative analysis of CNCF projects

• Kubernetes: Unbounded extends Kubernetes node, API, controller, and networking behavior rather than replacing Kubernetes.
• KubeEdge: both reach edge hosts. KubeEdge emphasizes cloud-edge synchronization, edge autonomy, applications, and devices; Unbounded's public scope is worker-node provisioning and cross-site networking.
• OpenYurt: both preserve Kubernetes APIs while extending nodes across edge or remote regions. OpenYurt also addresses disconnected operation, node pools, and cross-region pod connectivity, making it one of the closest functional comparisons.
• Metal3: both provide Kubernetes-native bare-metal lifecycle management and use Redfish; Unbounded also includes remote-node bootstrap and multi-site networking.
• Karmada: both address multi-cloud and hybrid-cloud operations. Karmada orchestrates across multiple clusters; Unbounded's stated model keeps one control plane and adds worker nodes from multiple locations.
• Kairos: both address edge, cloud, and bare-metal Kubernetes node lifecycle and can span regions; Kairos emphasizes immutable OS images and atomic upgrades.
• Existing CNI projects such as Cilium and Calico overlap with pod networking. Unbounded docs explicitly describe coexistence mode and position its own CNI around cross-site routing and tunnels.

Similar projects

Status: Proposed list covering CNCF and external projects

• Cluster API provides declarative lifecycle management for Kubernetes clusters and infrastructure providers. Unbounded focuses on adding worker nodes and networking them into an existing conformant control plane.
• Submariner connects networks across Kubernetes clusters. Unbounded networking connects sites and worker nodes within one Kubernetes cluster.
• Karpenter provisions nodes for unschedulable Kubernetes pods. Unbounded's cloud-API guide describes a planned Karpenter-based path, but explicitly says it is still being designed and built.
• Liqo builds transparent multi-cluster topologies, virtual-node workload offload, and cross-cluster networking. It federates independent clusters rather than joining remote machines as ordinary nodes of one cluster.
• KubeEdge, OpenYurt, Metal3, Karmada, Kairos, Cilium, and Calico are also relevant for the overlap reasons above.

Required validation for both sections: maintainers should correct the analysis and document protocol/API compatibility, feature boundaries, and collaboration opportunities. Relevant project communities should be contacted where overlap is material.

Cloud Native Landscape

Status: Verified as not currently identified

No entry matching Azure/unbounded, unbounded-cloud.io, or “Unbounded” was found in the canonical CNCF Landscape data on 2026-07-29.

Proposed application answer: No.

Owner/action: @Azure/unbounded-dev should confirm and, if appropriate, use the Landscape contribution process after the project scope and category are settled.

LFX Insights

Status: Not currently identified; owner confirmation required

No Unbounded entry was identified in the public Open Source Index on 2026-07-29.

Proposed application answer: No public LFX Insights project page identified as of 2026-07-29.

Owner/action: @Azure/unbounded-dev should confirm with Linux Foundation project services or use the LFX Insights project submission entry point if enrollment is desired.

Trademark and accounts

Status: Owner input required; no attestation can be made yet

Public assets currently identified are the GitHub repository, project website/domain, GitHub releases, and project artifacts/images published through GitHub release and registry workflows. This list is not proof of ownership or transfer authority.

The CNCF form requires agreement to donate project trademarks and accounts if accepted.

Owner: the current asset owners, Azure organization administrators, domain/registry owners, and the authorized contributing entity's open source and legal representatives. They must identify all transferable assets internally, confirm authority, approve the public attestation, and ensure designated contacts consent. Do not post access or recovery details here.

IP policy attestation

Status: Owner input required; no attestation can be made yet

The CNCF form requires the applicant to agree that the project will follow the CNCF IP Policy if accepted. This approval is distinct from the license-exception answer below.

Owner: copyright holder(s), authorized contributing entity, and qualified open source legal counsel must approve the public checkbox attestation. The repository-wide CODEOWNER team can provide the technical inventory but cannot establish legal authority.

Will the project require a license exception?

Status: Legal/owner decision required

Verified facts:

• The project's core LICENSE is MIT and names Microsoft Corporation as copyright holder.
• CNCF Charter section 11 states that new inbound and outbound code uses Apache License 2.0, while documentation is received and made available under CC BY 4.0; alternative code licenses require an exception.
• CNCF's dependency allowlist applies to third-party components and does not by itself resolve the core project's MIT license.
• The generated NOTICE inventories Go and frontend dependencies and their declared licenses; it is evidence for a full dependency review, not proof that every CNCF condition is satisfied.
• NOTICE states that it is generated from go.mod and frontend/package.json; it does not inventory the Rust dependencies in Cargo.toml and Cargo.lock, or the pinned native libfabric and OpenSSL dependencies. These surfaces must be included in the license and provenance review.

Current application answer: cannot yet be N/A. The contributing entity must choose and approve one of these outcomes: relicense the core project to Apache-2.0, obtain an applicable CNCF license exception, or establish another CNCF-approved path.

Owner: copyright holder(s), authorized contributing entity, and qualified open source legal counsel. @Azure/unbounded-dev should provide the complete code/dependency inventory; legal counsel must supply the final public answer.

Project Domain Technical Review

Status: Not completed in the public record; optional for Sandbox

The CNCF Sandbox process says a General Technical Review is voluntary, not required. The current TAG structure places data, storage, network, compute, edge, and load balancing under TAG Infrastructure, making it the strongest initial contact. TAG Workloads Foundation may also be relevant for worker execution environments and lifecycle.

Where to start: use the public TAG Infrastructure meeting, mailing list, or Slack links listed in its current TAG record, or complete the General Technical Review questions.

Owner: an approved project maintainer should present and record public meeting notes or questionnaire links. Do not list a CNCF person as a project contact until that person has engaged with and consented to being named for this application.

Application contact emails

Status: Owner input required

No contact should be inferred from commit metadata, issue activity, or generic policy addresses.

Owner/source of truth: @Azure/unbounded-dev and the project owner must designate one or more application contacts, confirm that they can represent the project, and obtain consent to publish their email addresses in the public CNCF issue.

Contributing or sponsoring entity and signatory

Status: Owner input required

Repository ownership, copyright notices, and a CLA process do not by themselves prove which legal entity will contribute the project or who has signature authority.

Owner/source of truth: the current project owner and asset owners, working with the authorized contributing entity's open source program office and legal counsel. They must provide the legal entity name, address, entity type, authorized signatory name/title, and approved email address required by the CNCF form. Keep authorization evidence internal; publish only the approved final values with consent.

CNCF contacts

Status: None verified

No public evidence reviewed establishes that a CNCF TOC or TAG leader is already familiar with and prepared to answer questions about Unbounded.

Where to find contacts: begin with TAG Infrastructure's public contacts. After a public presentation or review, ask participating leaders whether they consent to being named. Until then, leave this optional application field blank.

Additional information

Status: Proposed evidence

• The project identifies itself as early-development software for experimentation and prototyping: README.
• It has a public release pipeline and published releases, including v0.2.0.
• GoReleaser configuration generates checksums, keyless Sigstore signing for the checksum artifact, and SPDX SBOMs for configured binary archives: .goreleaser.yml. Other artifact types require separate workflow evidence and should not be implied by this file alone.
• The repository provides public support through GitHub Issues: SUPPORT.md.
• CNCF's current Sandbox marketing guidance provides a TOC mailing-list announcement and media introductions only when media contacts CNCF; it does not provide press outreach, a CNCF/TOC briefing, a CNCF blog post, or a social card. It prescribes “Cloud Native Sandbox” or “CNCF Sandbox projects” terminology: Sandbox marketing guidance.
• The Sandbox process asks projects that are primarily operators enabling another open source project to contact that project about becoming a subproject first. Unbounded contains an operator but also implements node bootstrap, machine lifecycle, bare-metal provisioning, storage, image distribution, and networking. The current project owners must still determine whether CNCF would consider it “primarily an operator” and document any upstream outreach if applicable.

Maintainers should decide which maturity, testing, security, release, and community evidence best supports the final application without overstating production readiness.

Pending actions and owners

Project maintainers (@Azure/unbounded-dev)

• Approve or correct the proposed summary, description, CNCF rationale, landscape fit, integrations, overlap, and similar-project analysis.
• Confirm the official contribution and trademark name: Unbounded Kubernetes, Project Unbounded, or another approved name.
• Confirm that only Azure/unbounded is in scope and fix stale Azure/unbounded-net links.
• Publish MAINTAINERS.md or .project data.
• Publish governance and roadmap documents.
• Confirm whether the CRDs are only implementation APIs or include an intended standard/specification.
• Collect consented adopter evidence or leave the optional field blank.
• Designate consenting application contacts.
• Decide whether to request an optional TAG Infrastructure or TAG Workloads Foundation review.

Project owner and contributing entity

• Approve pursuing CNCF contribution.
• Identify the contributing or sponsoring legal entity and authorized signatory.
• Provide the approved product/service separation statement.
• Confirm ownership and transferability of public project trademarks, domains, repositories, registries, and accounts.
• Approve the trademark/account-donation and CNCF IP-policy attestations.
• Obtain publication consent for all names, titles, addresses, and emails used in the final public application.
• Confirm whether the project is primarily an operator under the CNCF Sandbox process; if so, document outreach to the relevant upstream project.
• Acknowledge Sandbox support and marketing limits and approve public terminology/announcement plans.

Open source legal and security reviewers

• Decide whether to relicense the MIT core project to Apache-2.0 or seek a CNCF exception.
• Review all dependency licenses using NOTICE, Go modules, frontend lockfiles, container images, bundled binaries, and generated artifacts.
• Extend the dependency inventory to Cargo/Rust and native libfabric/OpenSSL components; NOTICE currently covers only Go and npm sources.
• Confirm code and asset provenance across the proposed contribution scope.
• Review SECURITY.md against CNCF project security expectations.
• Resolve or explicitly risk-assess the documented disabled SSH host-key verification before submission.

External users and adjacent communities

• Validate the problem statement and differentiator.
• Provide adopter statements only with organizational approval.
• Review overlap and collaboration opportunities with Cluster API, KubeEdge, OpenYurt, Metal3, Submariner, Karmada, Kairos, Liqo, Karpenter, and CNI communities.

Submission gate

• Every mandatory CNCF form field has either an approved answer or an approved public URL.
• Maintainers have approved all technical statements.
• The contributing entity has approved all legal, IP, trademark, transfer, contact, and signatory statements.
• Every named person has consented to public publication.
• The complete final cncf/sandbox issue has been reviewed without submitting it.
• The final CNCF Sandbox application is submitted and linked here.
• Contribution Agreement status and TOC outcome are tracked here using only public-safe information.

Do not describe the project as donated, contributed, accepted, or an official CNCF project until the TOC has approved the application and the Contribution Agreement has been signed.