Make tlsAuth configureable during runtime

[LukasAuerbeck]

Feature Description

We are trying to test a user registration flow protected with client certificates. The process from a high level is:

• Each user has by default access to a shared client certificate that is used to initially connect to the API, where a personalized client certificate is issued
• Use personalized client certificate to authenticate + authorize access to finalize registration and user setup

Because of this we need to update the global options, containing the tlsAuth, to use the personalized client certificate and the matching key. Updating the options during the runtime however doesn't change the behaviour of further requests, due to still using the default, shared certificate. Is there any way to force the VU to reinitiate the http client used to perform the connections and thus to use the latest options/certificates?

This seems to generally be the case for all/multiple fields in the options, since e.g. changing the log behaviour via the httpDebug field doesn't apply either:

import http from 'k6/http';

export var options = {
    httpDebug: 'full'
}

export default function () {
    options.httpDebug = null
    http.get("https://k6.io")
}

  scenarios: (100.00%) 1 scenario, 1 max VUs, 10m30s max duration (incl. graceful stop):
           * default: 1 iterations for each of 1 VUs (maxDuration: 10m0s, gracefulStop: 30s)

INFO[0000] Request:
GET / HTTP/1.1
Host: k6.io
User-Agent: k6/0.34.1 (https://k6.io/)
Accept-Encoding: gzip

  group= iter=0 request_id=3fb5a0bd-6ef3-4920-7eec-5ac1ec423149 scenario=default source=http-debug vu=1
INFO[0000] Response:
HTTP/2.0 200 OK
Content-Length: 505010
Age: 181475
..............

In #1045 (comment) one of the suggested solutions is to make the used client configurable via js, this would also solve the issue of using multiple client certificates.

[na--]

Thanks for opening this issue, it's a very valid use case that we unfortunately don't currently support... 😞 As you've found out, the script options are global and currently shared among all VUs and HTTP requests, and you can't change them from the script after the init context has been executed. Similarly to the issue you linked to, this would require either a per-request option or a new HTTP API that is capable of having different HTTP Client objects that are created in the VU contexts.

[MaksimKlyu]

It's really important to us. This function is similar to "JMeter Keystore Configuration". =)
https://jmeter.apache.org/usermanual/component_reference.html#Keystore_Configuration.

[ansel1]

This is also a key feature for us. The API we are testing uses client certs auth, and having each VU represent a unique client identity is critical to simulating meaningful load.

[imiric]

We won't be changing this in the current HTTP API, but this will be possible in the new API (initial design document). We're still ironing out the design and syntax, so you can follow the issue and document for details.

I'll close this issue in the meantime, as we want to keep a clean roadmap.