Proposal/Discussion: First-class support for async and rotating TLS credential providers in Node.js #1843
Description
Hello,
today, Node.js TLS APIs assume that credentials are static values that are available synchronously at construction time.
In practice, an increasing number of environments rely on externally provisioned identity (HSMs or workload APIs) and asynchronous availability of credentials at process startup, and short-lived credentials (minutes to hours) and continuous rotation of credentials during process lifetime.
Node.js does not currently provide a standard way to defer connection establishment until credentials are available and update credentials without reconstructing clients/agents.
As a result, applications and libraries must implement ad-hoc solutions solutions such as preiodically recreating agents, and such logic would need to be duplicated across a variety of packages and applications. This leads to fragmentation, inefficiency, and inconsistent behaviour.
A real-world scenario where this matters is SPIFFE workload identities, where local agent provides short-lived certificates and keys for client authorisation and mTLS.
I would like to open this discussion to expore different ways to solve this issue. Other ecosystems (Go, Java) are much more mature on this front, and I have not found any discussions related to this so far. Perhaps pushing this all the way into libraries is more correct in the end? But I believe there is a point in exploring this at the level of the Node.js networking API itself to solve this for all use cases at once.
A minimal way in which this could be implemented is to expand tls.connect to accept an async iterable object that is 1) initially awaited on the first connection, and 2) updates the credentials for new connections once new values are available. Alternatively a credential provider object that provides both a promise of current credentials and a subscription hook for future updates that each return options accepted by tls.createSecureContext.