Enable model-registry with UI by default

[Raakshass]

Summary of Changes

This PR enables the Model Registry server, UI, and demo catalog components in the default Kubeflow installation (example/kustomization.yaml), updates the Central Dashboard to include a Model Registry menu entry, adds README documentation, and adds CI tests with model CRUD verification.

Components added to example/kustomization.yaml:

• Model Registry Server with PostgreSQL database (overlays/postgres)
• Model Registry Istio networking / VirtualService (options/istio)
• Model Registry UI with Istio integration (options/ui/overlays/istio)
• Model Catalog demo (options/catalog/overlays/demo)

Central Dashboard:

• Updated applications/centraldashboard/overlays/oauth2-proxy/kustomization.yaml to use istio base overlay instead of kserve
• Added patches/configmap.yaml with Model Registry menu entry alongside existing KServe Endpoints entry

CI / Testing:

• Added tests/model_registry_install.sh — installs Model Registry server, UI, database, Istio networking, and catalog
• Added tests/model_registry_test.sh — CRUD tests (creates RegisteredModel, ModelVersion, ModelArtifact, verifies listing) + Istio gateway auth tests
• Updated .github/workflows/model_registry_test.yaml to run install and test scripts

Documentation:

• Added "Model Registry" section to README.md under "Install Individual Components"

Dependencies

No external dependencies. Uses existing upstream manifests from applications/model-registry/.

Related Issues

Closes #3047

[github-actions]

Welcome to the Kubeflow Manifests Repository

Thanks for opening your first PR. Your contribution means a lot to the Kubeflow community.

Before making more PRs:
Please ensure your PR follows our Contributing Guide.
Please also be aware that many components are synchronizes from upstream via the scripts in /scripts.
So in some cases you have to fix the problem in the upstream repositories first, but you can use a PR against kubeflow/manifests to test the platform integration.

Community Resources:

• CNCF Slack channels: https://www.kubeflow.org/docs/about/community/#kubeflow-slack-channels
• Community meetings: https://www.kubeflow.org/docs/about/community/

Thanks again for helping to improve Kubeflow.

[Raakshass]

hey @juliusvonkohout can you just review this pr.
Thank you

[juliusvonkohout]

hey @juliusvonkohout can you just review this pr. Thank you

I am still on vacation, but maybe @tarilabs can help sooner.

Are you sure that the catalog and everything is properly exposed in the dashboard UI @Raakshass? Do you mind sharing screenshots? Think of how we expose Kserve models web application in the dashboard.

[juliusvonkohout]

@Raakshass are you sure that it is properly exposed similar to the kserve models web application (endpoints) in the dashboard UI? I would like to see screenshots of the dashboard and the actual UI changes you made. Please check the original issue and related ones in the Model-Registry git repository. I think you are missing 80% of the work.

[tarilabs]

could you kindly share screenshot with @ederign as Julius suggested please on this thread?

[sameerdattav]

Hey @ederign @juliusvonkohout @tarilabs,

I’ve been following this PR and the related issue for a few days and thought I could jump in to help move things forward.
So I went ahead and opened a fresh PR that includes all the required changes along with validation screenshots:

#3323

I’d really appreciate a review when you get a chance. Thanks!

[ederign]

I've commented on #3323

[Raakshass]

Hi @juliusvonkohout @tarilabs — addressing the feedback about showing the actual dashboard/UI change.

What changed in this update

• Added a Central Dashboard overlay: applications/centraldashboard/overlays/model-registry/
• Added a JSON6902 patch that appends a new dashboard menu entry pointing to /model-registry/
  • Value added: {"text": "Model Registry", "link": "/model-registry/"}

Why this change

Kubeflow’s documentation for Model Registry installation and dashboard customization indicates the Model Registry entry should be added to the Central Dashboard configuration so it appears in the sidebar menu.

Verification status

• This PR is focused on manifests wiring (dashboard link + overlays).
• Local end-to-end screenshots are still pending; will follow up with real deployment verification + screenshots once the deployment environment is ready.

If you’d like the menu item to also include type/icon fields (as in the docs examples), please confirm the preferred values and I can update it accordingly.

[juliusvonkohout]

I think you can use a general named one called applications/centraldashboard/overlays/kustomization.yaml

We should also merge https://github.com/kubeflow/manifests/blob/master/applications/centraldashboard/overlays/oauth2-proxy/kustomization.yaml into that because oauth2-proxy is anyway mandatory.

[Raakshass]

@juliusvonkohout Refactor complete!
I've consolidated the oauth2-proxy and model-registry overlays into a single applications/centraldashboard/overlays/kustomization.yaml as requested. Also switched to a Strategic Merge Patch to fix the JSON syntax error.

Dashboard link is verified locally (screenshot attached).

[Raakshass]

Hi @juliusvonkohout @kimwnasptd,

I wanted to follow up on this PR. I noticed it's listed as a related issue for GSoC 2026 Project 4 (Platform Scalability and Security) - which is exciting!

Is there anything else needed from my side to move this forward? Happy to make any additional changes.

Thanks for your time!

[juliusvonkohout]

Now i just need some time go go thoroughly trough the authentication and authorization architecture.

[juliusvonkohout]

@Raakshass please investigate #3318 (comment) and see whether you can make it more secure and add security tests for that.

[Copilot]

Pull request overview

Copilot reviewed 8 out of 8 changed files in this pull request and generated 2 comments.

[Raakshass]

@Raakshass please investigate #3318 (comment) and see whether you can make it more secure and add security tests for that.

@juliusvonkohout
the AuthorizationPolicy is already hardened. abdullahpathan22's comment references the original upstream permissive rules: [{}], which i replaced with the KFP dual-path pattern in a prior commit. what they suggest is exactly what we already have:

• model-registry-service → dual-path: gateway ServiceAccount + internal K8s JWT with kubeflow-userid anti-spoof. matches ml-pipeline-ui in istio-authorization-config.yaml line-for-line
• model-registry-ui → gateway-only: istio-ingressgateway-service-account. matches jupyter, tensorboard, volumes, kserve web apps
  security tests added in 33bbce0:
  | test | what it validates | expected |
  |------|-------------------|----------|
  | test 6 | authorized default-editor token via gateway | 200 |
  | test 7 | unauthorized default ServiceAccount token via gateway | 403 |
  | test 8 (new) | unauthenticated request, no Authorization header | non-200 |

also fixed a bug where the test script started a duplicate port-forward on 8080, conflicting with port_forward_gateway.sh which already runs earlier in the CI workflow. now reuses the existing forward.

one thing i want to confirm: the anti-spoof rule (Rule 2) blocks internal pods from sending kubeflow-userid headers without going through the gateway. testing this through the gateway doesn't work because Rule 1 matches the gateway ServiceAccount regardless of headers. a proper in-mesh spoofing test would require deploying a temporary pod in a sidecar-injected namespace and exec'ing curl directly to model-registry-service.kubeflow.svc.cluster.local. should i add that, or is gateway-level coverage sufficient here?

[juliusvonkohout]

one thing i want to confirm: the anti-spoof rule (Rule 2) blocks internal pods from sending kubeflow-userid headers without going through the gateway. testing this through the gateway doesn't work because Rule 1 matches the gateway ServiceAccount regardless of headers. a proper in-mesh spoofing test would require deploying a temporary pod in a sidecar-injected namespace and exec'ing curl directly to model-registry-service.kubeflow.svc.cluster.local. should i add that, or is gateway-level coverage sufficient here?

more importantly
https://github.com/Raakshass/manifests/blob/33bbce056f367bf3c9be581f2b8e50eda6ae3944/.github/workflows/model_registry_test.yaml seems to have duplicated code, while https://github.com/kubeflow/manifests/pull/3318/changes#diff-4b30362af611e6ae2066d386c023437935b203936c034dd13c0fa669056c5175 and https://github.com/Raakshass/manifests/blob/33bbce056f367bf3c9be581f2b8e50eda6ae3944/.github/workflows/model_catalog_test.yaml is already cleaned up.

@Al-Pragliola @tarilabs please raise any objections or we merge this soon after the remaining cleanup.

[Copilot]

Pull request overview

Copilot reviewed 8 out of 8 changed files in this pull request and generated 4 comments.

[Raakshass]

one thing i want to confirm: the anti-spoof rule (Rule 2) blocks internal pods from sending kubeflow-userid headers without going through the gateway. testing this through the gateway doesn't work because Rule 1 matches the gateway ServiceAccount regardless of headers. a proper in-mesh spoofing test would require deploying a temporary pod in a sidecar-injected namespace and exec'ing curl directly to model-registry-service.kubeflow.svc.cluster.local. should i add that, or is gateway-level coverage sufficient here?

more importantly https://github.com/Raakshass/manifests/blob/33bbce056f367bf3c9be581f2b8e50eda6ae3944/.github/workflows/model_registry_test.yaml seems to have duplicated code, while https://github.com/kubeflow/manifests/pull/3318/changes#diff-4b30362af611e6ae2066d386c023437935b203936c034dd13c0fa669056c5175 and https://github.com/Raakshass/manifests/blob/33bbce056f367bf3c9be581f2b8e50eda6ae3944/.github/workflows/model_catalog_test.yaml is already cleaned up.

@Al-Pragliola @tarilabs please raise any objections or we merge this soon after the remaining cleanup.

cleaned up
model_registry_test.yaml
in 15cd3e7 — replaced all inline duplicated install/deploy/test code with three script calls matching the
model_catalog_test.yaml
pattern:

- name: Install Model Registry
  run: ./tests/model_registry_install.sh
- name: Port forward Istio gateway
  run: ./tests/port_forward_gateway.sh
- name: Run Model Registry Tests
  run: ./tests/model_registry_test.sh

also addressed all copilot review feedback in the same commit and fixed an AP abbreviation in 1e76409.

on security: the AuthorizationPolicy already implements the KFP dual-path pattern (gateway ServiceAccount + internal K8s JWT with kubeflow-userid anti-spoof) matching ml-pipeline-ui line-for-line. tests validate authorized (200), unauthorized (403), and unauthenticated (302/401/403) access.

[juliusvonkohout]

Thank you
/lgtm
/approve

we can refine later

[google-oss-prow]

[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

Details

Needs approval from an approver in each of these files:

• OWNERS [juliusvonkohout]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

no objections from other maintainers