Document the limitations of Audit Logging for policy rules

[antoninbas]

Starting with Antrea v1.13, logging is best-effort, which means that logging cannot typically be used for compliance purposes.

For older Antrea versions, traffic for which logging was enabled would be dropped after a certain rate was reached, creating issues for production workloads.

[qiyueyao]

lgtm, just three minor questions.

[qiyueyao]

Would it be more helpful to add a link to ACNP with log settings example here for comparison? And maybe change that previous example to a more suitable example to log (Drop), as opposed to this example?

[antoninbas]

Sorry I am having a hard time understanding what you are suggesting. What difference are we trying to highlight by comparing with the acnp-with-log-setting example? And which example would you want to update to use the Drop action (and why)?

[qiyueyao]

I assumed that acnp-with-log-setting example does not suffer much from disrupting application workloads, rather than this allow-dns example, so I was referring to this difference.

I was wondering if we need to change acnp-with-log-setting to Drop as mentioned below especially when the policy rule uses the Allow action. (Quick question is it no longer the case that only the first packet of an Allow connection will be logged?)

[antoninbas]

I assumed that acnp-with-log-setting example does not suffer much from disrupting application workloads, rather than this allow-dns example, so I was referring to this difference.

This policy applies to traffic from the application frontend to the DB layer. If it is a large scale application with a high number of connections, it could suffer from the same issue. In practice, for this specific case, the number of connections between the frontend and the DB is likely to stay "small", as the application is likely to use a connection pool instead of creating a new connection for each user session. But that really depends on the type of application.

The difference between these policies is more about the workloads to which they apply. I don't think there is a difference in how they are implemented. So they can both suffer from this issue in the same way.

In practice, users are more likely to experience this issue with CoreDNS because: 1) it seems common to enable logging for DNS requests, 2) even medium clusters usually have a large volume of DNS requests.

So I may still be missing your point.

I was wondering if we need to change acnp-with-log-setting to Drop as mentioned below especially when the policy rule uses the Allow action. (Quick question is it no longer the case that only the first packet of an Allow connection will be logged?)

With recent versions of Antrea (since v1.13), logging is fine with the Allow action, so why should we change the example? especially when the policy rule uses the Allow action is because the side effect of enabling logging with older Antrea versions is that flows are dropped after a certain rate limit. If the action is Allow, this is clearly a bigger deal than if the action is Drop anyway.

We only log the first packet of an Allow connection. That has not changed.

[qiyueyao]

Thanks for the detailed explanations! Now I understand, no need for difference, and If the action is Allow, this is clearly a bigger deal than if the action is Drop anyway. makes total sense.

[qiyueyao]

Just a personal feeling, do we usually include this backport detail in a readme?

[antoninbas]

I think it is helpful as users are more likely to find this information here, rather than look at the changelogs. I would be comfortable removing it after a few releases, but some users are running Antrea minor versions for a while, even after we stop maintaining them here.

[qiyueyao]

Understood, thanks!

[tnqn]

LGTM, Qiyue's comments also make sense to me.

[qiyueyao]

🎉

[antoninbas]

/skip-all