Restricting manifests to specific loader builds

[Aaron Meihm]

The general workflow right now for a manifest fetch is as follows:

• The loader creates an agent environment data structure
• Loader provides it to API, if authenticated the API uses this environment to determine what manifest to return. This is done using a SQL query, the first manifest target string that matches the submitted loader environment wins.

Since this data is client provided, it is possible for a loader instance with an intentionally modified environment to fetch a manifest it shouldn't get. An example scenario might be if a manifest is created to target loaders with a specific tag, and a loader instance modifies its environment to have this tag set.

This doesn't really buy you much, but you could get a different key or AMQP credential to use to connect to the relay.

[Aaron Meihm]

One possible way to resolve this, is to add a target string to the defined loader entry in the API. After authentication occurs, we would make sure this target string matches what the loader sent.

This has the drawback of needing to specify and extra value when the loader is created, but the benefit is it prevents submission of bad environment data that could impact manifest selection.

So an example would be loader instance X, with API key Y, must send an environment that matches "tags#>>'{operator}'='myoperator'" or it will be refused

@jvehent thoughts?