Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Appearance settings

alertmanager: honor optional MSTeams webhook secrets#8448

Open
GauravJ3 wants to merge 2 commits intoprometheus-operator:mainprometheus-operator/prometheus-operator:mainfrom
GauravJ3:codex/fix-optional-msteams-webhookGauravJ3/prometheus-operator:codex/fix-optional-msteams-webhookCopy head branch name to clipboard
Open

alertmanager: honor optional MSTeams webhook secrets#8448
GauravJ3 wants to merge 2 commits intoprometheus-operator:mainprometheus-operator/prometheus-operator:mainfrom
GauravJ3:codex/fix-optional-msteams-webhookGauravJ3/prometheus-operator:codex/fix-optional-msteams-webhookCopy head branch name to clipboard

Conversation

@GauravJ3
Copy link
Copy Markdown
Contributor

Description

Honor SecretKeySelector.optional for Microsoft Teams webhook secrets in
AlertmanagerConfig processing.

This change makes optional missing webhook secrets and keys non-fatal in the
shared secret loader and skips the affected MSTeams receiver entry when
rendering Alertmanager configuration. That keeps the rest of the
AlertmanagerConfig valid instead of failing reconciliation.

Closes: #7264

Type of change

  • CHANGE (fix or feature that would cause existing functionality to not work as expected)
  • FEATURE (non-breaking change which adds functionality)
  • BUGFIX (non-breaking change which fixes an issue)
  • ENHANCEMENT (non-breaking change which improves existing functionality)
  • NONE (if none of the other choices apply. Example, tooling, build system, CI, docs, etc.)

Verification

  • Added regression tests for optional missing secret and key lookups in the
    shared assets store.
  • Added AlertmanagerConfig validation coverage for optional missing MSTeams
    webhook secrets.
  • Added config generation coverage to ensure the MSTeams receiver is omitted
    when its optional webhook secret is missing.
  • Ran:
    go test ./pkg/assets ./pkg/alertmanager -run 'TestGetSecretKey|TestCheckAlertmanagerConfig|TestGenerateConfig|TestInitializeFromAlertmanagerConfig'

Changelog entry

Honor optional MSTeams webhook secrets in AlertmanagerConfig processing instead of failing reconciliation when the secret or key is missing.

AlertmanagerConfig currently treats optional MSTeams webhook secret
references as mandatory, which prevents config validation and
rendering when the secret or key is absent.

Teach the shared secret loader to honor SecretKeySelector.optional
and skip MSTeams receiver entries whose optional webhook secret is
missing. Add regression tests for store lookups, AlertmanagerConfig
validation, and rendered Alertmanager config output.

Closes prometheus-operator#7264

Signed-off-by: Gaurav Joshi <gauravjoshi12379@gmail.com>
@GauravJ3 GauravJ3 requested a review from a team as a code owner March 14, 2026 09:57
@GauravJ3
Copy link
Copy Markdown
Contributor Author

GauravJ3 commented Mar 14, 2026

Thanks for taking a look. I checked the failing CI job, and the only failing check is the ThanosRuler e2e job:

  • job: E2E tests (thanosruler)

  • test: TestAllNS/z/ThanosRulerStateless

  • error: waiting for alert 'alert1' to fire: context deadline exceeded: expected 1 query result but got 2

  • This looks unrelated to the change in this PR, which only touches Alertmanager/MS Teams optional secret handling plus focused unit coverage. I also tried to rerun the failed job from my fork account, but GitHub requires admin rights on the upstream repository for that.

If this looks flaky on your side as well, could someone please rerun the failed e2e job?

Copy link
Copy Markdown

@Fresa Fresa left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the PR, looks great! I just had some small comments.

I'm not an owner/maintainer of this repo just as a FYI.

},
golden: "CR_with_MSTeams_Receiver_Partial_Conf.golden",
},
{
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe we should add a test for v2 as well?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi @Fresa sure let me check on this

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Added MSTeamsV2 coverage in the follow-up commit so the config-generation path now has the same optional-missing-secret regression test as v1. Thanks for the catch.

},
ok: false,
},
{
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same here I guess; a v2 test?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Added the matching MSTeamsV2 validation coverage as well, so both the operator-side validation test and the config-generation test now cover v2.

Add validation and config-generation coverage for optional missing
MSTeamsV2 webhook secrets so the regression tests match the v1
MSTeams coverage added in the previous commit.

Signed-off-by: Gaurav Joshi <gauravjoshi12379@gmail.com>
@simonpasquier
Copy link
Copy Markdown
Contributor

Thanks for looking at this! As I wrote in #7264 (comment)

The semantics of the optional field for secret key refs aren't consistent across the API. In this case, the operator needs to copy the secret content to another secret meaning that optional: true isn't possible.
I'm not sure how to solve the issue except with better documentation and an API change to remove the optional field.

We have a chicken-and-egg problem because 1) the secret doesn't exist before the pods are created and 2) Alertmanager won't start if the msteams receiver has no webhook URL. In the best case, I assume that the pods will fail to start until the operator reads the secret but I haven't checked in real life.

The limitation is also not restricted to the msteams receiver but applies to all AlertmanagerConfig fields of type SecretKeySelector and any related change requires a wider impact analysis.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

AlertmanagerConfig's msteams optional webhookurl secret is not respected

3 participants

Morty Proxy This is a proxified and sanitized view of the page, visit original site.