[DuarteMCSilva]

Problem

Since #221, k6 only gets a hard-coded set of environment variables. Customers whose scripts (or k6 extensions) rely on other variables of the extension's environment could only get them back through the step's Environment variables parameter.

Change

• New option STEADYBIT_EXTENSION_K6_ENV_ALLOW_LIST (comma-separated exact names), Helm value k6.envAllowList. The names are added to the built-in defaults, they don't replace them.
• STEADYBIT_EXTENSION_* entries are dropped with a warning at startup, so a misconfigured entry can't hand the extension's own secrets (e.g. STEADYBIT_EXTENSION_CLOUD_API_TOKEN) back to scripts. k6Environment() also never passes STEADYBIT_EXTENSION_* variables, as a second safeguard.
• Exact names only: entries containing * are dropped with a warning. A prefix pattern would also expose variables added under it later.
• README: new "Environment of k6" section (defaults, the new option, the K6_* limitation) and a row in the configuration table. Linux package config gets a commented entry. Chart bumped to 1.2.53.

Breaking change

From #221, not yet released: k6 scripts no longer see the extension's environment variables via __ENV, except K6_*, proxy, TLS, Kubernetes and basic system variables. It's now listed as a breaking change in the CHANGELOG, with the new allow list and the step's environment variables as the way to migrate.

Testing

• Unit tests for the config cleanup (TestParseConfiguration_k6EnvAllowList) and for the allow list in k6Environment() (Test_k6Environment_withAllowList)
• Helm unit test + snapshot for k6.envAllowList
• e2e not run locally: the container build fails because HEAD carries the chart tag steadybit-extension-k6-1.2.52, which goreleaser rejects as not semver (unrelated to this change)

Card: https://steadybitgmbh.kanbanize.com/ctrl_board/2/cards/26574/details/

[claude]

Claude finished @DuarteMCSilva's task in 13s —— View job

---

Review of PR #222

• Checked for earlier unresolved Claude review threads. There were none, so nothing to resolve.
• Reviewed the changes in config, extk6, the Helm chart and the Linux package config.

No blocking issues found.

• ValidateConfiguration() is called from main.go:40, so the allow-list cleanup runs at startup.
• STEADYBIT_EXTENSION_* entries are blocked in two places, in the config cleanup (case-insensitive) and in k6Environment(). The second check holds even if the config were set directly.
• The cloud token still reaches k6 as K6_CLOUD_TOKEN, which is appended explicitly in common.go:197. The new filter doesn't affect that.
• The Helm with / join "," | quote handles an empty list correctly. The variable is omitted when the list is empty.

Minor note, no action needed: the check in k6Environment() is case-sensitive, while the config cleanup is case-insensitive. This is fine on Linux, where variable names are case-sensitive, and the config cleanup already drops lowercase variants.

I didn't run the tests or the e2e suite.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
100.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud