[alertmanager] Readiness/liveness probe failed when using basic auth

[yunex-ts]

Describe the bug a clear and concise description of what the bug is.

In a centrally running alertmanager opening and secured with basic auth, readiness and liveness probe will fail with error 401. Only http probes are allowed and not, like in prometheus, tcp checks

What's your helm version?

v3.15.2

What's your kubectl version?

v1.31.2

Which chart?

alertmanager

What's the chart version?

1.13.1

What happened?

I switched web.config to basic auth and the liveness and readiness probes failed with 401. Pod, of course, restarting

What you expected to happen?

I want to see liveness and readiness probe more configurable like in prometheus chart.
in values.yaml:

tcpSocketProbeEnabled: false
probeScheme: HTTP
readinessProbeInitialDelay: 30
readinessProbePeriodSeconds: 5
readinessProbeTimeout: 4
readinessProbeFailureThreshold: 3
readinessProbeSuccessThreshold: 1
livenessProbeInitialDelay: 30
livenessProbePeriodSeconds: 15
livenessProbeTimeout: 10
livenessProbeFailureThreshold: 3
livenessProbeSuccessThreshold: 1

in templates/statefulset.yaml:

readinessProbe:
  {{- if not .Values.tcpSocketProbeEnabled }}
  httpGet:
    path: {{ .Values.prefixURL }}/-/ready
    port: 9090
    scheme: {{ .Values.probeScheme }}
    {{- with .Values.probeHeaders }}
    httpHeaders:
  {{- toYaml . | nindent 14 }}
    {{- end }}
  {{- else }}
  tcpSocket:
    port: 9090
  {{- end }}
  initialDelaySeconds: {{ .Values.readinessProbeInitialDelay }}
  periodSeconds: {{ .Values.readinessProbePeriodSeconds }}
  timeoutSeconds: {{ .Values.readinessProbeTimeout }}
  failureThreshold: {{ .Values.readinessProbeFailureThreshold }}
  successThreshold: {{ .Values.readinessProbeSuccessThreshold }}
  livenessProbe:
  {{- if not .Values.tcpSocketProbeEnabled }}
  httpGet:
    path: {{ .Values.prefixURL }}/-/healthy
    port: 9090
    scheme: {{ .Values.probeScheme }}
    {{- with .Values.probeHeaders }}
    httpHeaders:
  {{- toYaml . | nindent 14 }}
    {{- end }}
  {{- else }}
  tcpSocket:
    port: 9090
  {{- end }}
  initialDelaySeconds: {{ .Values.livenessProbeInitialDelay }}
  periodSeconds: {{ .Values.livenessProbePeriodSeconds }}
  timeoutSeconds: {{ .Values.livenessProbeTimeout }}
  failureThreshold: {{ .Values.livenessProbeFailureThreshold }}
  successThreshold: {{ .Values.livenessProbeSuccessThreshold }}

How to reproduce it?

Just activate basic-auth in alertmanager

Enter the changed values of values.yaml?

extraSecretMounts:
  - name: admin-generic-secret-mount
    secretName: admin-pass-secret
    mountPath: /etc/secret
    subPath: ""
    readOnly: true
extraArgs:
  web.config.file: /etc/secret/web.config.yml
```

### Enter the command that you execute and failing/misfunctioning.

helm install alertmanager prometheus-community/alertmanager --version 1.13.1 --values values.yaml

### Anything else we need to know?

_No response_

[zeritti]

The chart may not be offering a flexible configuration at the moment but tcpSocket can still be defined in most conditions:

livenessProbe:
  httpGet: null
  tcpSocket:
    port: http
readinessProbe:
  httpGet: null
  tcpSocket:
    port: http

[yunex-ts]

I tried that of course 👍
But it does not work. I cant select two types is the error message

[yunex-ts]

It will work in case there is a condition within the template to not add that key if httpGetis null

[zeritti]

I see. I cannot make it error out, though, the chart gets rolled out straight away with the changed probe type. I reckon it would fail in case of being installed as a subchart.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Any further update will cause the issue/pull request to no longer be considered stale. Thank you for your contributions.