Rbac: Disambiguate between rbac 403 and application 403

[mandarjog]

When Rbac filter denies a request, it does not set a reponse flag.
From access logs, it is not possible to disambiguate a 403 emitted by the filter vs 403 emitted by the application.

1. Set response flag(s) to indicate
   a. denied by policy
   b. Potentially indicate that the response was generated within the proxy. This can be more generic than just rbac.
2. Indicate which rule or condition matched.

@yangminzhu @kyessenov

[mattklein123]

+1 for adding response flags and reasons if they are not already set. cc @alyssawilk

[alyssawilk]

FWIW it is accessible via response code details (https://www.envoyproxy.io/docs/envoy/latest/faq/debugging/why_is_envoy_sending_internal_responses) but adding a flag is fine as well.

[yangminzhu]

1. Set response flag(s) to indicate
   a. denied by policy

@mattklein123

This should be straightforward to add, I can add the flag. Not very clear what do you mean for reasons here, like @alyssawilk mentioned, currently it is in the response_code_details, and the HTTP response body will also have RBAC: access denied.

b. Potentially indicate that the response was generated within the proxy. This can be more generic than just rbac.

@mandarjog

For HTTP, the response body is RBAC: access denied, how do you want to improve this? For TCP I'm not sure what we can do there.

2. Indicate which rule or condition matched.

A recent PR merged to print the effective policy name in debug logging. Not sure where else you want to see it? One idea I thought before is to add it to the HTTP response body but that may need some thinking (or flag/API to control it) as user may don't always want to expose it.

[mandarjog]

@yangminzhu response body is not logged and it is not part of any telemetry, So response_flag should indicate denial

For response reason, I think we can use what @alyssawilk suggested. Do you think it is the appropriate place to put rule_id (if using deny rule) that caused the denial?

[yangminzhu]

@yangminzhu response body is not logged and it is not part of any telemetry, So response_flag should indicate denial

oh, ok, I thought you're referring to the end user experience.

For response reason, I think we can use what @alyssawilk suggested. Do you think it is the appropriate place to put rule_id (if using deny rule) that caused the denial?

I think it makes sense to set the response code detail to the policy_id. See #12912