fix 1802: leverage KEP-1755 to retrieve local image registry host an…

[johnpoth]

…d port

Fixes #1802, this makes:

$kamel install

work on supporting clusters without additional arguments (tested successfully on k3d), thanks !

Release Note

NONE

[astefanutti]

Great! Last time I checked, Minikube was not going to support this. Has it changed?

[astefanutti]

Would it be possible to move that logic in the controller, like when reconciling the platform, instead of keeping it for the sole kamel install. That way it would work also whatever the installation mode. I remember we kept it there for Minikube to avoid extra RBAC and specific code, but with that KEP, it seems it would be both logical and possible.

[nicolaferraro]

Would it be possible to move that logic in the controller, like when reconciling the platform, instead of keeping it for the sole kamel install. That way it would work also whatever the installation mode. I remember we kept it there for Minikube to avoid extra RBAC and specific code, but with that KEP, it seems it would be both logical and possible.

I guess it depends how much the kube-public namespace is public..

[astefanutti]

Would it be possible to move that logic in the controller, like when reconciling the platform, instead of keeping it for the sole kamel install. That way it would work also whatever the installation mode. I remember we kept it there for Minikube to avoid extra RBAC and specific code, but with that KEP, it seems it would be both logical and possible.

I guess it depends how much the kube-public namespace is public..

Hehe, I asked it as a question more by courtesy but I don't expect any counter arguments 😃.

[johnpoth]

Would it be possible to move that logic in the controller, like when reconciling the platform, instead of keeping it for the sole kamel install. That way it would work also whatever the installation mode. I remember we kept it there for Minikube to avoid extra RBAC and specific code, but with that KEP, it seems it would be both logical and possible.

Thanks for reviewing !

As @nicolaferraro said I'm not sure how public the "kube-public" namespace really is:

$kubectl auth can-i get cm  -n kube-public --as system:serviceaccount:camel-k:camel-k-operator
no

Although by convention it is supposed to be:

"kube-public This namespace is created automatically and is readable by all users (including those not authenticated). This namespace is mostly reserved for cluster usage, in case that some resources should be visible and readable publicly throughout the whole cluster. The public aspect of this namespace is only a convention, not a requirement."

Anyhow I've updated the PR so the logic is also in the operator. I've left it in the client as well so that

kamel install

works without any other options (i.e without having to specify --skip-operator-registry). Thanks !

[astefanutti]

I think it won't work for local install, as the operator service account do not have required permission.

I think the best solution is to create a dedicated ClusterRole with:

rules:
- apiGroups: [""]
  resources: ["configmaps"]
  resourceNames: ["local-registry-hosting"]
  verbs: ["get"]

And a RoleBinding projecting that ClusterRole on the kube-public namespace for the operator service account.

[astefanutti]

As @nicolaferraro said I'm not sure how public the "kube-public" namespace really is:

$kubectl auth can-i get cm  -n kube-public --as system:serviceaccount:camel-k:camel-k-operator
no

That means the operator service account do not have the required permission, but I would not deduce kube-public is not "public" from it. That only means read permission is granted for all users, but not service account. This is for us to add the permission to the operator service account.

One solution is to create a dedicated ClusterRole with:

rules:
- apiGroups: [""]
  resources: ["configmaps"]
  resourceNames: ["local-registry-hosting"]
  verbs: ["get"]

And a RoleBinding projecting that ClusterRole on the kube-public namespace for the operator service account.

[johnpoth]

kubectl auth can-i get cm -n kube-public --as system:serviceaccount:camel-k:camel-k-operator
no

As @nicolaferraro said I'm not sure how public the "kube-public" namespace really is:

$kubectl auth can-i get cm  -n kube-public --as system:serviceaccount:camel-k:camel-k-operator
no

That means the operator service account do not have the required permission, but I would not deduce kube-public is not "public" from it. That only means read permission is granted for all users, but not service account. This is for us to add the permission to the operator service account.

One solution is to create a dedicated ClusterRole with:

rules:
- apiGroups: [""]
  resources: ["configmaps"]
  resourceNames: ["local-registry-hosting"]
  verbs: ["get"]

And a RoleBinding projecting that ClusterRole on the kube-public namespace for the operator service account.

Ah yeah thanks, I think I tested with unauthorized users (which also didn't work) but I've added the RBAC files as you suggested which should make the question "is the kube-public namespace really public" null and void :) Thanks !

[github-actions]

This PR has been automatically marked as stale due to 90 days of inactivity.
It will be closed if no further activity occurs within 15 days.
If you think that’s incorrect or the issue should never stale, please simply write any comment.
Thanks for your contributions!

[squakez]

Hey @johnpoth unfortunately this has some conflict ongoing now. Would you mind rebase with main?

[johnpoth]

Thanks @squakez ! Rebased and merging....