DOC-1485: Fix doc reference to configurable audit log retention #1338
Conversation
✅ Deploy Preview for redpanda-docs-preview ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
|
Important Review skippedAuto incremental reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the You can disable this status message by setting the 📝 WalkthroughWalkthroughDocumentation updates in modules/manage/partials/audit-logging.adoc revise the “Configure retention for audit logs” section. The changes add guidance to export audit events to a SIEM instead of relying on in-cluster persistence, introduce a multi-step operational workflow to adjust retention (temporarily removing the _redpanda.audit_log topic from no_delete, updating retention.ms, and re-adding it), and insert a note recommending at least one year of audit log retention. Wording and instruction order are updated accordingly. No code or API signatures were modified. Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes Assessment against linked issues
Assessment against linked issues: Out-of-scope changes
Suggested reviewers
✨ Finishing Touches🧪 Generate unit tests
🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. CodeRabbit Commands (Invoked using PR/Issue comments)Type Other keywords and placeholders
CodeRabbit Configuration File (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
♻️ Duplicate comments (1)
modules/manage/partials/audit-logging.adoc (1)
402-403: Awkward and contradictory phrasing around “do not need to keep… seven days … and you must revise.”Even if this remained, the sentence mixes “do not need to keep” (reduce) with “must revise” (change either way). If retained in non‑cloud docs, tighten to “If you require a retention period different from the default seven days…”. For Cloud, this should instead state non‑configurability (see prior comment).
🧹 Nitpick comments (2)
modules/manage/partials/audit-logging.adoc (2)
404-404: One‑year retention recommendation needs scope and source; consider softening and scoping to exported logs.As written, it can be read as a product guarantee or Cloud capability. Suggest clarifying it applies to exported logs and is a general best practice, not a hard requirement provided by Cloud in‑cluster retention.
Proposed wording (if keeping this note after the previous diff):
- “Redpanda recommends retaining exported audit events for at least one year; consult your compliance team for requirements.”
Please confirm with Product/Compliance whether “one year” is the official guidance for public docs.
400-401: Add a cross‑reference to export guidance.Since the recommended path is to export to a SIEM/external store, add an xref to the page(s) that show how to forward audit events (for example, Splunk/SIEM integrations or generic sink guidance).
If you share the correct target page(s), I’ll add the xref(s) and a short example.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
💡 Knowledge Base configuration:
- MCP integration is disabled by default for public repositories
- Jira integration is disabled by default for public repositories
- Linear integration is disabled by default for public repositories
You can enable these sources in your CodeRabbit configuration.
📒 Files selected for processing (1)
modules/manage/partials/audit-logging.adoc(1 hunks)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (3)
- GitHub Check: Redirect rules - redpanda-docs-preview
- GitHub Check: Header rules - redpanda-docs-preview
- GitHub Check: Pages changed - redpanda-docs-preview
| Ideally, you export audit events to your own SIEM for persistence supporting your audit and compliance needs rather than relying on in-cluster persistence. | ||
|
|
||
| As you assess the retention needs for your audit logs, if you find that you do not need to keep them for the default seven days, and you must revise the retention period: | ||
|
|
||
| NOTE: Redpanda Data recommends that you retain audit logs for at least one year. | ||
|
|
||
| . Remove `_redpanda.audit_log` topic from the `no_delete` topics list in your cluster configuration. | ||
| . Update the `retention.ms` property for the `_redpanda.audit_log` topic. | ||
| . Add the `_redpanda.audit_log` topic back to the `delete` topics list. |
There was a problem hiding this comment.
🛠️ Refactor suggestion
Cloud docs currently instruct customers to change audit retention; this contradicts the PR objective (Cloud retention not end‑user configurable).
In env-cloud, steps to remove from no_delete, change retention.ms, and re-add to a delete list imply customers can mutate the internal _redpanda.audit_log topic. Per the PR objective, Cloud users cannot configure audit-log retention; they should export to a SIEM and manage retention there, or contact Support for changes. Recommend replacing the entire block with explicit non-configurability language and Support guidance, and removing the operational steps (or moving them under self-managed sections only).
Apply this diff to align the Cloud documentation with the stated objective:
- Ideally, you export audit events to your own SIEM for persistence supporting your audit and compliance needs rather than relying on in-cluster persistence.
-
- As you assess the retention needs for your audit logs, if you find that you do not need to keep them for the default seven days, and you must revise the retention period:
-
- NOTE: Redpanda Data recommends that you retain audit logs for at least one year.
-
-. Remove `_redpanda.audit_log` topic from the `no_delete` topics list in your cluster configuration.
-. Update the `retention.ms` property for the `_redpanda.audit_log` topic.
-. Add the `_redpanda.audit_log` topic back to the `delete` topics list.
+ In Redpanda Cloud, retention for the internal `_redpanda.audit_log` topic is managed by Redpanda and is not configurable by cluster users.
+
+ To meet audit/compliance retention requirements, export audit events to your own SIEM or external storage and manage retention there. If you have a business need to adjust the default seven‑day in‑cluster retention, contact Redpanda Support.
+
+ NOTE: Redpanda recommends retaining exported audit events for at least one year; work with your compliance team to set an appropriate policy.Would you like me to propose a matching move of the procedural steps into the self‑managed (non‑cloud) section, with concrete rpk/Admin API examples?
📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| Ideally, you export audit events to your own SIEM for persistence supporting your audit and compliance needs rather than relying on in-cluster persistence. | |
| As you assess the retention needs for your audit logs, if you find that you do not need to keep them for the default seven days, and you must revise the retention period: | |
| NOTE: Redpanda Data recommends that you retain audit logs for at least one year. | |
| . Remove `_redpanda.audit_log` topic from the `no_delete` topics list in your cluster configuration. | |
| . Update the `retention.ms` property for the `_redpanda.audit_log` topic. | |
| . Add the `_redpanda.audit_log` topic back to the `delete` topics list. | |
| In Redpanda Cloud, retention for the internal `_redpanda.audit_log` topic is managed by Redpanda and is not configurable by cluster users. | |
| To meet audit/compliance retention requirements, export audit events to your own SIEM or external storage and manage retention there. If you have a business need to adjust the default seven-day in-cluster retention, contact Redpanda Support. | |
| NOTE: Redpanda recommends retaining exported audit events for at least one year; work with your compliance team to set an appropriate policy. |
🤖 Prompt for AI Agents
modules/manage/partials/audit-logging.adoc lines 400-408: The current cloud docs
instruct users to modify `_redpanda.audit_log` retention (remove from no_delete,
set retention.ms, re-add to delete), which contradicts cloud policy that
audit-log retention is not user-configurable; replace this block with a short
paragraph stating that in Cloud audit-log retention cannot be changed by end
users, recommend exporting audit events to a SIEM for retention management or
contacting Support to request changes, and move the procedural steps
(remove/update/re-add) into the self-managed/non-cloud section only with a note
linking to that section.
There was a problem hiding this comment.
@michael-redpanda
Please let me know if CodeRabbit is right here. Can Cloud users do this or not?
There was a problem hiding this comment.
Seems like the humans are having a chat. I'll hop back into my burrow for now. If you need me again, just tag @coderabbitai in a new comment, and I'll come hopping out!
There was a problem hiding this comment.
In cloud, the customers can't modify the kafka_no_delete_topics configuration.
There was a problem hiding this comment.
@michael-redpanda Do you concur?
| . Remove `_redpanda.audit_log` topic from the `no_delete` topics list in your cluster configuration. | ||
| . Update the `retention.ms` property for the `_redpanda.audit_log` topic. | ||
| . Add the `_redpanda.audit_log` topic back to the `delete` topics list. |
There was a problem hiding this comment.
💡 Verification agent
🧩 Analysis chain
Property/feature names (“no_delete”/“delete list”) likely incorrect and unsafe in Cloud context.
- The names don’t match documented cluster properties in this file; and Cloud users typically cannot edit any internal topic delete protections.
- If these steps are kept for self‑managed, replace with exact property/UI names and provide corresponding rpk/Admin API examples, plus a warning about internal topic safety.
I can draft a self‑managed snippet with the exact rpk commands once you confirm the canonical property names that govern delete protections for internal topics.
🏁 Script executed:
#!/bin/bash
# Extract context and search for terms
echo "Context lines 390-420 in modules/manage/partials/audit-logging.adoc"
sed -n '390,420p' modules/manage/partials/audit-logging.adoc || true
echo ""
echo "Lines matching 'no_delete':"
rg -n -C2 'no_delete' modules/manage/partials/audit-logging.adoc || true
echo ""
echo "Lines matching 'delete list':"
rg -n -C2 'delete list' modules/manage/partials/audit-logging.adoc || trueLength of output: 2348
Update internal audit-log deletion instructions for self-managed and remove for Cloud
The current instructions under ifdef::env-cloud[] reference non-existent “no_delete” and “delete list” settings. The correct cluster property that protects internal topics from deletion and config changes is kafka_nodelete_topics. Cloud users cannot safely modify internal topics—Redpanda Cloud doesn’t expose deletion protection settings for internal topics and explicitly warns that changing built-in topics can cause failures.
Please refactor as follows:
• modules/manage/partials/audit-logging.adoc (lines 406–408):
– Replace the three list items with a self-managed-only snippet using the exact property name:
adoc NOTE: These steps apply only to self-managed clusters. Modifying internal topics can lead to data loss—proceed with caution. . View the current protected topics: `rpk cluster config get kafka_nodelete_topics` . Remove `_redpanda.audit_log` from the protected list: `rpk cluster config set kafka_nodelete_topics '["_schemas","__consumer_offsets"]'` . Update the retention period: `rpk topic alter-config _redpanda.audit_log --set retention.ms=259200000` . Add `_redpanda.audit_log` back to the protected list: `rpk cluster config set kafka_nodelete_topics '["_redpanda.audit_log","_schemas","__consumer_offsets"]'`
– Cite the cluster property docs for kafka_nodelete_topics and the internal-topic warning (docs.redpanda.com)
• Remove or hide this block under ifdef::env-cloud[]: Cloud users cannot edit internal topic deletion protections or retention settings.
|
|
||
| As you assess the retention needs for your audit logs, if you find that you do not need to keep them for the default seven days, and you must revise the retention period: | ||
|
|
||
| NOTE: Redpanda Data recommends that you retain audit logs for at least one year. |
There was a problem hiding this comment.
Redpanda Data recommends that you retain audit logs for at least one year in a separate system like your SIEM, so, in case there's an issue with the Redpanda cluster you still have access to the audit logs
| Ideally, you export audit events to your own SIEM for persistence supporting your audit and compliance needs rather than relying on in-cluster persistence. | ||
|
|
||
| As you assess the retention needs for your audit logs, if you find that you do not need to keep them for the default seven days, and you must revise the retention period: | ||
|
|
||
| NOTE: Redpanda Data recommends that you retain audit logs for at least one year. | ||
|
|
||
| . Remove `_redpanda.audit_log` topic from the `no_delete` topics list in your cluster configuration. | ||
| . Update the `retention.ms` property for the `_redpanda.audit_log` topic. | ||
| . Add the `_redpanda.audit_log` topic back to the `delete` topics list. |
There was a problem hiding this comment.
In cloud, the customers can't modify the kafka_no_delete_topics configuration.
Description
SMEs: Include in self-managed too?
Resolves https://redpandadata.atlassian.net/browse/DOC-1485
Review deadline:
Page previews
Configure retention for audit logs
Cloud doc
Checks