I would put a hold on this until we have a strong operational use case that we can't solve otherwise (eg. a database or even a gRPC adapter can certainly be a separate service, there is no strong reason to keep that inside of the Dex boundary)

In my opinion, the main reason people may want to use a sidecar container is to protect dex. For example:

1. Dex listens on localhost (direct connections from pod network to dex are not allowed).
2. Auth proxy listens on a pod IP address.

With this, other pods can't interact with dex bypassing authorization. I do something like this in my helm-charts, though they are very opinionated. Of course, you can use network policies or service mash, or whatever instead.

So, I have no objections to wait and let users decide about the value of this feature.

Not specifically a sidecar, but my use-case is to inject the LDAP connector BINDPW via Vault agent. So ideally being able to specify a different command using the values.yaml. E.g: https://www.vaultproject.io/docs/platform/k8s/injector/examples#environment-variable-example

For now I've just copied this helm chart and added the corresponding command in the deployment.yaml.

@saamalik I'd suggest using a mutating webhook for that.

Would be nice to support an initContainer to allow for custom template/style with out having to maintain a custom image.

We'd previously used an initContainer to unzip our styling ( from a config map ) into a volume that was mounted onto the dex pod..

The feature was available here previously ( old helm2 pile-o-charts repo...) :
https://github.com/helm/charts/blob/f4f301ae450101b981805bd045451f08c0d74afa/stable/dex/templates/deployment.yaml#L46

IMHO a custom built image is much safer, because there are less moving parts at runtime.