[Enhancement] TLS/authn/authz for Kafka Connect REST API

strimzi / strimzi-kafka-operator

Apache Kafka® running on Kubernetes

https://strimzi.io/

Apache License 2.0

4.79k stars 1.28k forks source link

[Enhancement] TLS/authn/authz for Kafka Connect REST API #2161

Open tombentley opened 4 years ago

tombentley commented 4 years ago

Is your feature request related to a problem? Please describe. The KafkaConnect REST API does not support TLS and is not authenticated.

Describe the solution you'd like It should be possible to encrypt the REST API with TLS. It should be possible to have the REST API authenticated (TLS authn and/or other mechanisms) Ideally it should also be possible for an authenticated user to only be authorised for some operations (e.g. read-only access would equate to only allowing GET methods).

katheris commented 2 years ago

scholzj commented 2 years ago

Triaged on 17.3.2022: Work in progress for encryption currently. See the proposal link above.

dadufour commented 1 month ago

Is there any progress on this issue? This was identified as a finding in our pentests campaign which is used for our PCI audits. Do you have a workaround to propose?

katheris commented 1 month ago

Unfortunately the proposal got blocked behind work to change how we manage certificates in Strimzi. I am actively working on the certificate changes, but it's taking time to find and implement the best approach, so I don't have any idea when I (or anyone else) would get back around to this.

The "workaround" is to make use of the KafkaConnector resources, that is the more Kubernetes native way of using Connect with Strimzi anyway. Then you can lock down the API with network policies.

dadufour commented 1 month ago

Thanks for the feedback. Yes, we are using MirrorMaker2 resources and we have network policies to restrict the access which is a mitigation. However, auditors don't like unauthenticated services running in the environment.

scholzj commented 1 month ago

I guess there are several general things influencing why this hasn't been done yet:

A long time ago we decided to postpone the Connect security after we solved the support for external certificate managers for Kafka clusters in order to use the same mechanisms and APIs. I think that is a reasonable decision. Unfortunately, the Kafka cluster part has not moved forward much since.
We never really made the decision about the Connector operator. The original thought was that we fully move to it and lock down Connect completely. But we never did it and I think many users would not like that idea. So we are in this strange state where we have both options and each of them has a bit different requirements for security.

😞