Scouttlo
All ideas/devtools/Plataforma SaaS que facilite la integración, gestión y actualización dinámica de credenciales multi-clúster basada en ClusterProfile y KEP-5339, con soporte para plugins de credenciales externos y alineación con estándares upstream.
GitHubB2Bdevtools

Plataforma SaaS que facilite la integración, gestión y actualización dinámica de credenciales multi-clúster basada en ClusterProfile y KEP-5339, con soporte para plugins de credenciales externos y alineación con estándares upstream.

Scouted 8 hours ago

6.8/ 10
Overall score

Turn this signal into an edge

We help you build it, validate it, and get there first.

Go from idea to plan: who buys, what MVP to launch, how to validate it, and what to measure before spending months.

Extra context

Learn more about this idea

Get a clearer explanation of what the opportunity means, the current problem behind it, how this idea solves it, and the key concepts involved.

Share your email to view this expanded analysis.

Score breakdown

Urgency8.0
Market size7.0
Feasibility7.0
Competition5.0
Pain point

Falta de integración nativa con ClusterProfile y su modelo de proveedor de credenciales en Sveltos limita la interoperabilidad y seguridad en la gestión multi-clúster.

Who'd pay for this

Equipos de operaciones de TI, DevOps y plataformas en empresas que gestionan múltiples clusters Kubernetes y buscan mejorar seguridad y compatibilidad con ecosistemas estándar.

Source signal

"By adopting ClusterProfile + KEP-5339, Sveltos could connect to managed clusters using short-lived credentials obtained via a pluggable exec flow (aligned with kubeconfig’s external credential provider protocol)."

Original post

Feature Request: Support native ClusterProfile integration (KEP-5339) in Project Sveltos

Published: 8 hours ago

Repository: projectsveltos/sveltos Author: kahirokunn ### Summary First of all, thank you for building and maintaining such a wonderful product! Sveltos is a truly great project, and we really appreciate the value it brings to the multi-cluster community. 🙏✨ We would like to humbly propose adding **native integration with the ClusterProfile API** (SIG Multicluster) and its **credential provider plugin model [(KEP-5339)](https://github.com/kubernetes/enhancements/tree/master/keps/sig-multicluster/5339-clusterprofile-plugin-credentials)**. Today Sveltos does not consume ClusterProfile, so it can’t leverage the standardized **`status.credentialProviders`** and the emerging Cluster Inventory ecosystem. By adopting ClusterProfile + [KEP-5339](https://github.com/kubernetes/enhancements/tree/master/keps/sig-multicluster/5339-clusterprofile-plugin-credentials), Sveltos could connect to managed clusters using short-lived credentials obtained via a pluggable **exec** flow (aligned with kubeconfig’s external credential provider protocol). This one change could potentially address—and allow closing—the following issues all at once: * #430 * #445 * #440 ### Background (why this is a re-proposal) Previously, I opened [an earlier proposal for ClusterProfile integration](https://github.com/projectsveltos/sveltos/issues/430). At that time, ClusterProfile did not yet have the **`credentialProviders`** specification; it could only hold kubeconfigs. In that state, there was no meaningful functional difference between a `SveltosCluster` resource and a `ClusterProfile`, so the integration was understandably declined. However, the situation has since changed significantly: * **`credentialProviders`** has been added to ClusterProfile, and implementations are landing. * At recent events such as **KubeCon**, we observed engineers from providers like **GCP and AWS actively aligning with ClusterProfile**. * This signals that ClusterProfile is becoming the upstream standard point of integration for credentials and inventory. Given this, we believe that following this evolution early would carry meaningful benefits for Sveltos in terms of **ecosystem alignment, security posture, and broader adoption**. It could help Sveltos capture an even stronger share in the multi-cluster management space. With the greatest respect, we would like to kindly **re-propose native ClusterProfile integration**, this time backed by the new `credentialProviders` functionality and its supporting ecosystem. ### Why this matters (Motivation) * **Ecosystem alignment:** ClusterProfile is becoming the common substrate for multi-cluster inventory and access. Without compatibility, Sveltos risks divergence from upstream conventions and tooling. * **Security posture:** KEP-5339 places **no secrets** in ClusterProfile. Credentials are obtained **out-of-tree** via an exec plugin chosen at deploy time, enabling short-lived tokens, SSO/WIF/OIDC, and provider-agnostic flows. * **Operational flexibility:** The plugin model avoids baking cloud-specific SDKs into Sveltos. Platform teams can pick/upgrade credential plugins independently of Sveltos releases. * **Ease of integration:** There is a **Go library implementation** in the Cluster Inventory project designed to construct the cluster connection info from `ClusterProfile.status` and invoke credential plugins. This keeps Sveltos changes minimal while providing maximum interoperability. → [Implementation PR: Define plugin interface and consumer library](https://github.com/kubernetes-sigs/cluster-inventory-api/pull/17) ### Suggested direction (High-level) Would you consider: * **Adopting the ClusterProfile API** as a first-class inventory source in Sveltos? * **Honoring `status.credentialProviders`** to discover the cluster’s accepted credential type(s) and connection parameters? * **Using the provided Go package** from the Cluster Inventory project to obtain short-lived credentials via the **exec plugin** protocol (KEP-541 compatible I/O), then building the client config to talk to the target cluster? > Note: This request is intentionally framed as an **integration and alignment proposal**, not prescribing a specific internal design or plugin set. The goal is to let Sveltos naturally plug into the Cluster Inventory & ClusterProfile ecosystem and benefit from provider-maintained exec plugins. ### Potential benefits to Project Sveltos * **Closes three open asks at once:** could unblock #430, #445, #440 by standardizing how Sveltos discovers clusters and obtains credentials. * **Future-proofing:** aligns with upstream multi-cluster APIs and avoids bespoke inventory/cred flows. * **Provider-neutral:** works equally well with GKE, EKS, AKS, on-prem, or any environment that supplies an exec credential plugin. * **Cleaner UX:** users point Sveltos at ClusterProfiles; Sveltos handles the rest through the standard plugin interface. ### Backward compatibility * This could be added **alongside current Sveltos mechanisms**. Users can opt into ClusterProfile-based integration without breaking existing flows. ### Open questions (for discussion) * Which credential types should be “known” by default vs. entirely user-configured? * How should Sveltos surface errors/observability around plugin execution and token acquisition? * What’s the minimal surface to declare ClusterProfile support (read-only of `status` vs. deeper interactions)? ### References * [KEP-5339: Plugin for Credentials in ClusterProfile](https://github.com/kubernetes/enhancements/tree/master/keps/sig-multicluster/5339-clusterprofile-plugin-credentials) * [Define plugin interface and consumer library by qiujian16 · Pull Request #17 · kubernetes-sigs/cluster-inventory-api](https://github.com/kubernetes-sigs/cluster-inventory-api/pull/17) * [Slack thread](https://kubernetes.slack.com/archives/C09R1PJR3/p1747786073248159) * [KEP-4322: ClusterProfile API](https://github.com/kubernetes/enhancements/blob/master/keps/sig-multicluster/4322-cluster-inventory/README.md) * [ClusterProfile API Overview - SIG Multicluster](https://multicluster.sigs.k8s.io/concepts/cluster-profile-api/) * [\[PUBLIC\] ClusterProfile Credentials via Plugin - Google Slides](https://docs.google.com/presentation/d/1v5-J-kFJ3TSpKqSraHcYkCz2NG7cNnYpq0ISF85wNMU/edit?pli=1&slide=id.g34154765f26_2_31#slide=id.g34154765f26_2_31)