Add plan-time YARA-L verification for chronicle_rule - #22
Closed
b3ngriffiths wants to merge 3 commits into
Closed
Conversation
Add a CustomizeDiff hook to chronicle_rule that calls the existing client.VerifyYARARule against Chronicle's compiler whenever rule_text is changing and its planned value is a known, non-empty string. This makes invalid YARA-L 2.0 fail during "terraform plan" instead of only "terraform apply", while leaving unrelated changes (live_enabled, alerting_enabled) and unknown/computed rule_text values alone. The existing apply-time verification in Create/Update is left in place as a defence-in-depth guard. Add unit tests covering: verification on new/changed rule_text, plan failure with Chronicle's compilation context surfaced, skipping when rule_text is unchanged/unknown, a response that omits "success", API errors during plan, and that Create/Update still verify before mutating Chronicle. Tests use an httptest server wired up via the same WithRuleBasePath mechanism the provider uses for rule_custom_endpoint, so no live Chronicle credentials are required. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_016kLA4K5wvUAdWG2epAVseV
Make the CustomizeDiff handling of unknown planned values explicit:
replace the GetOk-based skip with diff.NewValueKnown("rule_text") and
read the new planned value via diff.GetChange, which is the clearer,
self-documenting SDKv2 API for "only validate this if the new value is
known". Behaviour for concrete strings, and the apply-time verification
in Create/Update, are unchanged.
Add a focused test for the update-from-known-to-unknown path, where
HasChange is true but the new value is unknown -- the case where
NewValueKnown is load-bearing (the existing create-with-unknown test is
short-circuited by HasChange first).
Co-Authored-By: Claude <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016kLA4K5wvUAdWG2epAVseV
3 tasks
…ication CustomizeDiff can be invoked with a nil meta when the provider configuration itself is not yet known at plan time (e.g. credentials interpolated from another resource). The unconditional meta.(*chronicle.Client) type assertion then panicked; skip plan-time verification in that case and fall back to the apply-time check in Create/Update. Add a regression test that panics without the guard. Document the behaviour change in the chronicle_rule docs (template and generated page): plans that create a rule or change rule_text now make an authenticated verifyRule call, so they need Backstory credentials and network access to Chronicle, and unknown rule_text values are verified at apply time instead. Co-Authored-By: Claude <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_016kLA4K5wvUAdWG2epAVseV
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
3 participants
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.
What
Adds a
CustomizeDiffhook tochronicle_ruleso invalid YARA-L 2.0 inrule_textfails duringterraform planinstead of only atterraform apply.Previously
client.VerifyYARARulewas only called in Create/Update, so a broken rule surfaced late (during apply). This wires the same verification into plan.How
resourceRuleCustomizeDiffcalls the existingclient.VerifyYARARule(no duplicated HTTP logic) and only when it's relevant:rule_textis set on a new resource, or changes on an existing one.live_enabled/alerting_enabledchange (no API call).rule_textis empty or unknown/computed at plan time (e.g. interpolated from another resource) — falling back to the apply-time guard, sinceCustomizeDiffcan't reliably validate values that aren't concrete yet.error verifying YARA-L 2.0 rule during plan: <Chronicle context>, surfacing the compiler error in the plan output. Theduring planwording distinguishes it from the apply-time message.The existing Create/Update verification is left in place as a defence-in-depth apply-time guard. Destroy plans are unaffected (the SDK returns before
CustomizeDifffor a null proposed state).Tests
New unit tests in
chronicle/resource_rule_customizediff_test.go— no live Chronicle credentials required. They drive a real*chronicle.Clientagainst anhttptest.ServerviaWithRuleBasePath(the same mechanism the provider uses forrule_custom_endpoint), soVerifyYARARuleexercises real request/response handling:rule_textchangeverifyRulewhen onlylive_enabled/alerting_enabledchange, or whenrule_textis unknownsuccessas invalid, and fails the plan on an API errorRun:
make test— pass (acceptance tests skipped withoutTF_ACC)go test -race ./chronicle/...— pass, no data racesmake lint(gofmt+go vet) — cleanCaveat
terraform plannow makes an authenticatedverifyRuleAPI call to Chronicle wheneverrule_textis set or changed. Plan therefore requires valid Backstory API credentials and network access, and consumes theVerifyYARARulerate limiter.verifyRuleis validation-only — it does not create or evaluate rules.Docs
No schema attributes/descriptions changed, so
docs/resources/rule.mdneeds no update.