I'm currently designing a system for a private Kubernetes cluster that doesn't allow inbound access. This cluster will run a long-lived connector pod that sends outbound requests to a central backend to perform kubectl commands. Here's the flow I've set up: a user triggers a /cluster/register call, which prompts the backend to generate a cluster_id and a secret. Then, it creates a Keycloak client with the name conn- and embeds these details into the connector manifest. The connector uses OAuth2 client-credentials to authenticate with Keycloak and receives a JWT, which is then used for endpoints like /heartbeat and /callback that the backend validates using Keycloak's JWKS. While this system works, I'm unsure whether Keycloak is truly necessary since /cluster/register is secured and only allows trusted users to onboard clusters. The backend is already minting and binding machine identities. Keycloak does offer centralized revocation and rotation features. However, I'm questioning whether it adds significant security or just complicates things compared to a simpler backend-generated secret or using mTLS/SPIFFE. I'd appreciate some thoughts on whether this is a sensible authentication strategy for outbound-only connectors in private clusters, or if it's just adding unnecessary complexity.
3 Answers
It really depends on what kind of future changes you might foresee. If you anticipate scaling or more users needing access, having Keycloak for centralized identity management could save headaches later. But if you can manage with simpler auth methods and are confident in your security measures, it sounds like a valid path! Just weigh the trade-offs of ease vs. potential future needs.
I get your concerns! The entire kubectl execution happening within the connector pod using the cluster's native RBAC sounds secure, but running that flow in general raises some flags. It's important to keep your security tight, especially when dealing with cluster communication. Maybe consider if your system could be simplified without Keycloak? If you're handling the identities on the backend, you might not need an extra layer unless you need those centralized features for managing credentials.
I think you're on the right track! If your backend is strictly managing the credentials and ensuring that only trusted users can access /cluster/register, you might not need Keycloak as a middleman. Using a simple backend-issued secret could streamline operations. Plus, mTLS or SPIFFE is definitely a solid alternative for secure connections if Keycloak feels overly complex. Just ensure you’re comfortable with the security of whichever model you choose.
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