-
Notifications
You must be signed in to change notification settings - Fork 61
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
Prevent InferenceGraphs to refer to other namespaces #357
base: incubating
Are you sure you want to change the base?
Prevent InferenceGraphs to refer to other namespaces #357
Conversation
Skipping CI for Draft Pull Request. |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: israel-hdez The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
In ODH we prefer isolation between projects/namespaces. For InferenceGraph CRD, KServe doesn't do any validation on the used hostname when a node/step is using `serviceUrl`. This can break isolation between projects, because it is allowed to specify a hostname from another namespace. This adds a validating webhook to prevent the user from using an in-cluster hostname that would be referring to a different namespace from the created/updated InferenceGraph. Signed-off-by: Edgar Hernández <[email protected]>
8f2421c
to
8fe55be
Compare
// ValidateCreate implements webhook.CustomValidator so a webhook will be registered for the type InferenceGraph. | ||
func (v *InferenceGraphCustomValidator) ValidateCreate(_ context.Context, obj runtime.Object) (admission.Warnings, error) { | ||
inferencegraph, ok := obj.(*servingv1alpha1.InferenceGraph) | ||
if !ok { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
what are the odds of it return a false positive?
is there another InferenceGraph type that might conflict with the KServe one?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My understanding is that this is defensive coding (this is from scaffolding).
The ValidatingWebhookConfiguration
is external to the controller. So, users (or devs? 🙂) may misconfigure it, and you may receive here some other Kind (Pods, Deployments, or any other resource). I think the type assertion is for those (rare) cases.
About a conflicting type, I'm not really sure if it is possible. Maybe if it is coming from a different API Group? IDK.... I'm not even sure how controller-runtime will be handling that case.
@@ -30,10 +30,10 @@ import ( | |||
|
|||
istiov1beta1 "istio.io/client-go/pkg/apis/security/v1beta1" | |||
corev1 "k8s.io/api/core/v1" | |||
metav1 "k8s.io/apimachinery/pkg/apis/meta/v1" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure I'm following why this file was changed?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
goimport pattern, mostly likely.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It is just my preference of having on the last group of imports only only the ones from "this" package. The k8s.io/apimachinery/pkg/apis/meta/v1
is not a package from this repo, so I moved up.
Description
In ODH we prefer isolation between projects/namespaces. For InferenceGraph CRD, KServe doesn't do any validation on the used hostname when a node/step is using
serviceUrl
. This can break isolation between projects, because it is allowed to specify a hostname from another namespace.This adds a validating webhook to prevent the user from using an in-cluster hostname that would be referring to a different namespace from the created/updated InferenceGraph.
Fixes: https://issues.redhat.com/browse/RHOAIENG-17828
How Has This Been Tested?
TODO
Merge criteria: