BUG/MEDIUM: prometheus: reject passwords that are not SHA-256 crypt hashes

[PixiBixi]

What

The prometheus endpoint panics when the secret named by
prometheus-endpoint-auth-secret holds a password that is not a SHA-256 crypt hash.

pkg/handler/prometheus.go split the stored value on $ and read fields 1 and 2 to
rebuild the crypt salt, without checking that these fields existed:

partsPass := strings.Split(string(password), "$")
salt := fmt.Sprintf("$%s$%s$", partsPass[1], partsPass[2])

A plaintext password, which is what an operator writes when they skip the mkpasswd
step of documentation/prometheus.md, gives a slice of one element. Reading field 1
panics. The handler runs in the sync goroutine, so the panic takes down the controller,
and it comes back at every sync as long as the secret stays in place. Any user allowed
to write a secret in a watched namespace can stop the controller.

Reproduce

apiVersion: v1
kind: Secret
metadata:
  name: prometheus-credentials
  namespace: haproxy-controller
type: Opaque
stringData:
  admin: hunter2

prometheus-endpoint-auth-secret: haproxy-controller/prometheus-credentials

With --prometheus on:

panic: runtime error: index out of range [1] with length 1
  pkg/handler/prometheus.go:108
  pkg/controller/controller.go:158

Fix

The salt is read through cryptSalt, which refuses anything that does not carry the
SHA-256 identifier. A rejected user is skipped with an error in the logs and the endpoint
keeps answering 401 for them, which is the outcome they already had: a value that is not
a hash never matches what crypt computes. The other users of the secret keep their access.

Requiring the identifier, and not only a leading $, also separates a hash from a
plaintext password that contains $. $ecret$pass$word is shaped like a hash; kept, it
would lock the user out with nothing in the logs to say why.

Second bug, same expression

cryptSalt cuts the hash at its last $ instead of at a fixed field index. A hash
carrying a rounds= parameter, which mkpasswd writes with -R, used to give
$5$rounds=N$ as the salt, losing the salt itself. That user could never authenticate,
in silence.

Going through crypt.Verify(hash, password) instead was tried and does not work here:
common.Salt.Decode does bytes.SplitN(raw, '$', 4), so on $5$rounds=N$salt$digest
the fourth field absorbs salt$digest as a whole and verification always fails. The
salt has to be extracted before the call.

Affected versions

The faulty expression was introduced by 279d16d and is present from v3.1.11 and
v3.2.0 onwards. v3.1.10 and earlier build a HAProxy userlist instead and are not
affected.

Tests

pkg/handler/prometheus_test.go, 20 subcases. The one that matters replays the
comparison prometheusHandler performs on every request: it hashes the password with
the stored salt and expects the stored hash, with and without rounds=. A salt cut at
the wrong $ passes an equality assertion on its own but fails this one.

Checked that the tests fail against the previous implementation: the first one panics
again, and the rounds= case fails.

go test ./pkg/handler/ -race     PASS
go test ./... (without e2e)      PASS
go vet ./pkg/...                 clean
make check-commit                clean