Skip to content

[improve][fn] PIP-478: propagate the TLS provider pins to function-instance clients #26378

Description

@lhotari

Since #26326 the functions worker's own PulsarClient and PulsarAdmin carry all three
brokerClient* provider pins (brokerClientSslProvider, brokerClientJsseProvider,
brokerClientJcaProvider), and an embedded worker inherits them from the broker configuration.

The clients created inside a function instance do not. FunctionRuntimeManager reduces WorkerConfig
to AuthenticationConfig, which has no engine, JSSE or JCA provider fields, so the thread-runtime
function client — and the admin optionally exposed to functions — cannot inherit the worker's provider
selection. A FIPS deployment that pins BCJSSE and BCFIPS for the worker gets function instances running
on the JVM provider search order.

This is outside PIP-478's stated scope, which promises the pins on the worker's own client and admin,
so it does not block #26326. Closing it means extending the function-instance authentication
configuration and the runtime handoff to carry the applicable pins, deciding whether a local-run override
or the worker default wins, and testing both the runtime client and the exposed admin.

Found while verifying #26326.

Deferred out of #26326 as agreed in review; see the re-review summary for where it sits relative to that PR.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions