I'm working on a design for a private Kubernetes cluster that communicates outbound to a central backend via a long-lived connector pod. When a user registers the cluster, the backend generates a unique cluster ID and secret, sets up a Keycloak client, and injects these details into the connector's manifest. The connector uses OAuth2 client credentials to authenticate with Keycloak, receives a JWT, and then utilizes this JWT for authenticating to backend endpoints like /heartbeat and /callback, which are verified by Keycloak's JWKS. While this method is functional, I'm starting to question whether using Keycloak is truly necessary, especially since the registration endpoint is protected, meaning only trusted users can onboard clusters. Keycloak offers centralized token revocation and rotation, but I'm uncertain if it adds enough security compared to a simpler backend-issued secret or using an mTLS/SPIFFE model. I'm seeking feedback on whether this authentication approach is reasonable for outbound-only connectors in private clusters or if it introduces unnecessary complexity.
3 Answers
Why not consider Flux for this scenario? Instead of going through complex auth setups, you could let GitHub or GitLab handle authentication. This way, you could give certain users access to view the status of deployments without them being able to make changes.
My concern is that creating a new Keycloak client for each connection seems excessive and could hurt performance. Could you streamline things by having a single client and issuing short-lived tokens? If the aim is unified identity across pods, tools like HashiCorp Vault might provide what you need as they offer JWT identity tokens based on service accounts.
Using layers of security is always wise. Kubernetes utilizes OIDC for a reason, and your implementation with Keycloak seems valid. It resembles what's found in managed identity systems in cloud environments. Just ensure you're clear about your threat model—like protecting against impersonation and managing the operation of Keycloak itself. Also, think about what could go wrong. Having a solid backup plan if Keycloak fails is crucial.
Related Questions
Can't Load PhpMyadmin On After Server Update
Redirect www to non-www in Apache Conf
How To Check If Your SSL Cert Is SHA 1
Windows TrackPad Gestures