Kubernetes License check for Kubernetes Proxies#24543
Conversation
espadolini
left a comment
espadolini
left a comment
There was a problem hiding this comment.
You can just use (*TeleportProcess).getClusterFeatures instead of running your own periodic check; it gets updated whenever any service in the process (re)connects to the auth. Up to you if you think you should check it every time (by passing some closure) or only whenever we initialize the forwarder for the first time.
This PR ensures that a given Teleport root cluster is licensed for Kubernetes access when forwarding credentials to leaf clusters. Previously, the root Kube proxy would call auth server to generate a new cert-key pair with the user identity and during the call Auth ensured that it was licensed for Kubernetes usage. Given the recent developments for #22533, the call mentioned was removed and it's now possible for a root enterprise cluster to forward requests to a OSS leaf cluster without validating its license. Auth server already enforces Kubernetes license for Kubernetes service when it tries to heartbeat the cluster. If the cluster is not properly licensed, it's not possible to register kubernetes clusters. Part of #22533
tigrato
force-pushed
the
tigrato/ensure-license-kube-proxies
branch
from
b0f1cd7 to
a69a09d
Compare
tigrato
force-pushed
the
tigrato/ensure-license-kube-proxies
branch
from
a69a09d to
f913660
Compare
tigrato
force-pushed
the
tigrato/ensure-license-kube-proxies
branch
from
f913660 to
90321e7
Compare
| // If the cluster is not licensed for Kubernetes, return an error to the client. | ||
| if !f.cfg.ClusterFeatures().Kubernetes { | ||
| // If the cluster is not licensed for Kubernetes, return an error to the client | ||
| // but in a way that the code is translated to 500 error code. |
There was a problem hiding this comment.
If this isn't too much hassle, it might be worth testing that the error is truly translated to a 500 error code.
There was a problem hiding this comment.
Should this be a 500 or a 403 (Forbidden)?
There was a problem hiding this comment.
We seem to return trace.AccessDenied (which becomes a 403 in http) whenever some license feature check fails, which seems appropriate here. Is there a kube-specific reason why it should not be returned as an access denied?
There was a problem hiding this comment.
I preferred 500 to distinguish from cases where the user does not have access but reverted to Forbidden
public-teleport-github-review-bot
Bot
removed the request for review
from probakowski
4 participants
This PR ensures that a given Teleport root cluster is licensed for Kubernetes access when forwarding credentials to leaf clusters.
Previously, the root Kube proxy would call auth server to generate a new cert-key pair with the user identity and during the call Auth ensured that it was licensed for Kubernetes usage. Given the recent developments for #22533, the call mentioned was removed and it's now possible for a root enterprise cluster to forward requests to a OSS leaf cluster without validating its license.
Auth server already enforces Kubernetes license for Kubernetes service when it tries to heartbeat the cluster. If the cluster is not properly licensed, it's not possible to register kubernetes clusters.
Part of #22533