RBAC missing permissions for channels and inmemorychannels in messaging.knative.dev

[christophd]

The Camel K operator has lost the permission to get/list and manage channels/inmemorychannels in messaging.knative.dev group. This causes the knative trait to raise permission errors when binding a Kamelet to channels/inmemorychannels for instance.

To reproduce add a KameletBinding that makes use of a Knative channel.

apiVersion: camel.apache.org/v1alpha1
kind: KameletBinding
metadata:
  name: message-event-sink
spec:
  source:
    ref:
      kind: Channel
      apiVersion: messaging.knative.dev/v1
      name: messages
  sink:
    ref:
      kind: Kamelet
      apiVersion: camel.apache.org/v1alpha1
      name: log-sink

This will result in errors in Camel K operator logs and the KameletBinding is stuck in "Creating" phase.

{"level":"error","ts":1655995698.9808981,"logger":"controller.integration-controller","msg":"Reconciler error","reconciler group":"camel.apache.org","reconciler kind":"Integration","name":"prize-event-sink","namespace":"yaks-demo","error":"error during trait customization: unexpected error while executing handler for channel prize-channel: cannot determine address of channel prize-channel: channels.messaging.knative.dev \"prize-channel\" is forbidden: User \"system:serviceaccount:openshift-operators:camel-k-operator\" cannot get resource \"channels\" in API group \"messaging.knative.dev\" in the namespace \"yaks-demo\"","errorVerbose":"channels.messaging.knative.dev \"prize-channel\" is forbidden: User \"system:serviceaccount:openshift-operators:camel-k-operator\" cannot get resource \"channels\" in API group \"messaging.knative.dev\" in the namespace \"yaks-demo\"\ncannot determine address of channel prize-channel\ngithub.com/apache/camel-k/pkg/trait.(*knativeTrait).withServiceDo.func1\n\tgithub.com/apach...

[phantomjinx]

Fixed in #3382

[astefanutti]

Possible duplicate of #3328.

[christophd]

I think the addressable changes do apply for Knative channels as a sink. I was using the channel as a source in the KameletBinding. Does that make a difference?

[astefanutti]

I think #2958 should apply whether a Knative Addressable to be resolved is used as a sink or source.

[christophd]

@astefanutti I can see {"level":"info","ts":1656322558.1037383,"logger":"cmd","msg":"Cannot bind the Knative Addressable resolver aggregated ClusterRole: skipping."} in my operator logs. So that is why the camel-k specific addressable-resolver cluster role binding is not present on my cluster.

Need to find out what that exact problem is here

[christophd]

I have found the root cause with the Knative addressable-resolver cluster role binding.

{"level":"debug","ts":1656354670.720523,"logger":"camel-k.cmd","msg":"Error while binding the Knative Addressable resolver aggregated ClusterRole","error":"ClusterRoleBinding.rbac.authorization.k8s.io \"camel-k-operator-addressable-resolver\" is invalid: subjects[0].namespace: Required value"}

Only global operators hit that problem because the empty operator watch namespace was used in the service account subject while creating the cluster role binding (https://github.com/apache/camel-k/blob/main/pkg/install/knative.go#L73).