Support partial wildcards in intentions.

[sluebbert]

Feature Description

Intention validation, documentation, and source code all point to not allowing intentions with wildcards in names or source names.

For example, in source, several comments document:

... but only the full value can be a wildcard. Partial wildcards are not allowed.

We have designed around this limitation a few times now, but having native support would simplify things quite a bit for us.

Use Case(s)

1. Our automation at times creates a few jobs to represent the same batch app, but with separate cron schedules and separate arguments being passed in. This job may be the "OrderMainenanceJob", for example. A single "app" that can perform different, similar behaviors based on the arguments passed in at run time. So we may have this app scheduled to do task A every 10 minutes, and task B every hour.

   The Nomad jobs to represent task A and task B may be named ordermanagementjob-a and ordermanagementjob-b. We must make their Consul service name be ordermanagementjob instead of one that better matches the job's actual name because we don't want to manage the several individual intentions of ordermanagementjob-a → orderservice and ordermanagementjob-b → orderservice.

   It would be better to manage the single intention of ordermanagementjob-* → orderservice.

2. For the sake of running integration tests, a test sandbox, or tightly coupled apps within a single job, we may have dozens of services in a single job that fundamentally just need to communicate with each other with a few exceptions. These services in a single job do not share Nomad groups to allow better distribution and scheduling of the whole job across the data center. So to communicate with each other, they must be setup as Consul services, which then gets us into the realm of managing intentions for them. Since they all sit in the same job, we prefix their service names with a unique identifier shared across all of them. This ensures we can deploy multiple flavors of similar jobs that will not directly conflict with each other.

   It would be very helpful if we could have wildcard prefixes in this situation. Given my job with the name of monsterjob-12345 that contains 15 apps / services with service names like monsterjob-12345-orderservice, monsterjob-12345-paymentservice, monsterjob-12345-processingservice, etc. Building the combinations of intentions here without partial wildcards in a default deny all service mesh is a bummer.

   It would be great to have a single wildcard intention like monsterjob-12345-* → monsterjob-12345-* or monsterjob-12345-* → * or * → monsterjob-12345-*.

   I'm primary documenting this one for integration testing or transient service sandbox "environments" for the sake of development and testing. While even though we can automate the creation of dozens of combinations of intentions for a job, we then have to worry about the cleanup and what happens when cleanup fails leaving us with growing dead intentions. Having a single intention to manage, even when automated, is better than doing the same with 30+ intentions.

While I know the above items have alternative solutions such as namespaces, different data centers, or those alternatives mentioned above, from our point of view, partial wildcards in intentions would allow us to simplify things or to use less resources.

[t-davies]

+1 we have a similar use case, in ephemeral test environments spun up for pull requests.

These start up services with the same name but with a suffix (e.g. demo-service, may have an ephemeral test version of itself named demo-service-abc12345).

We currently have a background task watch for new ephemeral apps starting, query Consul for the intentions that the real deployed service would have in the same environment, and then create those intentions for the ephemeral copy. We can't do this from the job that deploys the ephemeral service since it would then need permissions to modify intentions for services other than the one it deploys.

But this could be greatly simplified if we could simply say "demo-service-*".