[Sandbox] kube-bind

[cnvergence]

Project summary

kube-bind is an open source project that enables Kubernetes service providers and consumers in distinct clusters to share and bind custom API resources across cluster boundaries.

Project description

kube-bind is an open source Kubernetes project that provides better support for service providers and consumers residing in distinct Kubernetes clusters. It introduces a binding mechanism that allows operators running in one cluster (the service provider) to offer custom APIs and controllers, while consumers in separate clusters can bind to those services and use the custom resources as if they were native to their own cluster.

The project solves a fundamental multi-tenancy and multi-cluster challenge: today, extending Kubernetes with custom controllers requires deploying the controller and its CRDs into the same cluster, making multi-cluster or SaaS-style service delivery difficult. kube-bind decouples the service provider's control plane from the consumer's cluster, allowing a single provider to serve many consumer clusters cleanly and securely.

kube-bind is built on top of standard Kubernetes primitives (CRDs, controllers, RBAC) and is designed to be cloud native from the ground up. It enables use cases such as managed database-as-a-service, managed Kafka, or any custom Kubernetes API offered as a service to multiple tenant clusters—without requiring those tenants to run the underlying controllers themselves.

kube-bind has a native, first-class integration with kcp via a dedicated kcp backend provider (contrib/kcp/). In this mode, kcp workspaces are treated as independent clusters, and kube-bind leverages kcp's APIExport/APIBinding primitives to expose and bind APIs across workspaces — enabling multi-tenant, SaaS-style API sharing with full workspace isolation and RBAC.

Org repo URL (provide if all repos under the org are in scope of the application)

https://github.com/kube-bind

Project repo URL in scope of application

https://github.com/kube-bind/kube-bind

Additional repos in scope of the application

N/A

Website URL

https://kube-bind.io

Roadmap

https://github.com/kube-bind/kube-bind/blob/main/ROADMAP.md

Roadmap context

N/A

Contributing guide

https://github.com/kube-bind/kube-bind/blob/main/CONTRIBUTING.md

Code of Conduct (CoC)

https://github.com/kube-bind/kube-bind/blob/main/code-of-conduct.md

Adopters

https://github.com/kube-bind/kube-bind/blob/main/ADOPTERS.md

Maintainers file

https://github.com/kube-bind/kube-bind/blob/main/OWNERS

Security policy file

https://github.com/kube-bind/kube-bind/blob/main/SECURITY.md

Standard or specification?

N/A

Business product or service to project separation

N/A

Why CNCF?

kube-bind is a Kubernetes-native project addressing a core multi-cluster use case. Contributing to the CNCF ensures neutral governance, broader community adoption, and alignment with the cloud-native project ecosystem. CNCF membership provides access to infrastructure, marketing, security audits, and a community of practitioners who benefit most from this technology.

Benefit to the landscape

kube-bind fills a gap in the CNCF landscape by providing a standardised, open mechanism for cross-cluster API and service binding. It enables a new class of multi-cluster SaaS-style Kubernetes service providers and enriches the multi-cluster story alongside projects like Cluster API, Open Cluster Management, and others.

Cloud native 'fit'

kube-bind is entirely Kubernetes-native: it is built using CRDs, controllers, and RBAC, and follows operator patterns. It is deployed as a Kubernetes controller/operator, uses kubeconfig-based authentication, and integrates naturally into any standard Kubernetes cluster.
It fits within the "Orchestration & Management" layer of the CNCF landscape, specifically in the multi-cluster and service binding space.

Cloud native 'integration'

• kubernetes: kube-bind is built directly on Kubernetes CRDs, controllers, and RBAC.
• kcp (kcp-dev/kcp, CNCF Sandbox): kcp provides the multi-tenant control plane and workspace isolation layer; kube-bind provides the cross-workspace API service binding mechanism on top of it. The two projects are complementary — kube-bind is designed to work both with plain Kubernetes clusters and with kcp, gaining significantly more power in the latter case.

It will complement many other projects, as for helping provider clusters to serve anything as a service to the consumer clusters, here are some examples with Crossplane, cert-manager and kro - https://docs.kube-bind.io/main/usage/integrations

Cloud native overlap

N/A

Similar projects

N/A

Landscape

Not currently listed.

Trademark and accounts

• If the project is accepted, I agree to donate all project trademarks and accounts to the CNCF

IP policy

• If the project is accepted, I agree the project will follow the CNCF IP Policy

Will the project require a license exception?

No – kube-bind is licensed under the Apache License 2.0.

Project "Domain Technical Review"

No response

Application contact email(s)

karol.szwaj@gmail.com,mangirdas@judeikis.lt

Contributing or sponsoring entity signatory information

Name	Signatory name	Email address
Joachim Kraftmayer	CLYSO	joachim.kraftmayer@clyso.com
Mirza Kopic	SAP	mirza.kopic@sap.com
Sebastian Scheele	Kubermatic	scheeles@kubermatic.com

CNCF contacts

Mario Fahlandt (@mfahlandt) TAG Operational Resilience Chair - mfahlandt@pixel-haufen.de

Additional information

kube-bind intentionally exists as a standalone project to kcp, for keeping a clear separation of concerns - kcp focuses on control plane multi-tenancy and workspace isolation.
Merging the two would pin kube-bind's adoption to kcp, limiting its applicability across the broader Kubernetes ecosystem.

By staying independent, kube-bind can evolve its binding semantics at its own pace, serve vanilla Kubernetes users, and ideally evolve the internal protocol to support many different backend providers (kubernetes - default one and kcp are already there).

Kubecon NA 2022 talk about kube-bind: https://www.youtube.com/watch?v=Uv0ivz5xej4
Kubernetes Slack channel link

[angellk]

/vote

[git-vote]

Vote created

@angellk has called for a vote on [Sandbox] kube-bind (#464).

The members of the following teams have binding votes:

Team
@cncf/cncf-toc-voters

Non-binding votes are also appreciated as a sign of support!

How to vote

You can cast your vote by reacting to this comment. The following reactions are supported:

In favor	Against	Abstain
👍	👎	👀

Please note that voting for multiple options is not allowed and those votes won't be counted.

The vote will be open for 2months 30days 2h 52m 48s. It will pass if at least 66% of the users with binding votes vote In favor 👍. Once it's closed, results will be published here as a new comment.

[kgamanji]

Feedback from the TOC sandbox review:

• The project name might need to be changed to follow the naming convention as all CNCF projects are subject to the Trademark Usage Policies set by the Linux Foundation. This is addressing the "kube-" part of the naming. We also found that "-bind" part is not fully descriptive of the project capabilities, so we advise reconsidering a renaming of this part too.

[mjudeikis]

Feedback from the TOC sandbox review:

• The project name might need to be changed to follow the naming convention as all CNCF projects are subject to the Trademark Usage Policies set by the Linux Foundation. This is addressing the "kube-" part of the naming. We also found that "-bind" part is not fully descriptive of teh proejct capabilities, so we advise reconsidering a renaming of this part too.

Thanks for this! If we get a positive vote result, rebranding is not an issue. Or would this need to happen before the end of the votes?

[kgamanji]

This would be a requirement for sandbox inclusion. So not a blocker for the vote, but a must have for the formal inclusion.