search

dexidp / helm-charts

Dex Helm chart repository
Apache License 2.0
51 stars 82 forks source link

Sidecar containers support #9

Open nabokihms opened 3 years ago

nabokihms commented 3 years ago

Description

I propose to consider adding the containers section. This section will allow users to inject additional containers, e.g., a reverse proxy, GRPC API adapter, or even a database.

values.yaml

# containers:
# - name: proxy
#   image: nginx:1.19.6
#   resources:
#     requests:
#       cpu: 10m
#       memory: 32Mi

Additional info

Adding the initContainers section can also be useful for preparing config, certificates, or other assets.

sagikazarmark commented 3 years ago

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)

nabokihms commented 3 years ago

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.

saamalik commented 3 years ago

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.

sagikazarmark commented 3 years ago

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

jgielstra-cs commented 3 years ago

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

sagikazarmark commented 3 years ago

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