k6 inspect fails when secrets are used in init context

[vtorosyan]

Description

k6 inspect (and k6 archive) error out when a script calls secrets.get() at the top level (init context), even though the script runs correctly during normal execution. This is a common pattern among k6 users.

Steps to reproduce

// secrets.js
import secrets from 'k6/secrets';

const secretValue = await secrets.get('secret_name');

export default function() { }

$ k6 inspect secrets.js
ERRO[0000] no secret sources are configured   hint="script exception"

Expected behavior

k6 inspect is an analysis command — it should not require a fully configured secrets source to introspect a script's options. Ideally, it would either:

• silently skip secret resolution during inspection, or
• complete successfully and include a note in the output that the script requires a secrets source at runtime.

What works today

Moving the secrets.get() call inside the default function works:

export default async () => {
    const secretValue = await secrets.get('secret_name');
}

Passing the exact secrets via CLI also works, but is not always feasible:

$ k6 inspect --secret-source=mock=secret_name=value secrets.js

Context

This affects Synthetic Monitoring, where k6 inspect runs in a sandboxed environment that intentionally has no access to the secrets source — that is a security property of the environment, not a configuration gap. As the number of SM users grows, the number of scripts using top-level secrets.get() is also growing, making this a blocker for our preprocessing pipeline.

A possible approach is discussed in PR #6092, which proposes a dummy secret source that returns an empty value for any requested secret and never errors. This would allow k6 inspect to run without requiring a real secrets source. We'd welcome input from the core team on whether this direction is acceptable or if there's a cleaner path.

[mem]

silently skip secret resolution during inspection, or

Please note that the way k6 inspect works requires the script to be (at least partially) evaluated. The options block itself (which is required for k6 inspect to do its job) is a constant and it's possible that its value is dynamically computed. E.g. something has simple as parameterizing one its values by reading from the environment.

Also note that the following valid construct has been observed in the wild, it's not just hypothetical:

const username = await secrets.get(`username`);

Even worse, this has been observed in the wild:

const username = await secrets.get(`username`);
if (username == "") {
   throw ...;
}

[mstoykov]

I would consider this ... the expected behaviour.

As mentioned k6 inspect needs to evaluate the script in order to get the options.

A secret is not forbidden and is working in the init context if configured. A secret can be part of the options or can be used to change the options.

So IMO there are 2 paths forward:

1. you run with the real secrets so the user can run it correctly - arguably the correct approach.
2. you decide that yo uwant the "dummy" solution and just build an extension for it - that dummy solution can even I guess give random values back, just to get around teh checking for empty values.

Realistically we can have a variant of 2 as an option within k6 - but to be honest if the only user will be SM, I would prefer for that to be owned by you.

Again the problem is that inspect needs to execute and the execution of the code (including the end result of the inspect) is dependant on the secrets.

The not strange solutions are:

1. require to configure secrets all the time
2. ... not allow secrets in the init context, which at this point will be considered a breaking change.

And you can enforce 2 as well - I guess you are practically enforcing it now.

[mem]

I would consider this ... the expected behaviour.

If that's the case, how is this not true:

k6 inspect is an analysis command — it should not require a fully configured secrets source to introspect a script's options.

We agree that evaluating the top level context of the script is necessary, but I think we disagree on whether real secret values must be made available to k6 inspect.

1. "Evaluate the init context" is not the same as "resolve every init operation at production fidelity"

   Yes, we must run init to obtain the options constant. But init routinely performs operations whose real value is unavailable or irrelevant at inspect time: reading env vars, open()-ing files, computing values from the clock, etc. k6 does not hard-abort on those. A missing env var yields "" and inspection proceeds. Secrets are the only init-time input that is singled out for a fatal error. This is an inconsistency (a defect), not a principle. I understand the need to evaluate the init context, but that does not justify demanding that one particular side-effecting call succeed with a genuine value. I have the same issue with the init context reaching out to the filesystem and the network.

2. The hard failure is a policy choice in the secrets module, not a property of inspection

   "no secret sources are configured" is the module refusing to answer. That's a deliberate UX guard so real runs fail loudly. That guard is correct for run. Treating it as an intrinsic requirement of inspect does not follow though: inspect needs init to complete, not to obtain the actual secret values. The whole point of the dummy-source workaround is to show the guard can be satisfied structurally without any real secret existing.

3. archive makes the "expected" framing self-contradicting

   archive exists to bundle a test to be run elsewhere, in the environment that actually holds the secrets. Requiring the secret source to be present at archive time inverts the contract: you'd have to possess the runtime secret in the build/packaging environment in order to produce an artifact whose entire purpose is deferred execution somewhere else. So the tooling forbids the exact workflow it was built to enable.

4. "Run with real secrets" is a security regression, not a fix

   You are correct that this issue was discovered in the context of Synthetic Monitoring, where k6 inspect runs in a sandbox has no secret access by design: it's a security boundary, not a misconfiguration. My initial expectation was to be able to avoid network access, too, but that does collide with remote imports, which k6 encourages. Supplying the real secrets in that environment would require injecting production secrets into an environment specifically built to exclude them.

5. "Just build an extension" is arbitrary offloading

   The need (introspect/package a script without resolving runtime secrets) is generic: any CI step that validates a script, any deferred-execution archive, any static-analysis pipeline hits it. It is true that Synthetic Monitoring is the context where this issue was identified, but it's not the only one. Even in the Synthetic Monitoring case, the context where this was identified is closer to the CI pipeline or static-analysis cases: we simply want to be able to run k6 inspect in order to perform validations on the script. k6 already ships first-party mock and cloud sources; the dummy source is a trivial generalization of mock (return something for any key instead of a fixed map). Pushing a one-file, general-purpose capability into an out-of-tree extension, while equally-niche sources live in-tree, isn't a consistent boundary. Along the same lines, k6 already includes implementation details (and entire functionality) that are specific to Grafana Cloud k6. Singling out Synthetic Monitoring as the odd case doesn't make sense.

In the context of this issue I'm not arguing that #6118 is the correct solution, but it's the closest I could get. I'm fully open to alternatives. The approach in that PR does have edge cases, and I don't think it's possible to fix them. For example, if a script retrieves a token in the init context and then proceeds to use that token to obtain data necessary for building the options value, that will fail. If somebody is actually doing that, we will tell them that even if that's allowed by the language, it's not supported by Synthetic Monitoring. I would certainly prefer it if that position could be made uniform across k6 because it does open the door to security issues. For example, I do not expect the output of k6 inspect to contain any sensitive data, and I do not intend to treat it as if did. We built the secrets feature precisely to avoid that kind of situation, which is the reason why we restrict retrieval of secrets to the actual execution location of the script.