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.
The acl.ACL objects are expensive to create, so we cache them on the server after they've been resolved from the token (or claim). The cache is keyed by a hash of the policies and not the token, so without considering Task Access to Variables most acl.ACL objects we get from WIs are going to be the same and will cache efficiently. Unfortunately when you add Task Access to Variables implicit policies, every WI will have a different cache key and that'll explode the number of acl.ACL objects we need to cache if there are a lot of them. This will push user-tokens out of the LRU.
A couple of ideas we'll want to explore:
Is there a way to create an efficient "pattern matching" policy that can be matched against the Variables paths without having to have a separate policy for each and every WI? (That's also https://github.com/hashicorp/nomad/issues/14764)
Is the memory usage so much that we can't just split out the WI ACL objects to their own cache, so that we don't push user-tokens out of the LRU cache?
Workload-Associated ACL Policies are ordinary ACL policies with the appropriate job/group/task fields set. This is suitable for use with most APIs, as shown in https://github.com/hashicorp/nomad/pull/15870. But the implicit Task Access to Variables pseudo-policies need special handling for the Variables RPC, which feels likely to result in a security bug eventually.
The
acl.ACL
objects are expensive to create, so we cache them on the server after they've been resolved from the token (or claim). The cache is keyed by a hash of the policies and not the token, so without considering Task Access to Variables mostacl.ACL
objects we get from WIs are going to be the same and will cache efficiently. Unfortunately when you add Task Access to Variables implicit policies, every WI will have a different cache key and that'll explode the number ofacl.ACL
objects we need to cache if there are a lot of them. This will push user-tokens out of the LRU.A couple of ideas we'll want to explore: