1. Proposed title of this feature request

Add native syslog/rsyslog (RFC5424/TCP-TLS/RELP) output for Red Hat Quay Action/Usage logs, with first-class QRadar/SIEM integration

2. What is the nature and description of the request?

Problem:

Today, Red Hat Quay Action/Usage logs is stored in the Quay database or exported to Elasticsearch or Splunk. There is no supported way for Quay to stream these audit-relevant events directly to syslog/rsyslog endpoints (e.g., QRadar), which many enterprises standardize on for security operations and compliance. 

Request:

Implement a native Action/Usage log sink for syslog that supports:

• Transports: TCP, TLS (recommended), and RELP for reliability.

• Protocols/format: RFC 5424 headers with selectable facility/severity; message payload as JSON preserving Quay fields (e.g., datetime, kind, actor, repository, ip, metadata).

• Configuration surfaces:

• • New LOGS_MODEL: syslog (and LOGS_MODEL_CONFIG.syslog_* parameters) alongside existing database|elasticsearch|splunk.

• • Support via the Quay Operator (OCP) and config.yaml (standalone).

• Security: mTLS/CA trust, certificate rotation, hostname pinning, and FIPS-compliant ciphers.

• Reliability & flow control: buffering/queueing, backoff/retry, batch size and rate controls, and at-least-once delivery (RELP option).

• Multi-destination: allow parallel sinks (e.g., syslog + ES/Splunk) to avoid architectural lock-in.

• Observability: health metrics (success/failure counts), circuit-breaker state, and per-sink status surfaces in Quay metrics/UI.

Out-of-scope alternatives considered:
OpenShift Logging can forward container stdout/stderr to syslog/QRadar, but that does not include the Quay Action/Usage log unless additional integration bridges are built. A native sink removes that gap and avoids custom maintenance.

Documentation note:
Current docs state "For deployments with a large amount of logged operations, you can store the usage logs in Elasticsearch and Splunk instead of the Red Hat Quay database backend."; please extend the docs to include syslog as a supported destination when implemented.

3. Why does the customer need this? (List the business requirements here)

• Security & Compliance (Telco/Critical Infra): Central SOC/SIEMs (e.g., QRadar) commonly ingest syslog/TLS. Direct streaming of Quay audit/usage events enables real-time detection, forensics, and regulatory reporting without intermediary data stores.

• Operational Simplicity: Eliminates brittle bridges (Quay → ES/Splunk → Syslog) or custom poll/export scripts. Reduces MTTR and day-2 ops overhead.

• Standardization: Many enterprises mandate syslog as the canonical transport into SIEM, with established tooling, retention, and access controls.

• Reliability & Determinism: A supported RELP/TCP-TLS sink is preferable to ad-hoc, best-effort forwarding.

• Air-gapped/Restricted networks: Direct syslog over TLS aligns with existing allow-lists and avoids deploying/operating additional stacks (ES/Splunk) solely to reach SIEM.

• Cost Control: Avoids standing up and operating Elasticsearch or Splunk infrastructure where it is not otherwise needed.

4. List any affected packages or components.

• Quay application (core):

• • Logging pipeline that emits Action/Usage events.

• • Configuration model: LOGS_MODEL and LOGS_MODEL_CONFIG to add syslog option and fields (server, port, protocol, TLS/RELP settings, facility, template).

• Quay Operator (OCP):

• • CRD/ConfigBundle validation to surface syslog settings and secrets (CA/client certs).

• • Status/conditions to report sink health.

• Quay Configuration & Docs:

• • Configure Red Hat Quay and Manage Red Hat Quay guides: add syslog as a supported Action Log destination alongside Elasticsearch and Splunk; include examples and security guidance. 

• Telemetry/Metrics:

• • Expose exporter counters/gauges (sent, failed, queued, dropped) via Prometheus endpoints used by OCP/Quay.

• (Optional) UI:

• • Admin page to test connectivity, view sink status, and show recent delivery errors.