cc @joaopgrassi @keithmattix, looks like you're interesting in original issue.

Not sure about I understand what you said:

1. envoy didn't support read it direcetly from env or sds, see grpc and http
2. we'd better do this on controlplane instread of, otherwise we need to spread the secret to all the namespaces where sidecars are.

I see. This absolutely needs to specify it's the environment variable of the control plane, which is not intuitive.

This is a possible security risk, as someone can now trigger the control plane to send out arbitrary env vars down to proxies, which may include confidential information. Given this is in mesh config, not proxy config, that is likely ok as they are the same trust domain.

However we are still storing the credentials in envoy, accessible by config_dump,etc. We do similar for TLS, but that is all in the "secret" code paths which obfuscate the contents. I worry this doesn't really meet the goal of the original issue, as we don't actually have end to end security of the header

However we are still storing the credentials in envoy, accessible by config_dump,etc. We do similar for TLS, but that is all in the "secret" code paths which obfuscate the contents. I worry this doesn't really meet the goal of the original issue, as we don't actually have end to end security of the header

you can not avoid this happen, users who can access config_dump will be able to read nearly everything.

In my experience, most people don't have direct access to the product environment (or need permission).
It still makes sense to decouple the mesh configuration(with argo or else) from the creation of secret(manually by ops team).

Yeah good call. Maybe we just specify in the comments that:

• Its istiod env var
• Its not end to end secure