Repository navigation
fix: preserve sensitive bootstrap boundaries in v2 provider selection - #5588
Merged
Merged
Conversation
Contributor
Dependency Review✅ No vulnerabilities or license issues or OpenSSF Scorecard issues found.Scanned FilesNone |
Contributor
There was a problem hiding this comment.
🟢 Approval recommended
No active review issues were identified for the sensitive-bootstrap configuration changes.
No open issues 🎉
What changed in this PR
This PR fixes v2 runner configuration planning when EC2 bootstrap content is sensitive, while preserving sensitivity on userdata and keeping public IAM policy keys usable.
Changes:
- Declassifies only the provider-presence boolean used for selection.
- Accesses the selected provider contract directly to avoid spreading userdata sensitivity to sibling policies.
- Adds mocked plan regressions for sensitive full userdata, pre-install scripts, and post-install scripts, with userdata sensitivity assertions.
| File | Description |
|---|---|
modules/runner-config/tests/sensitive-bootstrap.tftest.hcl |
Adds three sensitive-bootstrap planning regressions. |
modules/runner-config/tests/fixtures/sensitive-bootstrap/README.md |
Documents the test fixture’s module, input, and outputs. |
modules/runner-config/tests/fixtures/sensitive-bootstrap/main.tf |
Defines the runner fixture and exposes sensitivity and provider-type checks. |
modules/runner-config/compute-provider.tf |
Limits sensitivity propagation during provider selection and contract access. |
Review effort: Balanced
Brend-Smits
previously approved these changes
Nov 10, 2026
Brend-Smits
approved these changes
Nov 10, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Sensitive EC2 bootstrap content can prevent a v2 runner configuration from planning. We hit
Invalid for_each argumentfor bothaws_iam_role_policy.runner_providerandaws_iam_role_policy_attachment.runnerwhen a bootstrap script contained a sensitive value. The IAM policy keys themselves were public.Two expressions spread that sensitivity beyond the bootstrap value:
one(module.compute_aws_ec2[*].provider)promotes nested userdata sensitivity to the whole provider contract, including sibling policy maps.Declassify only the boolean indicating whether the provider is configured, and access the selected module's contract directly using the plan-known provider key. Bootstrap contents and resource attributes retain their sensitivity; no policy documents or configuration objects are passed through
nonsensitive().Added mocked parent-module plans covering sensitive full userdata, pre-install scripts, and post-install scripts, with an assertion that launch-template userdata remains sensitive. The regression reproduces both IAM errors on unmodified main. With the fix, all 20 runner-config tests and 21 multi-runner tests pass, including the existing computed-IAM-input cases.