There is no easy solution. Your init container will run before the sidecar starts. If your container runs before Istio’s init container it will not be secure. If your container runs after Istio’s it will not have network access.
If you can avoid doing network I/O in your init containers you should. If you must use init containers that expect connectivity, you’ll need a work-around.
If an application uses an Init Container for orchestration (for example trying to contact a remote CouchDB before starting up an app that depends on immediate connectivity to CouchDB) the pod initialization will not complete.
If your init container is just a tiny script you can sometimes move it from its own container to the app container with a hack like the following in your Deployment .yaml.
command: ["/bin/bash", "-c"]
args: ["until curl --head localhost:15000 ; do echo Waiting for Sidecar; sleep 3 ; done ; echo Sidecar available; ./init-stuff.sh && ./startup.sh"]
(where init-stuff.sh gets replaced by whatever your init used to do, and startup.sh is whatever command starts your app container).