-
Notifications
You must be signed in to change notification settings - Fork 918
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
Add Model Registry UI Integration Test #3000
Add Model Registry UI Integration Test #3000
Conversation
I've tested the changes in a kind cluster in which we have kubeflow installed, but unfortunately, following the instructions on https://github.com/kubeflow/manifests?tab=readme-ov-file#oauth2-proxy gets the pod on waiting, so I haven't been able to test it with a JWT, could you guys help me out here? (or provide a cluster to test the script) @tarilabs @juliusvonkohout |
- name: Dry-run KF Model Registry REST API UI | ||
run: | | ||
echo "Dry-run KF Model Registry REST API..." | ||
export KF_TOKEN="$(kubectl -n default create token default)" |
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.
Thank you for the PR. All model registry pods should live in the Kubeflow namespace. and AFAIK only default-editor from the example user namespace should be able to reach it. Everything else is probably a security breach.
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.
We should even have a negative test that verifies that it fails with no token or the wrong token
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.
Ok, so we should test first with a valid token (default-editor) and the with an invalid token? And wouldn't be that an issue with istio config?
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.
Here you can see an example of verifying that not anyone can access stuff with an illegal token
- name: List notebooks over API with unauthorized SA Token |
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.
Ok, I got what you suggested, we were using a healtcheck for smoke test that's not checking the headers. I've just tested it with a proper endpoint, I've added both test for UI as you suggested and it worked in my local tests.
cc @tarilabs maybe you wanna take a look at this.
@@ -80,3 +88,9 @@ jobs: | |||
echo "Dry-run KF Model Registry REST API..." | |||
export KF_TOKEN="$(kubectl -n default create token default)" |
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.
Thank you for the PR. All model registry pods should live in the Kubeflow namespace. and AFAIK only default-editor from the example user namespace should be able to reach it. Everything else is probably a security breach.
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.
Thank you for the PR. All model registry pods should live in the Kubeflow namespace. and AFAIK only default-editor from the example user namespace should be able to reach it. Everything else is probably a security breach.
Circling back to this conversation, we brought it yesterday in the MR community, are we supossed to change this, @tarilabs and the rest of the team were confused since this has been working just fine as it was, is it requried by us to change both tests?
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.
Yes, the token from the default namespaces should fail due to subjectaccessreview and only the token from a proper kubeflow namespace with the RBAC permissions should work.
af7ec63
to
552f835
Compare
Thank you for the PR and we will find a solution. |
For example
might be missing. |
The JWTs are working in our GHA and ran successfully a few minutes ago. Are you sure that you are on the latest master branch? Did you start with a fresh kind cluster according to the installation guidelines / GHA scripts? |
Ok, I'm sorry @juliusvonkohout I'm getting back to this right now. Yes, I've recreated the cluster and it seems to be working now, I tested the current config and it seems to be working fine. We can close this thread since I tested it and it's working. |
552f835
to
282ab35
Compare
@juliusvonkohout following up this conversation: #3000 (comment) I think we should scope this PR to the MR UI tests, I've pinged MR so they are aware of these changes and maybe they can do a follow up in the rest of the smoke tests, would it be fine doing it that way? |
2037e37
to
9651fb2
Compare
Signed-off-by: Lucas Fernandez <lucasfernandezaragon@gmail.com>
9651fb2
to
c5bf37b
Compare
Ok @juliusvonkohout tests are passing, I think the changes that you suggested are working as expected: https://github.com/kubeflow/manifests/actions/runs/13425225054/job/37506788756?pr=3000 |
Thank you very much. @tarilabs @lucferbux you should take a look at kustomize components instead of overlays to make your life easier. I think they would simplify your manifests structure and maintenance effort. /lgtm |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: juliusvonkohout 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 |
Pull Request Template for Kubeflow Manifests
✏️ Summary of Changes
📦 Dependencies
🐛 Related Issues
✅ Contributor Checklist