fix(policy): reject unknown endpoint security modes - #3187
Conversation
Closes NVIDIA#3046 Validate TLS, enforcement, and access values across policy and provider profile ingress, and prevent runtime parsing from falling back to audit for unknown enforcement values. Signed-off-by: Krzysztof Malczuk <kmalczuk@redhat.com>
Replace the public TLS, enforcement, and access strings with protobuf enums and carry the typed values through policy composition, provider profiles, drivers, and runtime conversion. Preserve the documented YAML spellings, reject unknown and invalid numeric enum values consistently, and update generated Go bindings, SDK conversions, tests, and policy documentation. Signed-off-by: Krzysztof Malczuk <kmalczuk@redhat.com>
267b665 to
c1c3bdd
Compare
There was a problem hiding this comment.
Great work on this!! @2000krysztof , the centralization in l7_validate.rs is a clean design and the test coverage there is thorough.
One question: I noticed that sandbox policies are persisted as binary protobuf blobs (encode_to_vec / decode in policy_store.rs). Changing NetworkEndpoint.tls, .enforcement, and .access from string (wire type 2) to enum (wire type 0) means that existing stored blobs with non-empty values for those fields will have those fields silently dropped to 0 (Unspecified) when decoded by the new code, since prost skips fields with a wire type mismatch rather than erroring.
The most sensitive case seems to be tls: skip, which would silently become tls: Unspecified (auto-detect) on upgrade. How is this currently handled for existing deployments?
| // Deprecated compatibility spelling; behaves like automatic handling. | ||
| NETWORK_TLS_MODE_TERMINATE = 2 [deprecated = true]; | ||
| // Deprecated compatibility spelling; behaves like automatic handling. | ||
| NETWORK_TLS_MODE_PASSTHROUGH = 3 [deprecated = true]; |
There was a problem hiding this comment.
These two values are marked deprecated, but there's no inline note pointing to the recommended replacement. Is the expectation that callers migrate to the new enum variants directly, or is there a planned alias or migration note somewhere? Just want to make sure it's easy to find for anyone reading the proto in isolation.
| } | ||
| } | ||
|
|
||
| pub fn network_access_preset_from_str(value: &str) -> Option<NetworkAccessPreset> { |
There was a problem hiding this comment.
With the proto fields now typed as enums on the wire, I'm curious whether these string-to-enum conversion functions are still needed for an active code path, for example YAML/Helm config that arrives as strings before being mapped to proto, or whether they're now primarily used for legacy input validation. Just trying to understand if there's an external config surface that still uses the string form.
2 participants
Summary
Make security-sensitive network policy values fail closed across all policy ingress paths. Replace the public TLS, enforcement, and access strings with typed protobuf enums so invalid values cannot silently weaken enforcement.
Related Issue
Closes #3046
Changes
Testing
mise run pre-commitpassesmise run testpassesChecklist