hashicorp / nomad

Nomad is an easy-to-use, flexible, and performant workload orchestrator that can deploy a mix of microservice, batch, containerized, and non-containerized applications. Nomad is easy to operate and scale and has native Consul and Vault integrations.
https://www.nomadproject.io/
Other
14.81k stars 1.94k forks source link

Workload Identity #15614

Closed mikenomitch closed 10 months ago

mikenomitch commented 1 year ago

Proposal

As part of the Variables project for Nomad 1.4, each Nomad Task is given a signed token that encodes information about its namespace, job, task group, and task. This Nomad Workload Identity JWT is used in order to validate that the Nomad task in question has access to the secure variables requested.

We should expand upon this work in several ways:

This would allow us to greatly expand the use of the workload identity tokens for more use cases.

Use-cases

anarsen commented 1 year ago

Absolutely love that this is coming to the Hashi stack.

You mention using OIDC federation, allowing Nomad tasks to assume an AWS IAM role using the task local JWT token issued by Nomad as an example.

For this to work, the OIDC endpoints in Nomad would have to be exposed on the public Internet. While there's nothing inherently sensitive in these endpoints, HashiCorp have always recommended not exposing Nomad endpoints publicly, nor Consul or Vault for that matter. Regardless of ACL, TLS etc. At least that's been my impression.

Would your docs on this end up recommending something like exposing only the OIDC endpoints publicly then?

mikenomitch commented 1 year ago

@anarsen, the public URL issue is something we'll still need to figure out.

To be honest, I'm not sure what our solution will be, but I'm glad you've called it out here, as it'll force us to think about this early. I wouldn't want to force people to deploy a job to proxy only specific routes to the Nomad servers, but that'd be at least one way to expose just these routes. If there's some other option you, or anybody else reading this, has in mind, let me know.

I'll update this thread once we zero in on a solution for this.

anarsen commented 1 year ago

My initial thought is that the OIDC configuration endpoints are cacheable, and offloading the Nomad servers from serving these sounds like a good idea.

Proposal 1: OIDC agent

A separate Nomad agent serving only OIDC configurations. Nomad servers would push OIDC config to these agents when there are updates.

Scalable and isolated from the Nomad server memory space. Minimizes the risk of someone exposing sensitive Nomad Server endpoints publicly. However, it's yet another thing to deploy and operate.

Proposal n: TBD

tgross commented 1 year ago

Related PRs slated for the 1.5.0 release:

mcpherrinm commented 1 year ago

The OIDC /.well-known/openid-configuration and JWKS keys are relatively static I believe, and can be uploaded to a public, static webhost. AWS' own OIDC documentation suggests using S3 for your JWKS. Perhaps Nomad could include support for storing those in an S3 bucket or compatible object storage, or include a new plugin type to handle publicly exposing those files.

Even if this isn't built into Nomad, it would be easy to have an external utility which scrapes and uploads them.

tgross commented 10 months ago

Shipped in Nomad 1.7.0-beta.1