Skip to content
Open
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
10 changes: 9 additions & 1 deletion modules/manage/partials/audit-logging.adoc
Original file line number Diff line number Diff line change
Expand Up @@ -397,7 +397,15 @@ ifdef::env-cloud[]

== Configure retention for audit logs

Assess the retention needs for your audit logs. You may not need to keep the logs for the default seven days. This is controlled by setting the `retention.ms` property for the `_redpanda.audit_log` topic.
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.
Comment on lines +400 to +408
Copy link
Contributor

@coderabbitai coderabbitai bot Aug 22, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🛠️ Refactor suggestion

⚠️ Potential issue

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.

Suggested change
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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@michael-redpanda
Please let me know if CodeRabbit is right here. Can Cloud users do this or not?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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!

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In cloud, the customers can't modify the kafka_no_delete_topics configuration.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@michael-redpanda Do you concur?

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

According to https://github.com/redpanda-data/cloudv2/pull/22922, _redpanda.audit_log has been removed from no_delete in cloud, so I believe it would simply be updating retention.ms for the topic. @simon0191 is that correct?

Comment on lines +406 to +408
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

💡 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 || true

Length 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.


== Next steps

Expand Down