istio: Istio injector annotations don't work as described in doc

Describe the bug Istio injector annotations don’t work as describe in at https://istio.io/docs/setup/kubernetes/sidecar-injection/#policy,

policy=disabled -> The sidecar injector will not inject the sidecar into pods by default. Add the sidecar.istio.io/inject annotation with value true to the pod template spec to enable injection.
policy=enabled -> The sidecar injector will inject the sidecar into pods by default. Add the sidecar.istio.io/inject annotation with value false to the pod template spec to disable injection

Expected behavior When policy=disabled the sidecar injector will not inject the sidecar into pods by default. Add the sidecar.istio.io/inject annotation with value true to the pod template spec to enable injection.

Steps to reproduce the bug Create a pod in a namespace where policy=disabled or policy unset. Injection will not happen no matter what we set pod annotation to.

Version 0.8

Is Istio Auth enabled or not? No, auth not eabled.

helm template --namespace=istio-system \
    --set sidecarInjectorWebhook.enabled=true \
    --set global.proxy.image=proxyv2 \
    --set prometheus.enabled=false \
    install/kubernetes/helm/istio > ../istio.yaml

Environment GKE 1.10

About this issue

Original URL
State: closed
Created 6 years ago
Comments: 25 (6 by maintainers)

Most upvoted comments

@ymesika It looks like setting up the ConfigMap policy works as you described.

I summarized the behavior as followed. Please correct me if I am wrong.

Namespace label `istio-injection`	ConfigMap key `policy`	Pod annotation `sidecar.istio.io/inject`	Injection
enabled	enabled	true	yes
enabled	enabled	false	no
enabled	enabled		yes
enabled	disabled	true	yes
enabled	disabled	false	no
enabled	disabled		no
disabled	enabled	true	no
disabled	enabled	false	no
disabled	enabled		no
disabled	disabled	true	no
disabled	disabled	false	no
disabled	disabled		no

tl;dr: if namespace policy=disabled then no injection. Otherwise, if Pod annotation is true => injection; false => no injection; empty => fallback on the ConfigMap key policy.

In my case I have one namespace where I want to disable sidecar injection by default, except for one Pod (opt-in) (this namespace contains my controllers and webhooks). I also have K namespaces where I want to enable sidecar injection by default (this namespace contains my users’ containers). Do you have recommendation of how I can achieve that?

Thanks a lot for the help so far.

+28

tcnghia on Jun 21, 2018

I’m surprised this hasn’t been addressed; the documentation reads as though you can disable injection at the namespace and enable selectively in the pod template but that’s apparently not the case?

Can we reopen this issue?

+21

blankenshipz on Oct 13, 2020

If I understand correctly ConfigMap is a cluster-wide injection policy, namespace label istio-injection is a namespace level injection policy, and Pod annotation sidecar.istio.io/inject is a Pod level injection policy.

Since namespace level policy are not yet documented, may I request that we adopt a hierarchical model? In such a hierarchical model, the policy with the least scope wins. So sidecar.istio.io/inject has highest priority, followed by namespace label istio-injection, then injector config ConfigMap key policy. Currently I think the namespace label istio-injection already trumps the injector ConfigMap key policy, so this proposal won’t be too different from previously. The only two cases that will change are

Namespace label `istio-injection`	ConfigMap key `policy`	Pod annotation `sidecar.istio.io/inject`	Injection
disabled	enabled	true	no -> yes
disabled	disabled	true	no -> yes

That would simplify things and allow application frameworks to ensure sidecar injection on Pods that they created on behalf of their users no matter what namespace they are in.

Some more background: in our current use case we create Pods on behalf of our users in their namespaces. Our Pods should always get sidecar injection – but currently we can’t ensure that without asking the user to add the label to their namespace first. Our users may not want to do so, since adding the label istio-injection=true to their namespace will all other Pods to be injected as well unless they also add sidecar.istio.io/inject=false in all their other Pods.

@ymesika @prune998 what do you think?

tcnghia on Jun 21, 2018

May I ask how we are supposed to follow the instructions for tls prometheus integration which specifically uses sidecar.istio.io/inject: "true" ? There are a bunch of pods in the prometheus’ namespace, turning namespace injection would be a pain as we would need to retrofit a bunch of deployment to not deploy the sidecar.

if I understand @johnking0099 last comments, I should go and modify my configmap.policy to disabled for this to work ? But then, if I understand the table way up there from @tcnghia, it would break my current setup as I would have to specify the pod annotation everywhere.

This does not feel very user-friendly, and for sure, documentation is not as clear as it could be.

simonpie on Feb 4, 2021