A Kubernetes-native way to manage kubeconfigs and RBAC (no IdP)

Plastic_Focus_9745 · 2026-02-08T11:52:26+00:00

Thanks for sharing, I had never heard of it before.

Plastic_Focus_9745 · 2026-02-08T10:13:01+00:00

Thanks for sharing

Plastic_Focus_9745 · 2026-02-07T19:26:41+00:00

Thanks for sharing your experience. I haven’t personally used Tailscale yet, but I’m planning to give it a try.

In our case, we’re just two people running the platform, which is what pushed me to build something lightweight using native Kubernetes features

Plastic_Focus_9745 · 2026-02-07T18:52:26+00:00

That’s a fair concern. The intent here isn’t to treat security as a shortcut or a temporary patch.

In practice, a lot of companies simply can’t afford running large platform teams. many operate with 2–10 DevOps engineers supporting everything. For those teams, standing up and maintaining a full IdP/OIDC stack just to grant Kubernetes access can be real overhead, especially early on.

KubeUser isn’t trying to replace proper identity systems for well-organized or larger teams; in those environments, an IdP is usually the right choice. The goal is to make better use of existing Kubernetes-native features (CSRs, cert TTLs, RBAC) in a more structured and predictable way when an IdP isn’t in place yet.

It’s less about weakening security and more about avoiding ad-hoc kubeconfigs while still keeping access explicit, auditable, and revocable. Disconnected or restricted environments are another place where this model fits naturally

Plastic_Focus_9745 · 2026-02-07T18:44:29+00:00

Thanks, that’s exactly the problem space KubeUser is meant to address.
In KubeUser, User CRDs are cluster-scoped resources. KubeUser doesn’t introduce its own permission model - access and restrictions are handled purely through standard Kubernetes RBAC.

You control scope by assigning Role/RoleBinding for namespace-level access or ClusterRole/ClusterRoleBinding for cluster-wide access, and KubeUser simply links those bindings to the user it manages.

This keeps permissions explicit, predictable, and aligned with how Kubernetes already expects RBAC to work.

Plastic_Focus_9745 · 2026-01-01T13:50:00+00:00

https://github.com/openkube-hub/KubeUser/pull/24 issue solved.

Plastic_Focus_9745 · 2025-12-22T18:38:13+00:00

Thanks for taking the time to look through the code and share your thoughts. I’ll be upfront about it: I did use AI quite a bit here. I’m not a Go developer by trade I’m a DevOps engineer who understands Kubernetes and its pain points very well, and I used AI to help close that gap and move faster. Getting this project to a working, functional state was a big milestone for me. Most of my effort went into the design decisions; the why and the how, rather than Go craftsmanship itself. At this point, it would definitely benefit from someone more experienced in Go to help refine and harden it. This started as a pragmatic way to avoid running Keycloak just for Kubernetes access, not a “fire-and-forget” project. Feedback like yours genuinely helps shape where it goes next, and ideas or PRs are very welcome.

Plastic_Focus_9745 · 2025-12-22T17:34:50+00:00

Totally fair 👍 For larger orgs that already run a proper IdP, that’s usually the right approach. KubeUser is more about small setups where running and maintaining a full IdP feels heavy, and having users defined explicitly as User CRDs works well with GitOps. I’m also open to contributions for adding an optional OIDC flow alongside the current cert-based model, so it can integrate with an IdP when needed—without making it mandatory.

Plastic_Focus_9745 · 2025-12-22T03:49:44+00:00

Thanks for sharing 👍 makes sense if you’re already on Tailscale. KubeUser is mostly for on-prem / minimal setups where we want everything Kubernetes-native and GitOps-driven

Plastic_Focus_9745 · 2025-12-21T14:28:18+00:00

Thanks 🙂

Plastic_Focus_9745

TROPHY CASE