How to secure authToken of the managed clusters ?

[wengyao04]

Please provide an in-depth description of the question you have:

Karmada provides two mode to register the managed clusters: Push mode and Pull mode.

• In the Pull mode, it creates a service account and bind it to the admin clusterrole, and use this token as authToken to connect the managed cluster
• In the push mode, we use similar way to create the authToken and use it to connect managed clusters

However, it introduces potential security issue. For example, if the authToken is leaked, we need to

• delete that clusterrolebinding
• create a new service account and bind to the admin clusterrole
• update the authToken using the token from the new sa

It is still manageable, but it would be preferable that Karmada can support short live authToken. One possible solution is to allow user pass the custom RoundTripper in the kubeclient config (rest config), where users can customize the callback to refresh the short live token. But I am not quite show how http2 long polling works with short live token (mainly for watch endpoint)

Could we have your suggestion ? Thank you !

[wengyao04]

In our use case, we want

• to exchange a short live JWT token (from a Company role account) to another short live JWT toke (by calling our identity exchange server)
• enable karmada api server authentication-webhook (we enable --authentication-token-webhook-config-file=/etc/webhook/config). It verifies the exchanged short live JWT token

We want to check if karmada can support customized round tripper when set up kubeclient of the managed cluster. For us, we will exchange the identity token in the customized round tripper.

This kubeclient with customized round tripper should work with get/update/create/delete, but I am not quite sure if it works for watch. What happens if the token is expired for the watch endpoint ?

It's probably ok, My understanding is that api watch -> call ETCD watch endpoint

In etcd v3, it is a http2 long polling (grpc). https://etcd.io/docs/v3.2/learning/auth_design/#authentication The authentication is per connection not per rpc, because there is no per rpc authentication. Once authentication is established during the connection setup, the connection is established.

The client connection used to request the authentication token is typically thrown away; it cannot carry the new token's credentials. This is because gRPC doesn't provide a way for adding per RPC credential after creation of the connection (calling grpc.Dial()). Therefore, a client cannot assign a token to its connection that is obtained through the connection. The client needs a new connection for using the token.