[stigglor]

Summary

Adds an optional auth setting on both components, supporting the bearer, basic, and custom strategies via a new VectorAuthConfig type that reuses the existing HTTP auth header logic.

The sink sends the credentials on every request, including the health check. The source validates incoming requests with a tonic interceptor using a constant time comparison, and rejects mismatches with an Unauthenticated status. The standard gRPC health service stays open so liveness probes do not need credentials. The token is a normal config value, so it can come from a secrets backend with SECRET[...].

Vector configuration

How did you test this PR?

The bearer-token auth was verified at two levels. Automated: unit tests for the source covering a matching token auth_roundtrip, a missing token, and a wrong token, both rejected with Unauthenticated, plus a constant-time-compare test and an http test confirming VectorAuthConfig produces the right Authorization header for bearer/basic/custom.
End-to-end: a single live vector process wired as demo_logs → vector sink → vector source → console, where matching tokens delivered all 5 events to the console, and a mismatched token produced zero delivered events with the source returning Unauthenticated: "Valid authorization token required.", a failed healthcheck, and the request correctly dropped as non-retriable.

Change Type

• Bug fix
• New feature
• Dependencies
• Non-functional (chore, refactoring, docs)
• Performance

Is this a breaking change?

• Yes
• No

Does this PR include user facing changes?

• Yes. Please add a changelog fragment based on our guidelines.
• No. A maintainer will apply the no-changelog label to this PR.

References

Closes #2017

[stigglor]

@pront 👋 Any timelines on potentially getting this one merged given it's a somewhat smaller change? mTLS auth is unrealistic for larger platforms, and hence being able to use http/2 across our Vector fleet would be a big win.

[pront]

@pront 👋 Any timelines on potentially getting this one merged given it's a somewhat smaller change? mTLS auth is unrealistic for larger platforms, and hence being able to use http/2 across our Vector fleet would be a big win.

Hi @stigglor, can you resolve the merge conflicts? I will review shortly.

[pront]

Could we ensure custom credentials are redacted throughout this path? Auth::apply_headers_map() logs the complete custom value when header parsing fails. For example, a secret containing a trailing newline gets written to the error log before the source or sink fails to build. This also affects credentials resolved through SECRET[...].

I reproduced this with a dummy credential:

ERROR ... Invalid custom auth header value. value=SSWS dummy-custom-secret

Valid custom headers also have is_sensitive() == false, whereas basic and bearer headers are marked sensitive. Could we use SensitiveString for the custom value, avoid logging its contents on validation errors, and mark the resulting header sensitive?

[stigglor]

Fixed in bcf7d04. custom is now a SensitiveString, the header is marked sensitive for all three strategies, and an invalid value now fails the build with an error that names auth.value without logging its contents. Your trailing newline example is covered by authorization_header_error_omits_credentials.

[stigglor]

Hey @pront, sorry for the slow reply on this one, and thanks for taking a look!

I've merged master in and sorted the conflicts. The sink moved over to ValidatedSink with multiple endpoints since I opened this, so the auth header now goes to every endpoint and to the healthchecks too. The plaintext warning also checks each endpoint's scheme now, since TLS follows the URL rather than the tls block.

Good catch on the redaction! The custom value is now a SensitiveString, and the header is built directly rather than going through Auth::apply_headers_map, so nothing gets logged when a value is invalid. The error just names the option (auth.value) without the contents. All three strategies are marked sensitive now as well, which keeps the value out of the HPACK dynamic table on the HTTP/2 connection. I added a test using your trailing newline example.

The shared Auth::Custom on master has the same logging and sensitivity gap for the HTTP components. Happy to put up a separate PR for that if it'd be useful?

Should be ready for another look whenever you get a chance 🙂