Support Regex in Promotion Policies

[BenHesketh21]

Checklist

• I've searched the issue queue to verify this is not a duplicate feature request.
• I've pasted the output of kargo version, if applicable.
• I've pasted logs, if applicable.

Proposed Feature

It would be nice if promotion policies could accept regex for stages so that you can enable auto promotion for a group of stages with a similar name.

Motivation

We are trying to use Kargo for PR Preview environments and wanting to use auto promotion for those. But with the way promotion policies work. I would have to add a new policy every time a PR is created and remove it every time the PR was closed. I could put each PR in it's own project but that seems like it would quickly bloat the projects list page.

Suggested Implementation

I would just make the stage section of promotion policies accept regex, or have a similar option as credentials do and have a stageIsRegex bool option. And apply the policy to all stages in that project that fit the description.

[blakepettersson]

We discussed this internally and in our opinion we'd prefer to set labels on the stages themselves and then to use label selectors within spec.promotionPolicies to determine which stages are auto-promotable or not.

[BenHesketh21]

Removing as raised again here: #3670

[krancour]

Adding here, so we don't lose track of it, either regex or label selectors create a vulnerability that promotion policies were designed to avoid.

The premise behind promotion policies being configured at the project-level instead of the stage level is that there is a high likelihood of there being developers authorized to create and update stages (since it's rather technical work), but not authorized to promote (since, in many orgs, that decision might be left to someone like a product owner).

If auto-promotion were controlled at the stage level, a developer without permissions to promote, but with permissions to edit a stage could effectively promote anyway by enabling auto-promotion.

Using label selectors for this policy creates the vulnerability we were wishing to avoid. Want to enable auto-promotion on a given stage? Just update its labels. 😬

Similar can be said for regex. Stage names are immutable like all other resource names in k8s, but nothing would stop someone who can create stages from creating a new one with all the same details as the one they'd like to promote to, but naming it such that it is selected by the regex.

This left me very concerned about using either of these approaches, however, @hiddeco has correctly pointed out that using label selectors for policies is something project admins can opt-into only if they perceive its convenience to outweigh their concerns over the above, and we'd have to document it as such.

So none of this is to say that this can't or won't be done. I just don't want us to lose track of this facet of it.