fix(userspace/libsinsp): avoid exception failure on unknown k8s node name #833
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 type of PR is this?
/kind bug
Any specific area of the project related to this PR?
/area libsinsp
Does this PR require a change in the driver versions?
What this PR does / why we need it:
When a node name is passed to the k8s client filtering, we throw an exception in case the node name is not found in the reconstructed k8s cluster state. However, this does not distinguish bad node names from unexpected/unpredictable parsing errors during the k8s cluster stare reconstruction. Since an exception can be blocking and cause consumers like Falco to terminate, the best option we have from a security/availability perspective is to log with error level instead of throwing an exception.
Of course, this is a workaround and not a concrete long-term solution. Here, we are giving priority to security and availability of the libs consumer over ease of troubleshooting in case k8s metadata ends up being not available. Since we now have libs logging in Falco (which we didn't have when first introducing this check), I think this is an acceptable tradeoff.
Which issue(s) this PR fixes:
Fixes falcosecurity/falco#2358
Special notes for your reviewer:
Open to discussion for better workarounds.
Does this PR introduce a user-facing change?: