-
Notifications
You must be signed in to change notification settings - Fork 2k
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
Workload Identity #15614
Comments
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? |
@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. |
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 agentA 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 |
Related PRs slated for the 1.5.0 release: |
The OIDC Even if this isn't built into Nomad, it would be easy to have an external utility which scrapes and uploads them. |
Shipped in Nomad 1.7.0-beta.1 |
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
The text was updated successfully, but these errors were encountered: