Confusing Config options w/ OIDC discovery

[johnharris85]

The readme for OIDC indicates that either ACME or unix listen socket are required. They aren't (works fine without) and the checks for this condition (https://github.com/spiffe/spire/blob/master/support/oidc-discovery-provider/config.go#L138) are broken anyway :smile:

I'm assuming there isn't a technical reason one or the other are required (as I have it working just fine). Propose we just remove the readme requirement (and the erroneous check)? If it's for security we can add a note to warn users? Happy to submit a PR if folks agree.

• Version: 0.9.2
• Platform: Ubuntu 18.04 w/K8s 1.16.3
• Subsystem: OIDC Discovery

[evan2645]

The readme for OIDC indicates that either ACME or unix listen socket are required. They aren't (works fine without)

Hmm that's definitely a bug. IIRC we made a purposeful choice to disallow configurations that result in an unprotected server due to the sensitivity of the endpoint. I'm not sure if we want to overturn that decision - I don't personally feel like we should.

If you really want to serve it insecurely, then you can serve it using a simple http server over the UDS. That was the intention, anyway. I'm curious to hear more about what you're trying to accomplish

[johnharris85]

I'm running it in cluster and don't want this component to be responsible for any ACME certs. I'm using cert-manager for that (terminating TLS @ contour ingress for my PoC). If we want to guarantee TLS to the pod can we specify that TLS cert and key are required fields if ACME is disabled? And hook that up to a TLS listener? That would enable users to manage their own ACME certs and then just TLS passthrough?

For the UDS I have the overhead of creating / managing that local server.

[evan2645]

If we want to guarantee TLS to the pod can we specify that TLS cert and key are required fields if ACME is disabled? And hook that up to a TLS listener? That would enable users to manage their own ACME certs and then just TLS passthrough?

That sounds super reasonable to me! And yes so long as that works for you, I think it fits the bill nicely.

ACME || Cert + Key || UDS

[marcofranssen]

What is the state of this proposal in Spire 0.12.3? Trying to run this on my localhost k8s cluster and preferably would also like to have another component be responsible for the acme termination in my eks cluster.

Any guidelines on how to make this work? Trying to build this into this Helm chart.

https://github.com/philips-labs/helm-charts/tree/main/charts/spire

See this PR for the current WIP to add OIDC component to the Helm chart.

https://github.com/philips-labs/helm-charts/pull/24

[github-actions[bot]]

This issue is stale because it has been open for 365 days with no activity.

[github-actions[bot]]

This issue was closed because it has been inactive for 30 days since being marked as stale.