After registry the model, see nothing from ui

[jeffrey4l]

trafficstars

Describe the bug

After following the doc to registry model, i can see them through api

curl -sX 'GET' 'http://localhost:8081/api/model_registry/v1alpha3/registered_models?pageSize=100&orderBy=ID&sortOrder=DESC' -H 'accept: application/json' | jq
{
  "items": [
    {
      "createTimeSinceEpoch": "1742371423079",
      "customProperties": {},
      "id": "3",
      "lastUpdateTimeSinceEpoch": "1742371423079",
      "name": "r1",
      "owner": "[email protected]",
      "state": "LIVE"
    },
    {
      "createTimeSinceEpoch": "1742369743855",
      "customProperties": {},
      "id": "1",
      "lastUpdateTimeSinceEpoch": "1742369743855",
      "name": "my-model",
      "owner": "Ada Lovelace",
      "state": "LIVE"
    }
  ],
  "nextPageToken": "",
  "pageSize": 100,
  "size": 2
}

But still seem nothing from webui

To Reproduce

• install model registry ui following https://www.kubeflow.org/docs/components/model-registry/installation/
• registry a new model following https://www.kubeflow.org/docs/components/model-registry/getting-started/#setup

Expected behavior

• model can be registry and view and modify from ui

[pboyd]

Hi @jeffrey4l. Which namespace did you install model registry in? By default it goes to the kubeflow namespace which won't work for the UI. Based on the screenshot, you should install model registry in the kubeflow-user-example-com namespace.

The website docs are a bit confusing on this point, there's a PR to clean it up (btw, I'd love some feedback on that PR, if you can!).

[rareddy]

@pboyd I mistakenly used kubeflow as the PROFILE_NAME, but that doesn't work and needs to be explicitly called out. Additionally, I recommend creating a new profile for the Model Registry instead of using kubeflow-user-example-com, which is intended for user workloads. The Model Registry should have its own dedicated profile since it is a shared component across all profiles rather than an individual user's workload.

[pboyd]

@rareddy, it can work that way...

Create a model-registry profile:

kubectl create -f - <<EOF
apiVersion: kubeflow.org/v1
kind: Profile
metadata:
  name: model-registry
spec:
  owner:
    kind: User
    name: [email protected]
EOF

Update and apply the manifests:

PROFILE_NAME=model-registry
for DIR in options/istio overlays/db ; do (cd $DIR && kustomize edit set namespace $PROFILE_NAME && kubectl apply -k .); done

We can simplify it a bit by changing the default namespace in the manifests. We could also add a manifest for the profile, but we would have to hard-code a default username for the owner.

Is there any appetite for a helm chart? It would be a lot simpler for users.

[tarilabs]

Is there any appetite for a helm chart? It would be a lot simpler for users.

based on my observations there is not (yet?) a unanimous consensus in KF community whether a Helm chart is desired (or less) as the supported installation method:

• https://github.com/kubeflow/community/pull/832

[rareddy]

We can simplify it a bit by changing the default namespace in the manifests. We could also add a manifest for the profile, but we would have to hard-code a default username for the owner.

• I agree, I see no reason to keep the model registry deployed in kubeflow namespace if we can not use that with UI
• Adding an additional manifest is just going to confuse with two model registry instances where one of then being not used at all
• as per hardcoding the user name; I see that is what the other profile did, but we would need to call out in the docs explicitly to the user change and not use it for prod scenarios

I recommend, for now, replacing the current manifest with deploying the model registry in a profile as suggested above and tying the UI with that profile's model registry. That is for KF 1.10. I understand there is no clear direction here to support the multiple instances of Model Registry (may be there is :) )

Going past that, I am not convinced about workflow; We should be able to deploy the model registry(s) in a "known" namespace like model-registry which is not a profile, but we figure need out what it takes for "profile" based user to grant access so that we show all the available Model Registries for that user. This can be further captured as another issue. wdyt?

cc: @lucferbux @ederign

[jeffrey4l]

After deploy the model-registry to kubeflow-user-example-com, the ui works as expected.

But my question is:

• if deploy the model-registry to other namespace, like 'model-registry`, how to control who can see and access it? especially from the ui.
• is there any RBAC control for each registed model? i.e. Profile A can see model B only, and can not see model C.

[lucferbux]

Based on these comments and the website PR, I've just revamped my PR, @jeffrey4l @pboyd @rareddy let me know what you think: https://github.com/kubeflow/model-registry/pull/854

[pboyd]

But my question is:

• if deploy the model-registry to other namespace, like 'model-registry`, how to control who can see and access it? especially from the ui.
• is there any RBAC control for each registed model? i.e. Profile A can see model B only, and can not see model C.

The UI uses profiles to control access. If you want to deploy to a model-registry namespace (or any other namespace, for that matter), you'll need to make a new profile first:

kubectl create -f - <<EOF
apiVersion: kubeflow.org/v1
kind: Profile
metadata:
  name: model-registry
spec:
  owner:
    kind: User
    name: [email protected]
EOF

The kubeflow profile controller will then create the namespace.

[lucferbux]

But my question is:

• if deploy the model-registry to other namespace, like 'model-registry`, how to control who can see and access it? especially from the ui.
• is there any RBAC control for each registed model? i.e. Profile A can see model B only, and can not see model C.

The UI uses profiles to control access. If you want to deploy to a model-registry namespace (or any other namespace, for that matter), you'll need to make a new profile first:

kubectl create -f - <<EOF
apiVersion: kubeflow.org/v1
kind: Profile
metadata:
  name: model-registry
spec:
  owner:
    kind: User
    name: [email protected]
EOF

The kubeflow profile controller will then create the namespace.

Btw, in the docs they warn you that if the namespace is already present there might be some side effects.

is there any RBAC control for each registed model? i.e. Profile A can see model B only, and can not see model C.

This is a really good question, we haven't added this to our current architecture, there's two main roles in profiles, editor and viewer, there's no granularity inside of that, so a user that has access to that profile might either have view or edit permissions, so no, KCD does not support that use case and we as MR UI don't support roles yet.

[mginfn]

Hi, I've a running Kubeflow instance and I've deployed the Model Registry in a custom profile named "mlaas", patching kustomization.yaml files as follows:

PROFILE_NAME=mlaas
to_patch=(
    "kubeflow-manifests/apps/model-registry/upstream/overlays/db"
    "kubeflow-manifests/apps/model-registry/upstream/options/istio"
    "kubeflow-manifests/apps/model-registry/upstream/options/csi"
    "kubeflow-manifests/apps/model-registry/upstream/options/ui/overlays/istio"
)

for dir_path in "${to_patch[@]}"; do
    (cd $dir_path; kustomize edit set namespace $PROFILE_NAME)
done

I can register and list models using the python client in a Notebook within the cluster, but in the Kubeflow Central Dashboard the routing to the Model Registry UI is broken, reporting "Sorry, /model-registry/ is not a valid page".

I noticed that there are several references to the "kubeflow" namespace that I assume should be patched as well, e.g.:

• https://github.com/kubeflow/model-registry/blob/3b6206870d1656c0c504c61fcbf12e16ebb4ced4/manifests/kustomize/options/ui/overlays/istio/destination-rule-ui.yaml#L8
• https://github.com/kubeflow/model-registry/blob/3b6206870d1656c0c504c61fcbf12e16ebb4ced4/manifests/kustomize/options/ui/overlays/istio/virtual-service.yaml#L24

Moreover, references to the "kubeflow-gateway" should be replaced to "kubeflow/kubeflow-gateway", e.g. at the following line:

• https://github.com/kubeflow/model-registry/blob/3b6206870d1656c0c504c61fcbf12e16ebb4ced4/manifests/kustomize/options/ui/overlays/istio/virtual-service.yaml#L9

After patching all these values, now the Model Registry UI works within the Central Dashboard. Am I right or there's something I'm missing? Thank you!

[lucferbux]

Hi @mginfn I need to re-test the new instructions in case there's something wrong, but executing whats now in the manifest's docs should be more than enough:

PROFILE_NAME=<your-profile>
for DIR in options/istio overlays/db ; do (cd $DIR; kustomize edit set namespace $PROFILE_NAME; kubectl apply -k .); done

Reason is that once that you set namespace in the two main kustomize files, and apply them with kubectl apply -k all files are overridden and deployed with that namespace. You are right, the files that you mention should go to the namespace you are overriding, but that should be covered with the command right above.

I'm doing a fresh install right now of kubeflow, let me check if there's something wrong with the instructions and I'll get back to you. Thanks a lot for the feedback.

[mginfn]

Hi @lucferbux, any news about this issue? As to my tests, just relying on "kustomize edit" does not work, as Model Registry service uris are not patched (e.g. "model-registry-ui-service.kubeflow.svc.cluster.local", see other examples above). Moreover, I deployed the Model Registry in its own profile "model-registry" and I can access it from the UI as far as I switch to the "model-registry" profile, If I use a different profile the UI tells to read the docs to deploy a new model registry (the original issue in this thread). For me, it would be very helpful to clarify in the documentation how to install the Model Registry and how to access it (by profile owners and contributors) in a multi-tenant Kubeflow installation. Thanks for your help and great work!

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[github-actions[bot]]

This issue has been automatically closed because it has not had recent activity. Please comment "/reopen" to reopen it.

[MattiaSarti]

For those interested in a workaround: https://github.com/canonical/bundle-kubeflow/issues/1340

[mginfn]

Hi @MattiaSarti, thanks for your great work! I'm trying your solution, deploying the ModelRegistry in the kubeflow namespace with the EnvoyFilter you provided. Logs from Istio show that a request from "namespace=mlaas" to "model-registry-ui-service.kubeflow" is recorded, but I get a 403 error:

[2025-09-15T17:09:58.564Z] "GET /model-registry/api/v1/model_registry?namespace=mlaas HTTP/2" 403 - via_upstream - "-" 0 68 4 3 "10.244.0.0" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:142.0) Gecko/20100101 Firefox/142.0" "846e2534-4c35-4b4f-9737-bd7419ac8e3c" "kubeflow.XXX.cloud.infn.it:30443" "10.244.1.95:8080" outbound|80||model-registry-ui-service.kubeflow.svc.cluster.local 10.244.2.213:35704 10.244.2.213:8443 10.244.0.0:8966 kubeflow.XXX.cloud.infn.it -

Is there any need for an additional Istio AuthorizationPolicy? Thank you

[MattiaSarti]

Anytime, @mginfn, and thanks!

If you deploy the Model Registry from the upstream manifests (considering version v0.2.22) as:

• /overlays/db

and include the options:

• /options/istio
• /options/ui/overlays/istio

then no additional steps should be required.

[mginfn]

Hi @MattiaSarti , all layers are included, yet I'm getting 403.

These are the authorization policies applied to the model-registry-ui workload:

istioctl x authz check model-registry-ui-6d6fff8648-fd9rm.kubeflow          
ACTION   AuthorizationPolicy            RULES
ALLOW    global-deny-all.istio-system   1
ALLOW    model-registry-ui.kubeflow     1

The ui policy seems fine as well:

apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  creationTimestamp: "2025-09-15T16:58:49Z"
  generation: 1
  labels:
    app: model-registry-ui
  name: model-registry-ui
  namespace: kubeflow
  resourceVersion: "135582174"
  uid: 4456724a-70c2-4e31-8dfe-ec710cd5d0cc
spec:
  action: ALLOW
  rules:
  - from:
    - source:
        principals:
        - cluster.local/ns/istio-system/sa/istio-ingressgateway-service-account
  selector:
    matchLabels:
      app: model-registry-ui

Any idea? Thank you!

[MattiaSarti]

@mginfn, can you share the command you are using for making the API call?

I am giving for granted that, when calling the BFF API from outside the K8s cluster, you are passing the Istio authentication token for the namespace of the respective Profile you are calling the API on behalf of. So does the UI for you, behind the scenes (either using tokens or cookies). See the many code snippets in the linked issue of mine for references.

[mginfn]

Hi @MattiaSarti, I'm navigating to the ModelRegistry app using the Central Dashboard UI, this is the curl issued by the browser:

curl 'https://kubeflow.XYZ.cloud.infn.it:30443/model-registry/api/v1/model_registry?namespace=mlaas' \
  -H 'User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:142.0) Gecko/20100101 Firefox/142.0' \
  -H 'Accept: */*' \
  -H 'Accept-Language: en-US,en;q=0.5' \
  -H 'Accept-Encoding: gzip, deflate, br, zstd' \
  -H 'Referer: https://kubeflow.XYZ.cloud.infn.it:30443/model-registry/' \
  -H 'Connection: keep-alive' \
  -H 'Cookie: auth=xyz' \
  -H 'Sec-Fetch-Dest: empty' \
  -H 'Sec-Fetch-Mode: cors' \
  -H 'Sec-Fetch-Site: same-origin' \
  -H 'Priority: u=4' \
  -H 'TE: trailers'

The 403 is somehow related to your EnvoyFilter as If I delete it I don't get the 403 error any more but I get (as expected by your analysis) an empty response:

{
	"data": []
}

I'm using ModelRegistry v0.2.19 (bundled in Kubeflow Manifests v1.10.2).

[MattiaSarti]

Got it, @mginfn.

Then authentication is correctly passed.

I would say the version difference is less likely to be the problem.

What I see is that you are using TLS while I was not, only testing locally over HTTP. That is way more likely to be the problem. My EnvoyFilter was tuned for HTTP calls on port 8080, so I guess you need to adjust it for HTTPS calls on your port.

If I end up having to deal with the same problem, I'll share the solution variant.

[mginfn]

Hi @MattiaSarti , I understand. From Istio logs the port is the same (8080), but the query parameter rewriting is breaking authorization somehow. Did you consider using VirtualServices for URL rewriting? Maybe it's a more reliable approach to preserve Istio functionalities.

[MattiaSarti]

I see, @mginfn.

No, with VirtualService it is not possible to selectively rewrite a single query parameter, you can change things like headers but for query parameters you would have to rewrite the whole URL, which would not make API calls work in general.