camel-k-operator forbidden to get kafkachannels.messaging.knative.dev since 1.8.x #2950
Comments
|
Wildcard permissions have been removed with #2807, as unbounded RBAC is not considered a best practice. A Knative Sink can be any resource that's Addressable, and the Camel K operator do a GET request to retrieve the address from the resource We can expand the list of default Addressable resources that the operator is granted read permission on, like https://knative.dev/docs/eventing/sinks/#using-custom-resources-as-sinks If that is the right approach, we need to document it. |
|
Right, I agree it makes sense for the camel-k project to leave the responsibility to the administrator, as camel-k project itself cannot know what the system as a whole will be using. This of course present a problem for an ecosystem of operators, which should somehow be integrated together and ideally work OOB (like the OpenShift operators), as the role of those operators is to make the administrator's job easier... I don't have answer to that problem. ( I guess some general mechanism would be needed, loosely coupling CRDs and ClusterRoles together, such that some mechanism would grant these rules automatically somehow, but also somehow safely (to not allow just any custom Role to be granted write access to all addressables, etc...?), but of course camel-k is not the proper venue to solve this general problem... |
|
Thanks a lot for your feedback. Would you know if the kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: kafkasinks-addressable-resolver
labels:
kafka.eventing.knative.dev/release: devel
duck.knative.dev/addressable: "true"
# Do not use this role directly. These rules will be added to the "addressable-resolver" role.
rules:
- apiGroups:
- eventing.knative.dev
resources:
- kafkasinks
- kafkasinks/status
verbs:
- get
- list
- watchIf that it's the case, it may be possible to create an aggregated role, like: apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: camel-k-operator-knative-sinks
aggregationRule:
clusterRoleSelectors:
- matchLabels:
duck.knative.dev/addressable: "true"
rules: []And have the Kubernetes control plane automatically update it with the aggregated rules. WDYT? |
|
The aggregated This is the apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: camel-k-addressable-resolver
subjects:
- kind: ServiceAccount
name: <camel-k-service-account>
namespace: <camel-k-namespace>
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: addressable-resolver |
|
@pierDipi Thanks! I infer the I've researched how to create the corresponding ClusterRoleBinding via OLM, but that does not seem supported, as subjects are not resolved for OLM bundle additional manifests. So it has to be created from the operator at start time. |
|
I've open a new PR #2958, that adds |
With camelk 1.7, I can use the https://github.com/apache/camel-k/tree/main/examples/knative example with a KafkaChannel channels, instead of InMemoryChannel.
The same example fails on 1.8.x with KafkaChannels, due to
( compare https://github.com/apache/camel-k/blob/release-1.7.x/helm/camel-k/templates/operator-role.yaml#L219-L224 vs https://github.com/apache/camel-k/blob/main/helm/camel-k/templates/operator-role.yaml#L244-L248
it is clear the now the rules are more explicit, which also means it lacks permission to access non-default channel kinds.
(full error from camel-k-operator logs)
The text was updated successfully, but these errors were encountered: