cilium
tetragon: Fixed missing grpc port expose via helm install
Currently the tetragon service does not expose the grpc port when it is enabled via values.yaml. This checks to see if the grpc is enabled and exposes the port via the service.
Signed-off-by: pxp928 [email protected]
@willfindlay Correct me if I am wrong. New to tetragon. But you can limit which address the grpc is exposed via the values.yaml. So only the specified address would be able to connect and all other unauthorized addresses would not be able to connect.
i think @willfindlay 's concern is that the traffic is not encrypted, so if you expose the grpc endpoint as a service, anybody on the network can connect to it. that's why currently we only listen on the local interface by default. in cilium / hubble, we use mTLS to ensure that only hubble-relay can connect to cilium: https://docs.cilium.io/en/stable/concepts/observability/hubble-configuration/
stepping back a little bit, could you describe your use case? maybe we can come up with something that doesn't require exposing plaintext grpc endpoint.
@michi-covalent So I am creating an integration with another tool where I want to filter on a specific pod in a specific namespace and create a record of the set of execs, syscalls, etc. (whatever you add to your tracing). I agree with your point, any suggestions on how we can proceed? The other tool that I would be integrating with would be in the same cluster as tetragon.
Would it make more sense to expose grpc via a unix socket instead?
Yes, we've actually had offline discussions about this before but nobody has gotten around to it yet. Would be happy to accept a PR for this, although ideally it would be configurable with the Unix socket as a default imo.
@pxp928 looks like there is some agreement here on direction I'll wait for an update to (re)review and hopefully merge.
Since this PR has not seen updates for sometime, I'll move it into draft for now. @pxp928 feel free to mark it as ready for review whenever it is ready. Thanks!
