<p>Recently I was adding Istio to my kubernetes cluster. When enabling istio to one of the namespaces where MongoDB statefulset were deployed, MongoDB was failed to start up.</p>
<p>The error message was &quot;keyfile permissions too open&quot;</p>
<p>When I analyzed whats going on, keyfile is coming from the /etc/secrets-volume which is mounted to the statefulset from kubernetes secret.</p>
<p>The file permissions was 440 instead of 400. Because of this MongoDB started to complain that &quot;permissions too open&quot; and the pod went to Crashbackloopoff.</p>
<p>When I disable Istio injection in that namespace, MongoDB is starting fine.</p>
<p>Whats going on here? Does Istio has anything to do with container filesystem, especially default permissions?</p>

<p>The istio sidecar injection is not always meant for all kinds of containers like mentioned in istio documentation <a href="https://istio.io/latest/docs/setup/additional-setup/sidecar-injection/#more-control-adding-exceptions" rel="nofollow noreferrer">guide</a>. These containers should be excluded from istio sidecar injection.</p>
<p>In case of Databases that are deployed using <code>StatefulSets</code> some of the containers might be temporary or used as operators which can end up in crash loop or other problematic states.</p>
<p>There is also alternative approach to not istio inject databases at all and just add them as external services with <code>ServiceEntry</code> objects. There is entire <a href="https://istio.io/latest/blog/2018/egress-mongo/" rel="nofollow noreferrer">blog post</a> in istio documentation how to do that specifically with MongoDB. the guide is little outdated so be sure to refer to current <a href="https://istio.io/latest/docs/reference/config/networking/service-entry/" rel="nofollow noreferrer">documentation page</a> for <code>ServiceEntry</code> which also has examples of using external MongoDB.</p>
<p>Hope it helps.</p>
