Story: As a Quay administrator I want to be able to enable auditing of unsuccessful login attempts as well as failed pull and push attempts due to incorrect permissions or credentials, so that I can track down potential security-relevant issues or issues with insufficient permissions.

Related discussion found in PROJQUAY-3482.

Acceptance criteria:

• Quay administrators can enable/disable auditing of failed logins, failed pushes, failed pulls  and failed deletions with separate tunable per event type
• Quay administrator, with the config tunable enabled, can get event logs for unsuccessful sign in attempts due to incorrect credentials or disabled user accounts
• Quay administrator, with the config tunable enabled, can get event logs for failed pulls and failed pushes due to incorrect permissions
• In case of unsuccessful user logins the user and its account is logged as performer and target namespace
• In case of unsuccessful robot logins, the user or organization is logged as target namespace if found, the robot name is logged as performer if it is a valid robot (and password mismatches) and the user name is logged as target namespace if its owning the robot and is disabled
• In case of unsuccessful Oauth API token authentication the owning user is logged as performer (if found) and the owning organization is logged as target namespace (if found) and if the token has expired
• In case of unsuccessful app-specific token login the owning user is logged as performer and the target namespace if the user is disabled or the token has expired
• Documentation calling out that enabling this audit tunable can lead to increased audit log traffic which may slow down the database

Note:

• due to the way OCI/docker clients push images (layer blob uploads are attempted first which result in 401 responses for each) work, a failed push due to insufficient privileges will log on audit log event for each layer in the image that was attempted to be pushed