fix(wiz): identify EKS clusters by ARN instead of Wiz-internal hash#36
Open
fix(wiz): identify EKS clusters by ARN instead of Wiz-internal hash#36
Conversation
81d34df to
db0b544
Compare
…urce_id, version, engine
The Wiz inventory parser hard-coded the CSV column names for resource_id
(externalId), name, account_id, region, and tags. This made the YAML
field_mappings entries for those keys decorative — they happened to
match the hard-coded constants, but changing them had no effect.
For EKS specifically, this was actively wrong: Wiz's 'externalId' column
is an internal hash, while the cluster ARN lives in 'providerUniqueId'.
Fixing only resource_id while leaving the rest hard-coded would have
left a confusing half-configurable interface.
This commit makes field_mappings the single source of truth for every
CSV column the parser reads:
- generic.go: introduces a generic column(key, defaultCol) helper used
for resource_id, name, account_id, region, version, engine, and tags.
Each lookup falls back to the canonical Wiz column when not mapped.
nativeType (used to filter rows) and graphEntity.properties (used by
Lambda) remain hard-coded because they are infrastructure, not
resource fields.
- pkg/config/loader.go: adds validateFieldMappings, which enforces that
resource_id, version, and engine are present in field_mappings.
Three resource types are exempt where the underlying CSV does not
expose a single column for the field:
- lambda: version (runtime) is extracted from graphEntity.properties
JSON; engine is implicitly 'aws-lambda'.
- eks: engine is implicitly 'eks' (no engine column).
- opensearch: engine is derived from version.
- config/resources.yaml: every resource now declares its full set of
field_mappings in a consistent order, with explicit comments where
a field is implicit (eks engine, opensearch engine, lambda
version+engine). EKS sets resource_id: 'providerUniqueId' so
Resource.ID is the cluster ARN instead of a Wiz-internal hash.
- Tests:
- TestParseResourceRow_AllMappingsAreConfigurable: proves the
parser honors every field_mapping by using non-canonical Wiz
column names everywhere.
- TestParseResourceRow_ConfigurableResourceIDColumn: covers the
EKS providerUniqueId case.
- TestGetRequiredColumns_ConfigurableResourceIDColumn: verifies
required-columns derivation reflects the override.
- TestValidateConfig_FieldMappings: covers the new validator,
including the lambda/eks/opensearch exemptions.
- Docs: ARCHITECTURE.md, the add-version-guard-resource skill, and
the example YAMLs are updated to document the new required/optional
keys, the per-type exemptions, and the EKS providerUniqueId guidance.
Amp-Thread-ID: https://ampcode.com/threads/T-019dd0ae-f269-7191-ae5f-019a787fcaa8
Co-authored-by: Amp <amp@ampcode.com>
CI's golangci-lint-action runs with only-new-issues: true, but the pre-push hook ran the linter over the entire codebase, surfacing many pre-existing issues unrelated to the push being made. This made the hook block contributors on issues that CI itself would not flag. Switch the hook to --new-from-rev=origin/main so it lints only changes relative to the integration branch, matching CI behavior. Falls back to local 'main' when origin/main is not available. Amp-Thread-ID: https://ampcode.com/threads/T-019dd0ae-f269-7191-ae5f-019a787fcaa8 Co-authored-by: Amp <amp@ampcode.com>
db0b544 to
06b2382
Compare
17801b8 to
06b2382
Compare
The 'Examples' block at the end re-pasted aurora-postgresql, eks, and elasticache-redis as comments — but those resources are already defined live above. Standalone copy-paste templates already live in skills/add-version-guard-resource/examples/, and the README/USAGE docs cover the WIZ_REPORT_IDS env var. Replace ~70 lines of duplication with a single pointer to the skill. Amp-Thread-ID: https://ampcode.com/threads/T-019dd117-2fc4-71e6-8fd1-72b471f07e15 Co-authored-by: Amp <amp@ampcode.com>
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
1 participant
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.
Problem
EKS clusters in our snapshots are keyed by Wiz's
externalIdcolumn, whichfor EKS is a Wiz-internal hash (e.g.
a8f3...e1b2) — not the cluster ARN.Anything joining on
Resource.ID(snapshot JSON, S3 keys, dashboards) getsopaque values that don't match what AWS or operators see.
The cluster ARN lives in Wiz's
providerUniqueIdcolumn. To use it we needthe parser's CSV column choice to be configurable per resource — today it's
hard-coded.
Fix
Make every CSV column the parser reads driven by
field_mappings, thenpoint EKS at
providerUniqueId. Other resource types keep their existingbehavior because YAML defaults match the previously hard-coded columns.
pkg/inventory/wiz/generic.go— single helper resolves any field viafield_mappingswith a Wiz-canonical default.pkg/config/loader.go— fail fast at load time ifresource_id,version,engineare missing (withlambda/eks/opensearchexemptions where the field is implicit).
config/resources.yaml— EKS setsresource_id: "providerUniqueId";every resource declares its full mapping.
only-new-issues: truebehavior so itdoesn't block contributors on pre-existing lint debt.
Behavior change
EKS findings going forward use ARNs (
arn:aws:eks:…:cluster/…). All otherresource types unchanged.
Verified end-to-end against live Wiz data via docker-compose: 155/155 EKS
findings now have ARN-prefixed resource IDs.
Verification
go vet,gofmt,goimports,go test ./..., andgolangci-lint run --new-from-rev=mainall clean.