Eventing: [BUG] Natss Channel doesn't work with Istio 1.1.x

Created on 9 Apr 2019  路  5Comments  路  Source: knative/eventing

Describe the bug
After installing Istio 1.1.x in a k8s cluster, both Natss controller and dispatcher in knative-eventing namespace can not connect to natss service.

{"level":"error","ts":"2019-04-09T18:46:00.914Z","logger":"provisioner","caller":"clusterchannelprovisioner/controller.go:42","msg":"Connect() failed: ","eventing.knative.dev/clusterChannelProvisioner":"natss","eventing.knative.dev/clusterChannelProvisionerComponent":"Controller","error":"read tcp 100.104.99.25:52518->100.71.171.214:4222: i/o timeout","stacktrace":"github.com/knative/eventing/contrib/natss/pkg/controller/clusterchannelprovisioner.ProvideController\n\t/go/src/github.com/knative/eventing/contrib/natss/pkg/controller/clusterchannelprovisioner/controller.go:42\nmain.main\n\t/go/src/github.com/knative/eventing/contrib/natss/pkg/controller/main.go:53\nruntime.main\n\t/usr/local/go/src/runtime/proc.go:200"}

Expected behavior
Natss channel works.

To Reproduce
Upgrade Istio to 1.1

Knative release version
V0.5.0

Additional context
No.

kinbug

Most helpful comment

A temporary simple solution to secure NATSS is to use "Authenticated Users": https://nats.io/documentation/streaming/nats-streaming-tls/
That means the the client pods (NATSS Controller + Dispatcher) and the NATSS Server pod should use the same "user" based on a shared secret done at the installation time. Of course, for a production ready solution, you have to thing how to rotate the credentials, etc.

We hoped that with the supporting of mTLS for TCP connections in Istio 1.1, NATSS would be part of the mesh too.
In Kyma we are using now the "shared secret" solution.

All 5 comments

We discovered this recently while upgrading Kyma to Istio 1.1. It seems this issue was discovered in the past with Istio. For some unknown reason, NATSS started working with Istio at some 0.x.

Here are some related issues
https://github.com/istio/istio/issues/10832
https://github.com/istio/old_issues_repo/issues/338
https://github.com/nats-io/nats-operator/issues/88

For Kyma there was no other option but to disable the Istio sidecar. I also contacted the natss community and they recommend not to have any proxy between natss client and server.

@abbi-gaurav : Thanks for the information I disabled sidecar injection for natss statefulset and now it's working.

What is the reason we put Natss on the mesh?

A temporary simple solution to secure NATSS is to use "Authenticated Users": https://nats.io/documentation/streaming/nats-streaming-tls/
That means the the client pods (NATSS Controller + Dispatcher) and the NATSS Server pod should use the same "user" based on a shared secret done at the installation time. Of course, for a production ready solution, you have to thing how to rotate the credentials, etc.

We hoped that with the supporting of mTLS for TCP connections in Istio 1.1, NATSS would be part of the mesh too.
In Kyma we are using now the "shared secret" solution.

/close

@akashrv: Closing this issue.

In response to this:

/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

nachocano picture nachocano  路  12Comments

lionelvillard picture lionelvillard  路  13Comments

capri-xiyue picture capri-xiyue  路  8Comments

mattmoor picture mattmoor  路  13Comments

rhuss picture rhuss  路  4Comments