How do I enable audit logging in Redpanda and export logs to our SIEM?

Most teams hit the same wall the moment Redpanda becomes mission‑critical: security and compliance want a complete, trustworthy audit trail, and your platform team wants those logs in a central SIEM without bolting on a new Rube Goldberg machine. The good news is Redpanda is built for this reality: you can enable audit logging, stream those events out like any other Kafka‑compatible data, and feed your SIEM while keeping operations simple.

Quick Answer: Turn on Redpanda audit logging at the cluster level, secure it with RBAC/OIDC/Kerberos, write the audit events into dedicated topics, and then use a connector, consumer, or log forwarder to ship those topics into your SIEM with TLS and fine‑grained ACLs. The result: a continuous, immutable record of who did what, when, and from where—centrally searchable in your SIEM.

The Quick Overview

What It Is: Redpanda’s audit logging is an enterprise‑grade feature that records security‑relevant actions—authentication, authorization, configuration changes, access to topics—into an append‑only stream you can retain, query, and export.
Who It Is For: Platform, security, and data engineering teams that need Kafka‑compatible streaming with compliance‑ready observability: RBAC, OIDC/Kerberos, TLS, ACLs, and audit trails routed into a SIEM.
Core Problem Solved: Proving and enforcing control. You need to show exactly how Redpanda is used, catch misconfigurations and suspicious access early, and replay what happened when something goes wrong—without drowning in bespoke logging glue.

How It Works

At a high level, enabling audit logging in Redpanda is a three‑step path:

Turn on secure, governed access.
You configure identity (OIDC or Kerberos), encryption (TLS), and authorization (ACLs / RBAC). That gives you enforceable identities and actions to audit.
Enable and configure audit logging.
You switch on audit logging in your Redpanda configuration, choose what to log, and route audit events to one or more internal topics. Those topics behave like any other Redpanda stream: replicated, durable, and queryable.
Export audit streams to your SIEM.
You hook your SIEM into those topics via a Kafka‑compatible connector, a lightweight consumer, or a log shipping agent. From there you can index, correlate, alert, and retain according to your security policies.

Under the hood, Redpanda keeps the operational footprint tight: one binary, zero external dependencies, Kafka API compatibility, built‑in observability via Prometheus, and enterprise controls like RBAC, SSO, FIPS‑compliant binaries, and audit logging. You get an immutable security trail without building a separate log pipeline.

Step‑by‑Step: Enabling Audit Logging in Redpanda

1. Lock in identity and access controls

Audit logs are only as good as the identities behind them. Start with secure access:

Enable TLS encryption to protect data in transit between clients, brokers, and the console.
Configure OIDC or Kerberos authentication so every action is tied to a real user, service, or agent:
- OIDC for SSO with your identity provider.
- Kerberos for deeply integrated on‑prem environments.
Use fine‑grained ACLs and RBAC:
- ACLs to control which principals can read/write specific topics, create consumer groups, and manage metadata.
- RBAC to govern access to management surfaces like Redpanda Console and admin APIs.
Enable SSO for Redpanda Console so UI actions (e.g., creating topics, changing configs) are authenticated and auditable.

This gives your audit logging something meaningful to capture: who (OIDC/Kerberos identity), did what (ACL/RBAC‑guarded action), against which resource, from where, and when.

2. Enable audit logging at the cluster layer

Next, you configure Redpanda to emit audit logs. The exact config options will depend on your Redpanda version, but the pattern looks like this:

Choose your audit scope: Typical audit domains include:
- Authentication events (logins, failures)
- Authorization decisions (ACL/RBAC allow/deny)
- Topic and schema changes (create, delete, config updates)
- Consumer group changes (creation, offset resets)
- Administrative operations (cluster settings, user management)
Route events to internal topics: Configure Redpanda so that audit events land in one or more dedicated topics, for example:
- rp.audit.auth
- rp.audit.admin
- rp.audit.access
These topics:
- Live in your Redpanda cluster.
- Are replicated and durable like any other topic.
- Can be protected with strict ACLs so only your security tooling can read them.
Set retention and storage strategy: Decide how long you keep audit data in Redpanda versus your SIEM:
- Use retention policies (time‑based or size‑based) on audit topics.
- Optionally pair with remote read replicas or tiered storage to keep long‑term history off operational clusters.
Restart / reload configuration: Apply the changes and restart or reload Redpanda services as required so audit logging takes effect.

Now every relevant action on the cluster is captured in a structured, append‑only stream.

3. Harden and observe the audit pipeline

Before you export anything, make sure the audit pipeline itself is secure and observable:

Restrict access to audit topics with ACLs:
- Only your SIEM connector/service account should have read permissions.
- Write permissions should be limited to brokers themselves.
Monitor cluster health via Prometheus:
- Watch broker CPU, disk, and network.
- Track audit topic lag for your SIEM consumers to detect backpressure.
Use a FIPS‑compliant binary if you operate in regulated environments that require validated cryptography.

This keeps your audit trail trustworthy and your cluster stable as you ramp up SIEM ingestion.

Exporting Redpanda Audit Logs to Your SIEM

Once audit events are flowing into topics, exporting is just streaming 101: Redpanda is Kafka‑compatible, so you use the same patterns you’d use for any Kafka‑to‑SIEM integration.

Common patterns

Kafka / Redpanda connector into SIEM

Many SIEMs expose a native or marketplace connector that can read from Kafka APIs:
- Configure the connector with:
  - Bootstrap servers: your Redpanda brokers or load‑balanced endpoint.
  - Security: TLS, and SASL if using OIDC/Kerberos.
  - Topics: the audit topics you created (rp.audit.*).
- Map audit fields to your SIEM’s schema (e.g., user, resource, operation, IP, timestamp, cluster).
This is ideal if your SIEM is Kafka‑aware and you want a managed integration.
Custom consumer service that forwards to SIEM

If your SIEM expects HTTP, syslog, or a custom ingestion API:
- Build a small consumer service in your language of choice (Java, Go, Python, Rust) using a Kafka client.
- Consume from the audit topics and transform events into the SIEM’s expected format.
- Push events to:
  - HTTP ingestion endpoints,
  - Syslog/CEF/LEEF collector,
  - Or an agent like Fluent Bit/Fluentd/Vector.
This gives you full control over redaction, enrichment, and batching.
Log‑shipping via an agent

Some teams prefer generic log shippers:
- Use a connector or consumer to write audit events to local log files or a dedicated topic that an agent can read.
- Deploy agents (Fluent Bit, Filebeat, etc.) to watch those logs or topics and forward into the SIEM.
This leverages existing log‑forwarding infrastructure while still treating Redpanda as the source of truth.

Best practices for SIEM integration

Separate audit workloads from operational traffic:
- Consider remote read replicas to serve SIEM reads without touching the hot path of your streaming applications.
Normalize and enrich events early:
- Add cluster ID, environment (prod/stage), and region before events hit the SIEM.
Protect PII and secrets:
- Ensure sensitive payload fields are filtered or redacted before leaving Redpanda, especially if agents or apps write sensitive data.
Alert on the right patterns:
- Unusual login patterns.
- Repeated ACL/RBAC denies.
- Sudden changes in topic configurations or retention.
- Large offset resets in critical consumer groups.

Your SIEM becomes the command center, while Redpanda remains the immutable source—every agent, app, and admin leaves a trace.

Features & Benefits Breakdown

Core Feature	What It Does	Primary Benefit
Audit Logging	Records security‑relevant actions across the Redpanda cluster	Complete, replayable history for compliance and forensics
RBAC, ACLs, OIDC, Kerberos	Governs who can access what, and how they authenticate	Enforce least privilege and tie logs to real identities
TLS & FIPS‑Compliant Binary	Secures data in transit and meets strict crypto/compliance requirements	Safe to expose to regulated workloads and external audits
Prometheus Observability	Exposes metrics for brokers, topics, and consumers	Detect ingestion/backpressure issues before they cause gaps
Remote Read Replicas	Serves reads from secondary clusters to protect operational workloads	Offload SIEM queries without impacting real‑time pipelines

Ideal Use Cases

Best for regulated workloads (finance, healthcare, public sector):
Because it gives you an immutable, centrally searchable trail of all Redpanda activity while supporting FIPS, RBAC, OIDC/Kerberos, and SIEM export.
Best for security‑sensitive AI / agent workloads:
Because agents don’t just read—they act and change data. Redpanda lets you govern access before actions occur and keep a permanent, exportable record of every interaction.

Limitations & Considerations

Storage and retention overhead:
Audit logs can grow fast. Use retention policies, tiered storage, or read replicas, and lean on your SIEM for long‑term archive.
Parsing and schema management:
SIEM value depends on structured fields. Plan a schema for audit events and configure your connector/consumer to normalize and enrich data consistently.

Pricing & Plans

Audit logging sits alongside other enterprise capabilities in Redpanda’s commercial offerings, which build on the free Community Edition.

Typical model:

Community / Starter:
Best for developers and teams needing Kafka‑compatible streaming to prototype and test, with basic security and observability. Ideal to test logging patterns before enabling full audit trails.
Enterprise / Managed (including BYOC):
Best for organizations that need enterprise security (RBAC, OIDC/Kerberos, SSO, FIPS‑compliant binaries, audit logging), 24x7 support with SLAs, remote read replicas, and deployment flexibility (your VPC, multicloud, air‑gapped).

For exact pricing, deployment options (self‑managed, BYOC, fully managed), and what’s included with audit logging, check the Redpanda pricing page.

Frequently Asked Questions

Do I need a separate logging cluster just for audit logs?

Short Answer: Not necessarily, but isolating reads with remote replicas is a strong pattern for large SIEM workloads.

Details:
Redpanda can store audit logs in the same cluster as your application topics. For smaller to mid‑sized environments, that’s often enough—especially with well‑tuned retention. As audit volume and SIEM queries grow, many teams:

Keep audit topics in the primary cluster.
Use remote read replicas or a dedicated analytics cluster to serve SIEM reads.
Apply stricter ACLs so only SIEM pipelines can access those topics.

This protects your operational SLOs while your SIEM runs heavy correlation and searches.

Can I filter or redact fields before audit data reaches the SIEM?

Short Answer: Yes. Use your connector or consumer layer to filter, redact, or aggregate events.

Details:
Redpanda emits audit events as structured records. When you export them:

A Kafka‑compatible connector often exposes transforms to drop fields, mask sensitive values, or remap fields.
A custom consumer service gives you full control: you can:
- Drop non‑critical events (e.g., health checks).
- Mask usernames, IPs, or topic names according to policy.
- Aggregate high‑volume events into summaries before forwarding.

This lets you meet privacy requirements and control SIEM ingest volume without losing the underlying, full‑fidelity history in Redpanda.

Summary

Enabling audit logging in Redpanda and exporting those logs to your SIEM is about more than ticking a compliance box. It’s how you prove you can see, control, and trust what’s happening on the backbone of your streaming and agentic workloads.

You:

Authenticate with OIDC or Kerberos.
Authorize with RBAC and ACLs.
Encrypt with TLS and FIPS‑compliant binaries.
Log every meaningful action into durable Redpanda topics.
Export those streams into your SIEM using Kafka‑compatible connectors, consumers, or agents.
Replay and investigate when something goes wrong—without guessing.

You’re not bolting on a sidecar logger. You’re turning your streaming platform into an auditable, governed data plane that security teams can rely on.

Next Step

Get Started