Failing to instantiate OIDC authenticator when --oidc-ca-file is not specified about kube-rbac-proxy HOT 6 CLOSED

In the context of the original image, yes, there is just one, but a lot of organizations repackage the project AFAIK.
Also I would bind myself to an image / distro. I am really hesitant about that. I gave the example of mkcert as I was curious how they manage different possibilities.

E.g. bitnami uses mini-debian? kubebuilder seems to do some repackging too? Red Hat uses a RHEL image.

I can reach out for a second opinion to other maintainers.

from kube-rbac-proxy.

Wouldn't it be better to specify --oidc-ca-file=/etc/ssl/certs/ca-certificates.crt?

This is also a very specific path: There are at least 4 different paths in Linux distributions.

I am not completely convinced that the added complexity is worth it, but I might be missing context.

from kube-rbac-proxy.

The default location is based on the base image gcr.io/distroless/static:nonroot. I guess mkcert needs to consider all those options as it shall run/support different env. In the case here, the base image is not a moving part or at least we know the exact env on which the kube-rbac-proxy needs to run. It can check a set of 'default' locations but we always know which one will be used at the end. IMHO it is a fair trade off.

from kube-rbac-proxy.

Yep it is a valid case. Different distributions manage the case differently. Just for a reference here are some links:

• RedHat
• Debian
• openSuSE
  Probably these locations can also change with new releases, but still a set of default locations can be compiled, taking care for the majority of the cases. No objections at all.

from kube-rbac-proxy.

I talked to @s-urbaniak and he wasn't convinced either. I hope you are not disappointed.

Thx for your frequent contributions.

from kube-rbac-proxy.

@ibihim No not at all. The project owners/maintainers decide on if or how to solve cases.

from kube-rbac-proxy.