OIDC client-secret gets passed to the proxy as a cli argument even if set as a Secret

[PastNullInfinity]

The Proxy Injector supports taking parameters as a Secret, which would have made me believe that the injected sidecar would do the same, which is not the case.

When configuring the sidecar container, the ProxyInjector will always set the configuration of Gatekeeper as command line arguments,making the whole point of passing sensitive variables as a Secret moot.

In particular, these lines are problematic:

ProxyInjector/internal/pkg/handler/create.go

Lines 199 to 201 in 63fc7ea

	if config.ClientSecret != "" && annotations[constants.AnnotationPrefix+"client-secret"] == "" {
	configArgs = append(configArgs, "--client-secret="+config.ClientSecret)
	}

What i would expect is that the ProxyInjector controller would create a separate Secret for the client-secret, and mount it as a VolumeMount inside the Gatekeeper container.

As it stands, this issue makes the whole premise of the {{- if eq .Values.proxyinjector.mount "secret" }} option inside the configuration of ProxyInjector pretty much useless ☹️

[usamaahmadkhan]

@PastNullInfinity Thank you for opening an issue. Does gatekeeper provides support to get the secrets from Environment variables instead of cli? If yes, then we can just set them and this can be resolved.

[PastNullInfinity]

@PastNullInfinity Thank you for opening an issue. Does gatekeeper provides support to get the secrets from Environment variables instead of cli? If yes, then we can just set them and this can be resolved.

Unfortunately not, only through cli flags or via the config.yaml.

For now I have a (admittedly, pretty hacky) workaround: I've made a new dockerfile for gatekeeper that passes $CLIENT_SECRET as a flag to gatekeeper, and then I've modified the patch that ProxyInjector applies in order to also add an env: declaration with a reference to a Secret containing the key.

As far as I can tell, there's no easy way to set the secret without mounting it as a file (so a volumeMount), or by editing the dockerfile itself.

I realize also that adding a volume would mean to change quite a bit of the current patch method, since it only cares for the container spec right now.

[PastNullInfinity]

Ping for this issue. If the proposed solution seems usable, I can start to work on a PR.
Otherwise, I'm happy to help with changing the Patching method in a way that solves this issue