Expose policy attribution in Network Policy Agent ALLOW/DENY flow logs so that each observed flow can be associated with the Kubernetes NetworkPolicy resource or resources that contributed to the decision.
At minimum, it would be useful for the flow event to include:
- Policy name
- Policy namespace
- Traffic direction
- Relevant policy or policies associated with the ALLOW/DENY verdict
The exact format is flexible.
This is a follow-up to #642, where we confirmed that policy attribution is not currently available in NPA and were asked to open a separate enhancement request for this capability.
Why is this needed:
We consume NPA policy-event flow logs for network-security visibility. The existing flow logs provide the traffic details and ALLOW/DENY verdict, but they do not indicate which policy resulted in that decision.
Policy attribution would allow us to clearly explain why a particular flow was permitted or blocked.
This is particularly useful for:
- Security reviews
- Troubleshooting NetworkPolicy behavior
- Auditing
- Compliance
- Policy analysis and visibility
For example, when a flow is allowed, we would like to identify which policy allowed it. For a denied flow, we would like to identify the relevant policy or isolation context that resulted in the traffic being blocked.
@jaydeokar @cdirubbio @viveksb007 — tagging for context from #642. Thanks again for the guidance there.
Expose policy attribution in Network Policy Agent ALLOW/DENY flow logs so that each observed flow can be associated with the Kubernetes
NetworkPolicyresource or resources that contributed to the decision.At minimum, it would be useful for the flow event to include:
The exact format is flexible.
This is a follow-up to #642, where we confirmed that policy attribution is not currently available in NPA and were asked to open a separate enhancement request for this capability.
Why is this needed:
We consume NPA policy-event flow logs for network-security visibility. The existing flow logs provide the traffic details and ALLOW/DENY verdict, but they do not indicate which policy resulted in that decision.
Policy attribution would allow us to clearly explain why a particular flow was permitted or blocked.
This is particularly useful for:
For example, when a flow is allowed, we would like to identify which policy allowed it. For a denied flow, we would like to identify the relevant policy or isolation context that resulted in the traffic being blocked.
@jaydeokar @cdirubbio @viveksb007 — tagging for context from #642. Thanks again for the guidance there.