feat: add silence enforcement rules (v1alpha2)

[splattner]

What

Adds a selector-gated, off-by-default multi-tenancy control for the
observability.giantswarm.io/v1alpha2 API. When one or more rules are configured,
a Silence created in a namespace matching a rule's namespaceSelector gets an
authoritative namespace="<namespace>" matcher (plus any custom matchers from the
rule) injected into the Alertmanager silence — so a silence can only ever mute
alerts belonging to its own namespace.

Why

By default a Silence in one namespace can mute alerts from any namespace, since
a silence is just a set of Alertmanager matchers. This provides lightweight
namespace isolation for shared-Alertmanager, multi-tenant setups.

How it works

• Configured via a mounted YAML file (--namespace-enforcement-config), rendered by
  Helm from namespaceEnforcement values into a ConfigMap.
• Rules use native metav1.LabelSelector. A namespace is enforced if it matches
  any rule (OR). Empty rules ⇒ no enforcement (the default).
• Rules are first-match-wins (top-to-bottom); the first matching rule's custom
  matchers apply.
• Enforcement is authoritative: a user-supplied matcher on an enforced label is
  overridden, logged, and surfaced as a MatcherOverridden Kubernetes Event on the
  Silence.
• Evaluated at reconcile time and fail-closed — if the namespace lookup fails,
  the silence is not synced.

Example

namespaceEnforcement:
  matcherLabel: "namespace"
  rules:
    - namespaceSelector:
        matchLabels:
          tenant-isolation: "enabled"
    - namespaceSelector:
        matchExpressions:
          - key: team
            operator: In
            values: [platform]
      matchers:
        - name: cluster_id
          value: prod
          matchType: "="

[TheoBrigitte]

The overall direction does make some sense, and I understand the needs to be able to enforce some specific Silence matchers.
However I don't quite agree with the opinionated approach towards namespaces here. Alertmanager itself has no notion of namespace, this is very much a Kubernetes related concept. Therefore I would like to make this more generic.

I would suggest to give users the choice to add or not the specific namespace matcher. Instead I would suggest not to default to "namespace" when the 'matcherLabel` is empty, and rather not add it.

An example of this would be

1. Input silence

apiVersion: observability.giantswarm.io/v1alpha2
kind: Silence
metadata:
  name: my-test
  namespace: my-namespace   # this namespace is labeled with team=platform
spec:
  matchers:
  - matchType: =
    name: foo
    value: bar

2. The operator apply the following enforcement rules

namespaceEnforcement:
  matcherLabel: ""  # Can also be omitted
  rules:
    - namespaceSelector:
        matchLabels:
          tenant-isolation: "enabled"
    - namespaceSelector:
        matchExpressions:
          - key: team
            operator: In
            values: [platform]
      matchers:
        - name: cluster_id
          value: prod
          matchType: "="

3. Output silence

apiVersion: observability.giantswarm.io/v1alpha2
kind: Silence
metadata:
  name: my-test
  namespace: my-namespace
spec:
  matchers:
  - matchType: =
    name: foo
    value: bar
  - matchType: =
    name: cluster_id
    value: prod

---

If going with this then some renaming might be good, example:

• namespaceEnforcement -> enforcementRules
• matcherLabel -> namespaceMatcherLabel

[splattner]

Thanks for the review, @TheoBrigitte — I agree, as I am mainly in Kubernetes world, I'm probably biased a bit ;)

I've reworked it to be generic, with namespace scoping strictly opt-in.

• namespaceMatcherLabel no longer defaults to "namespace". When it's empty (the default), no namespace matcher is injected — a matching rule only applies its own matchers.
• Your example now behaves exactly as described: a silence with foo=bar in a team=platform namespace gets cluster_id=prod appended, foo=bar preserved, and no namespace matcher. Added unit + envtest coverage for this.
• Namespace scoping is available by explicitly setting namespaceMatcherLabel (e.g. "namespace"), which injects the authoritative ="" matcher.

Renaming (as suggested)

• namespaceEnforcement → enforcementRules
• matcherLabel → namespaceMatcherLabel
• flag --namespace-enforcement-config → --enforcement-config (ConfigMap/volume/mount renamed to match)

enforcementRules:
  namespaceMatcherLabel: ""   # opt-in; set e.g. "namespace" to enable namespace scoping
  rules:
    - namespaceSelector:
        matchLabels:
          tenant-isolation: "enabled"
    - namespaceSelector:
        matchExpressions:
          - key: team
            operator: In
            values: [platform]
      matchers:
        - name: cluster_id
          value: prod
          matchType: "="

[TheoBrigitte]

Sounds good, can you please have a look at this comment also 5249e92#r3664473297

[splattner]

Sounds good, can you please have a look at this comment also 5249e92#r3664473297

sure, but 🤔 i'm not seeing any comments there? what was it?

[TheoBrigitte]

Sorry I forgot to publish it actually.

[TheoBrigitte]

I would rather keep the v1alpha2.MatchType instead of using redefining those variables. Unless I missed something this routine is not shared with the previous CR version.

[splattner]

Good catch, thanks — you're right, that routine is only used by the v1alpha2 path (v2 controller + enforcement loader), the v1alpha1 controller builds matchers from its own bool fields. I've dropped the redefined constants and NewMatcher now takes a v1alpha2.MatchType directly, switching on the existing v1alpha2.Match* values. Pushed in 24720ba.

[TheoBrigitte]

I've merge the main branch into your PR in order to fix the CI pipeline.

[TheoBrigitte]

This looks about right to me. I'll give it a test run soon.