Merge pull request #9 from metal-stack/update-docs

Update docs for konnectivity mTLS proxy

README.md

@@ -9,9 +9,12 @@ This is a small piece of software that is intended to run as sidecar in an out-o
 - There has to be a corresponding `kubernetes-audit-tailer` service and pod in the cluster that receives the audit data and makes it available to a cluster logging solution, e.g. by writing it to its stdout so that it appears as container log
 - We use fluent-bit with the `forward` out plugin as forwarding agent because it is built for the task of reliably forwarding log data. There needs to be a corresponding fluent-bit or fluentd running in the `kubernetes-audit-tailer` pod to receive the data
 
-### Use with konnectivity tunnel (currently only UDS proxy with http-connect)
+### Use with konnectivity tunnel (UDS proxy or mTLS proxy with http-connect)
 
-If connectivity between the apiserver and cluster is with a [konnectivity proxy](https://github.com/kubernetes-sigs/apiserver-network-proxy), auditforwarder can use this if it is a UDS proxy running in another sidecar of the apiserver and if it is a http connect (not GRPC) proxy. Details on how this gets invoked are within the konnectivity test case (see next section).
+If connectivity between the apiserver and cluster is done with a [konnectivity proxy](https://github.com/kubernetes-sigs/apiserver-network-proxy), auditforwarder can use this. There are two variants supported:
+
+- A UDS proxy using the http connect method, running in another sidecar of the apiserver. Details on how this gets invoked are within the konnectivity test case (see next section).
+- A mTLS proxy using http connect, running in a seperate pod from the kube-apiserver. The method to use this is much the same as with the UDS proxy; there are seperate command options to specify the proxy host and port.
 
 ## Testing locally
 

kind/README.md

@@ -55,14 +55,16 @@ You can implement your own destination by using the right output plugin; you can
 
 ## Using auditforwarder with a konnectivity tunnel
 
-Gardener offers the option to use a [konnectivity](https://github.com/kubernetes-sigs/apiserver-network-proxy) tunnel for the connectivity between apiserver and cluster. The way Gardener uses it, a Unix Domain Socket file acts as proxy endpoint for the kube-apiserver.
+Gardener offers the option to use a [konnectivity](https://github.com/kubernetes-sigs/apiserver-network-proxy) tunnel for the connectivity between apiserver and cluster. The way Gardener uses it (unless the apiserver SNI featureGate is active as well), a Unix Domain Socket file acts as proxy endpoint for the kube-apiserver.
 
 audit-forwarder can use this proxy; you need to mount the UDS socket file into the container and specify it with the `konnectivity-uds-socket` command line option (or corresponding environment variable). The audit-forwarder will open a local port for fluent-bit to use, connect to the audit-tailer service the the konnectivity tunnel and then just forward the data throuth the tunnel.
 
 Creating the kind cluster with konnectivity enabled in a manner similar to what Gardener is doing is a two step process: First execute `./make-kind-cluster_konnectivity` to create the cluster, and make the `kind-etc-kubernetes` subdirectory your own as instructed; then patch the kube-apiserver to use konnectivity with `./make-konnectivity`.
 
 Once you have the cluster, you can activate the audit-forwarder with `./make-audit-forwarder-konnectivity`. And don't forget the audit tailer.
 
+There is no seperate test case for the mTLS proxy; konnectivity has already been removed from current gardener versions so this is very short-lived and not worth the effort to implement.
+
 ## Testing memory limits
 
 audit-forwarder comes with a default mem_buf_limit configuration of 200 Mbyte to prevent it from using up all the memory if it can not write the log data to the audit tailer for a long time. The limit can also be configured through command line option / environment variable.