Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Push out deprecation of Authentication Without Workload Identity to 1.11 or further #24970

Closed
lattwood opened this issue Jan 28, 2025 · 1 comment

Comments

@lattwood
Copy link
Contributor

lattwood commented Jan 28, 2025

Proposal

Push out deprecation of Authentication Without Workload Identity to 1.11, and/or until hashicorp/vault#29435 is addressed.

Edit: there is precedent, it was originally scheduled for deprecation in 1.9 but it was pushed out.

Use-cases

I want to run my cluster in adherence with Hashicorp best practices, which necessitates the use of mutual TLS authentication, while also having Vault fetch required metadata from Nomad using said mutual TLS process.

Attempted Solutions

The alternatives presented require some Rube Goldberg-esque machinations that on a long enough timeline would fail and break JWT/OIDC trust between Nomad and vault.

@gulducat
Copy link
Member

Hey there @lattwood, thanks for reaching out.

I suppose you're referring to our Upcoming release notes? We have had long-standing plans to remove the old auth workflows for Consul and Vault, and we intend to stick to our current plan.

For perhaps some amount of reassurance, our security model states

Using tls.verify_https_client=false downgrades the Nomad agent HTTP server to use TLS instead of mTLS. This is safe if ACLs are enabled and is recommended if you are using the Nomad web UI to avoid the difficulty of distributing client certificates to browsers.

and the link for the configuration also similarly states

By default, verify_https_client is set to false, which is safe so long as ACLs are enabled.

So, with ACLs enabled, disabling client cert validation is still operating within Nomad's security model. This is common, usually for ease of UI/CLI access, and it also applies to the JWKS URL that Vault (and any other systems) hit to verify workload identity tokens.


For the general case, only standard TLS is required for the JWKS URL, so the system that wants to verify a JWT knows that the public key(s) are from the appropriate source. Beyond that, for better or worse most systems out there do not support sending client certs with requests to JWKS URLs, so setting up Rube Goldberg-esque machinations (a proxy or a cache or similar) is required in most cases anyway, if verification is enabled. We've gone back and forth on it a lot internally, but it's an unfortunate reality that needs to be handled differently by folks depending on their Nomad cluster environment, if client TLS verification is a hard requirement despite ACLs being enabled.

I can appreciate your concern, and hope it doesn't cause too much headache, but we'll be proceeding with the deprecation as planned.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants