-
Notifications
You must be signed in to change notification settings - Fork 1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ClusterRole permissions are too broadly scoped? #3724
Comments
Probably, not at the moment. We would need to re-work how models are fetched from storage.
Perhaps, the most notable use of secrets in KServe is for giving storage credentials, so that models can be downloaded. For example, for S3, these are the docs: https://kserve.github.io/website/latest/modelserving/storage/s3/s3/ Secrets are inspected, first, to understand what storage is being used (S3, GCS, HTTP, etc.). Also, annotations contain any storage-specific configurations and those are passed to the storage-initializer container in the model pod to download models. Thus, KServe needs to be able to read the secrets on the namespaces where models are deployed. Since we don't know what are those namespaces, we give the privilege over the cluster. If you need to limit that privilege only to some namespace, I think you can... Just check what are the namespaces where you will be deploying InferenceServices and give the privileges just to those... That said, I'm not fully familiar with all the code base. I just know pulling models is the most notable case. There may be other features that would require reading secrets. Yet, my guess is that, anyway, reading secrets across namespaces may not be required. So, well... try limiting the privilege to those namespaces where you are using KServe and check if that works. |
/kind question
Hello team,
I have a general question. I noticed that the permissions defined in the kserve-manager-role for kserve-controller-manager are broadly scoped. For example:
This broad scope poses a security risk for us due to our compliance requirements. Is there a specific reason the role needs cluster-wide access to secrets? or can it be scoped down to certain namespaces? please advise
Thank you
The text was updated successfully, but these errors were encountered: