Security enhancement request

[esnible]

This is not a bug, it is an enhancement request or question.

I run Istio-vet against IBM Container service like this:

MYCLUSTER=...
MYDC=dal13
docker run --rm -v ~/.bluemix/plugins/container-service/clusters/$MYCLUSTER/kube-config-$MYDC-$MYCLUSTER.yml:/root/.kube/config -v ~/.bluemix/plugins/container-service/clusters/$MYCLUSTER/ca-$MYDC-$MYCLUSTER.pem:/root/.kube/ca-$MYDC-$MYCLUSTER.pem quay.io/aspenmesh/istio-vet:master

It works great. The config and .pem cert are sent to the instance, and it can access using oidc auth provider.

However, I am nervous about giving my certificate to a Docker image I don't control. (I realize I could inspect the code and compile the code myself.)

My idea is to have istio-vet not require a configuration. If no configuration is supplied, it would use the cluster at localhost:8001 assuming no security. This would allow me to run kubectl proxy & and docker run quay.io/aspenmesh/istio-vet:master with no need for mounting a cert and configuration.

[nrjpoddar]

Thanks @esnible for filing this enhancement. I had not considered this possible security risk. If you're running this locally do you prefer to run via docker container or want to use an executable that we can package and release as part of the repository? I'm guessing if someone don't trust the container it's fair to assume that they also don't trust the binary? :)

If you're running the container locally and want to use kubectl proxy I think it will still require a fair amount of setup i.e. exposing container port to a host port and then running kubectl proxy on that host port. We can make the change to support this enhancement if users want to do the manual configuration.