Hi I am trying to perform mTLS using tlsauth in OPTIONS for one of my load test .But the problem here is that i m fetching the values of certs and key in script during test run time by calling aws secrets manager service which is defined in setup function. As tls auth is defined at options(init context level) which is the first thing to be resolved, Post i will end up seeing ssl handshake faliure.
alternatives which are not possible
- Cant use skip tls verify option as mT:S is defined as mandatory for the application
- These tests are executed in EKS (Deployed through helm chart using github actions), possible way is that during deployment process only fetch the secrets from the service and set as env variables. This requires a change in infra which is not in my control
Can anyone suggest alternatives or the latest versions of K6 resolve this options resolvations ?Please consider this as a priority
Hi @amarmalatesh,
I’m sorry, but I think that today there’s no real built-in alternative. So, I guess you will need to handle that in your own -e.g., with a script, that runs before k6, and that accommodates your k6 test accordingly-.
Also, feel free to check if there’s already any related issue within the k6 repo issues, and to leave a comment with your needs if so, or to open a new one, as a feature request, explaining your concrete needs.
I cannot promise the team will add such support soon, but having the feature request and for us to understand the user needs is the first step.
Thanks! 
Hi @joanlopez Thanks for reply. In general, data can be retrieved from external services during the setup phase, including secrets, certificates, configuration data, or files stored in cloud services. However, due to the execution model of k6, not all retrieved data can be consumed where it is needed. Certain resources, such as mTLS credentials, must be resolved during the init phase, and libraries like SharedArray require data parsing to occur in the init context as well. As a result, even though the required data can be successfully fetched from external services, k6’s phase-specific constraints can limit how and where that data can be utilized. I will try to have a look at the repo whether this has been reported or not if not i will open one.
Right now we came up with this approach where we are injecting certificates into a file path via the CI/CD pipeline (after retrieving them from Secrets Manager) is not ideal from a security and maintainability perspective. This workaround is primarily driven by the requirement that mTLS configuration be available during the init phase, rather than being dynamically resolved later in the test lifecycle.
Hi @amarmalatesh,
Yes, I know it might represent a limitation for some use cases, as yours. Looks like the suggested alternative is what you’re already doing, so I guess next step is to open a feature request (or comment to the existing one, if any), with your concrete needs/use case, so the team can consider it as a feature for one of the upcoming releases, among other competing priorities.
Contributions (as PRs) are also welcome, just in case you have interest on that.
Thanks!
