gator: support multiple default constraints per template in generated catalogs/bundles

[sozercan]

Summary

gator policy generate-catalog and gator policy install --bundle currently appear to support at most one default constraint manifest per ConstraintTemplate per bundle.

This makes it difficult for a catalog bundle to install multiple preconfigured Constraint instances that share the same ConstraintTemplate but use different names/parameters.

Current behavior

The generated catalog shape uses a single string path for each policy/bundle pair, for example:

policies:
- name: exampletemplate
  templatePath: library/example/example-template/template.yaml
  bundles:
  - example-default
  bundleConstraints:
    example-default: library/example/example-template/samples/default/constraint.yaml

Because bundleConstraints maps each bundle name to one path, a bundle cannot naturally express:

bundleConstraints:
  example-default:
  - samples/default-a/constraint.yaml
  - samples/default-b/constraint.yaml

The generator also discovers constraints from sample directories and picks a single matching/fallback constraint file per bundle, so multiple sample constraints for the same template and bundle cannot all be represented.

Separately, using a single multi-document YAML file does not seem to work with the current installer path, because the installer unmarshals the fetched constraint YAML into one unstructured.Unstructured and installs one object. A Kubernetes List object would also not behave as a set of constraints because the installer expects the object itself to be a constraint.

Desired behavior

It would be useful for Gator catalogs/bundles to support multiple default constraint manifests for the same ConstraintTemplate in the same bundle.

Possible approaches could include one or more of:

1. Allow bundleConstraints values to be a list of paths while preserving compatibility with the existing string form.
2. Allow the bundles file passed to generate-catalog --bundles to specify explicit constraint paths per policy/bundle.
3. Teach policy install to decode and install multiple constraint objects from a single multi-document manifest path.
4. Add another catalog field for bundle constraint manifests that can contain multiple objects.

Example use case

A policy catalog may want a single bundle to install:

• one ConstraintTemplate; and
• multiple default Constraint instances for that template, each with different parameters, names, match criteria, or enforcement settings.

Today this requires workarounds such as creating catalog-only alias policies, generating the catalog and post-processing it, or splitting a logically single template into multiple templates only to satisfy catalog/install limitations.

Why this matters

Supporting multiple default constraints per template would make Gator-generated catalogs more flexible and would better match how Gatekeeper itself can use one ConstraintTemplate with many Constraint instances.