http://starrocks.io logo
Join Slack
Powered by
I have a question about AuditLoader Plugin retenti...
# questions-and-troubleshooting
s
I have a question about AuditLoader Plugin retention policy. I was able to install the AuditLoader plugin successfully, I wanted to know if there is any retention policy I can set on the audit loader tables .? I do not see any information about retention policy in the document. https://docs.starrocks.io/docs/3.5/administration/management/audit_loader/
@Rocky can you let me know what would be the retention policy for audit logger table when using AudiLogger Plugin.?
r
The retention policy for audit logs when using the AuditLoader Plugin (often referred to as the AuditLogger) is managed at two different levels: the local log files on the FE (Frontend) nodes and the StarRocks table where the logs are loaded. 1. Retention for the Audit Log Table (Internal Table) Since the AuditLoader plugin loads data into a standard StarRocks table, the retention is controlled by the table's Partition TTL or Dynamic Partitioning settings. In the official recommended setup for the audit log table: * Default Retention: Usually 30 days. * Mechanism: It typically uses the 
partition_live_number
property (or 
dynamic_partition.start
in older versions). * Configuration: When creating the table, the 
PROPERTIES
define how many partitions to keep. For example:
Copy code
sql
    CREATE TABLE starrocks_audit_db*.starrocks_audit_tbl* (
      ...
    )
    PARTITION BY date_trunc('day', `timestamp`)
    PROPERTIES (
      "partition_live_number" = "30" -- This keeps only the last 30 days of data
    );
If you need to change this, you can alter the table:
Copy code
sql
    ALTER TABLE starrocks_audit_db*.starrocks_audit_tbl*
    SET ("partition_live_number" = "90"); -- Changes retention to 90 days
2. Retention for Local FE Log Files Before the logs are loaded into the table, they exist as physical files on each FE node's disk (located at 
fe/log/fe.audit.log
). These are managed by FE configuration parameters: * 
audit_log_delete_age
: Controls how long the log files are kept on disk. * Default: 
30d
(30 days). * 
audit_log_roll_num
: Controls the maximum number of audit log files to retain. * Default: 
90
. * 
log_cleaner_audit_log_min_retention_days
: Ensures audit logs are not deleted even if disk space is low until this many days have passed. * Default: 
3
. Summary * Table Data: Controlled by 
partition_live_number
(Recommended: 30 days). * Disk Files: Controlled by 
audit_log_delete_age
(Default: 30 days). If you are following the standard installation guide, your audit log table will likely purge data older than 30 days automatically. To keep logs for a longer period, you must increase the 
partition_live_number
in the table properties. References • administration/management/audit_loader.md • table_design/data_distribution/dynamic_partitioning.md
s
@Rocky can I use openssl AES_128_CBC to encrypt the creds instead of using 
SELECT TO_BASE64(AES_ENCRYPT('password','secret_key'));
.
r
To use OpenSSL to encrypt credentials for the AuditLoader plugin, you should use AES-128-ECB rather than AES-128-CBC. The AuditLoader plugin expects the password to be encrypted using StarRocks' default 
AES_ENCRYPT
behavior. Since the recommended SQL command 
SELECT TO_BASE64(AES_ENCRYPT('password','secret_key'));
does not specify an encryption mode or an Initialization Vector (IV), it defaults to AES-128-ECB. Why you shouldn't use AES-128-CBC The AuditLoader plugin's 
plugin.conf
does not provide a field for an Initialization Vector (IV). CBC mode requires an IV to function; without it, the plugin's internal decryption logic (which is hardcoded to match the default SQL function) will fail to decrypt a CBC-encrypted string. How to use OpenSSL (AES-128-ECB) To produce a result identical to the StarRocks SQL command using OpenSSL, follow these steps: 1. Convert your Secret Key to Hex: StarRocks pads keys shorter than 16 bytes with zeros (
\0
). If your 
secret_key
is 
my_secret
, you must convert it to a 32-character hex string (16 bytes). * Example: 
my_secret
in hex is 
6d795f736563726574
. * Padded to 16 bytes: 
6d795f73656372657400000000000000
. 2. Run the OpenSSL command:
Copy code
bash
    echo -n "your_password" | openssl enc -aes-128-ecb -K <your_hex_key> -nosalt -base64
Example Comparison * StarRocks SQL:
Copy code
sql
    SELECT TO_BASE64(AES_ENCRYPT('test_pass', 'my_key'));
    -- Output: 'S3V6Y2V7A9G9y/U7z9I9pg==' (example)
* OpenSSL Command:
Copy code
bash
    # Hex for 'my_key' padded with zeros: 6d795f6b657900000000000000000000
    echo -n "test_pass" | openssl enc -aes-128-ecb -K 6d795f6b657900000000000000000000 -nosalt -base64
Summary of Plugin Settings In your 
plugin.conf
, ensure the following: * `password`: Paste the Base64 string generated by the OpenSSL command. * `secret_key`: Use the same plaintext key (e.g., 
my_key
) used in the encryption step. Note: The 
secret_key
must not be longer than 16 bytes. If you need a more secure posture, it is recommended to manage access via StarRocks RBAC (Role-Based Access Control) to limit who can view the 
plugin.conf
file on the FE nodes. References • administration/management/audit_loader.md • loading/Flink-connector-starrocks.md • loading/Spark-connector-starrocks.md • loading/Kafka-connector-starrocks.md
s
@Rocky what grants does the db user needs so that plugin can write into the audit logger table .?
r
For the AuditLoader Plugin to successfully write audit logs into your StarRocks cluster, the database user configured in 
plugin.conf
requires the 
INSERT
 privilege on the target audit table. In the StarRocks Role-Based Access Control (RBAC) system, the 
INSERT
privilege is what allows a user to perform Stream Load operations, which is the underlying mechanism the plugin uses to send data. Required Grants Assuming your audit database is 
starrocks_audit_db*
and your table is 
starrocks_audit_tbl*
, you should execute the following SQL commands to set up the user:
Copy code
sql
-- 1. Create a dedicated user for the plugin
CREATE USER 'audit_loader_user'@'%' IDENTIFIED BY 'your_password';

-- 2. Grant INSERT privilege on the audit table
GRANT INSERT ON TABLE starrocks_audit_db__.starrocks_audit_tbl__ TO USER 'audit_loader_user'@'%';
Why only 
INSERT
? * Stream Load: The AuditLoader plugin reads the local 
fe.audit.log
file and pushes the data to the FE using the HTTP Stream Load interface. Stream Load only requires the 
INSERT
permission on the destination table. * No SELECT needed: The plugin itself does not need to read the table; it only writes to it. (However, you as an admin will need 
SELECT
privileges to query the logs later). Additional Tips * Database Scope: If you prefer, you can grant the privilege at the database level:
Copy code
sql
    GRANT INSERT ON DATABASE starrocks_audit_db__ TO USER 'audit_loader_user'@'%';
* Verification: After configuring the user in 
plugin.conf
and installing the plugin, check the FE leader's 
fe.log
. If there is a permission issue, you will see errors containing 
Access denied
or 
Unauthorized
associated with the "audit" keyword. * Encryption: If you are encrypting the password in 
plugin.conf
(as discussed previously), ensure the 
secret_key
and the encrypted string match what the user actually uses. References • administration/management/audit_loader.md • loading/StreamLoad.md • sql-reference/sql-statements/account-management/GRANT.md References • loading/StreamLoad.md • loading/Stream_Load_transaction_interface.md • loading/loading_introduction/loading_concepts.md • sql-reference/sql-statements/loading_unloading/BROKER_LOAD.md • loading/RoutineLoad.md • sql-reference/sql-statements/loading_unloading/STREAM_LOAD.md • loading/Etl_in_loading.md • loading/Flink_cdc_load.md
s
I already have insert grant for the user, but still I see 401, access denied if fe.log. @Rocky
r
The 
401 Access Denied
error in your 
fe.log
while using the AuditLoader plugin almost always points to an Authentication failure rather than a missing privilege (which usually results in a 403 Forbidden). Even if you have granted 
INSERT
privileges, here are the three most likely reasons for this error: 1. Host Mismatch (
127.0.0.1
) By default, the AuditLoader plugin in 
plugin.conf
is configured to connect to 
127.0.0.1:8030
. If you created your user with a specific IP (e.g., 
'audit_user'@'10.0.0.5'
), StarRocks will deny the connection when the plugin tries to log in from 
127.0.0.1
. Solution: Ensure the user is allowed to connect from the local loopback address or any host:
Copy code
sql
-- Check existing users
SELECT user, host FROM mysql.user WHERE user = 'your_audit_user';

-- If it's not '%' or '127.0.0.1', recreate or add the host:
CREATE USER 'your_audit_user'@'127.0.0.1' IDENTIFIED BY 'your_password';
GRANT INSERT ON starrocks_audit_db__.starrocks_audit_tbl__ TO USER 'your_audit_user'@'127.0.0.1';
2. Password Encryption Mismatch In 
plugin.conf
, there is a 
secret_key
field. * If 
secret_key
is empty: The 
password
field must be the plaintext password. * If 
secret_key
is set: The 
password
field must be the Base64-encoded encrypted string (the output of the 
AES_ENCRYPT
function), NOT the plaintext password. If you provided a 
secret_key
but entered the plaintext password in the 
password
field, the plugin will decrypt the plaintext string into garbage data and fail to log in, resulting in a 
401
. 3. Special Characters in 
plugin.conf
 The 
plugin.conf
file is a standard properties-style file. If your password contains special characters (like 
#
, 
=
, or spaces), they might be misinterpreted by the plugin loader. * Recommendation: Use a password with only alphanumeric characters if possible, or ensure it is encrypted using the 
secret_key
method to bypass character parsing issues in the config file. 4. Privilege Scope While you mentioned you have the 
INSERT
grant, verify it is granted at the Table or Database level, not just a global level that might not have propagated.
Copy code
sql
-- Verify privileges
SHOW GRANTS FOR 'your_audit_user'@'127.0.0.1';
The user requires: • 
INSERT
on the audit table. • No other global privileges are strictly required for the plugin to function. How to apply changes: After you modify 
plugin.conf
to fix the credentials: 1. Uninstall the plugin: 
UNINSTALL PLUGIN AuditLoader;
2. Repackage the zip: (Important: StarRocks loads the config from the zip during installation). 3. Install the plugin: 
INSTALL PLUGIN FROM "/path/to/auditloader.zip";
Pro Tip: To verify if the credentials work outside of the plugin, try a manual Stream Load from the command line on the same FE server using the same credentials:
Copy code
bash
curl --location-trusted -u audit_user:password -H "label:test_123" \
     -T /dev/null  <http://127.0.0.1:8030/api/starrocks_audit_db__/starrocks_audit_tbl__/_stream_load>
If this 
curl
command also returns 
Access Denied
, the issue is definitely the StarRocks user/password/host configuration. References • administration/management/audit_loader.md • loading/StreamLoad.md • sql-reference/sql-statements/account-management/CREATE_USER.md References • loading/loading_introduction/loading_concepts.md • loading/StreamLoad.md • loading/Stream_Load_transaction_interface.md
s
@Rocky I am using encrypted password with secret key and I verifed the encryption and decryption is producing correct creds and the user has all grants for db and table. However when I decrypt it, I see this hex string is too short, padding with zero bytes to length, is that the reason I am seeing 401 errors ?
r
The "hex string is too short" message is an OpenSSL warning, and while it is often harmless, it is a strong indicator that the manual encryption/decryption process you are using doesn't perfectly align with how StarRocks handles the password internally. This is likely the reason you are seeing 401 Access Denied errors. Even if your manual 
openssl
test says the decryption is "correct," the plugin is likely deriving a different plaintext password than the one you intended. Here are the specific reasons why this happens and how to fix it: 1. The Key Type Mismatch (String vs. Hex) * In `plugin.conf`: The 
secret_key
you provide is treated as a literal string. * In OpenSSL: The 
-K
flag expects a Hexadecimal string, not a plaintext string. * The Conflict: If your secret key is 
my_key
and you run 
openssl -K my_key
, OpenSSL tries to interpret "my_key" as hex. Since 'm', 'y', and 'k' are not valid hex characters, it fails or produces a completely different binary key than the string "my_key". The Fix: You must convert your 
secret_key
string to hex first.
Copy code
bash
# Example: If your secret_key is 'my_key'
echo -n "my_key" | xxd -p
# Output: 6d795f6b6579
Then use that hex output in your OpenSSL command. 2. Zero-Padding Behavior StarRocks (following MySQL's logic) handles keys for AES-128 by taking exactly 16 bytes. If your key is shorter than 16 bytes, it pads the right side with null bytes (
\0
). The warning 
hex string is too short, padding with zero bytes to length
means OpenSSL is doing exactly that—appending zeros to the right to reach 32 hex characters (16 bytes). While the padding logic is the same, the 401 error occurs if the base string you started with wasn't converted to hex correctly (as noted in point 1). 3. Encryption Mode (CBC vs. ECB) As mentioned in our earlier discussion, the AuditLoader plugin uses StarRocks' default encryption, which is AES-128-ECB. * If you are still testing with 
aes-128-cbc
in OpenSSL, it will never match the plugin. * ECB does not use an IV. If you are providing an 
-iv
in OpenSSL, the plugin will ignore it, causing a decryption mismatch. The "Golden" OpenSSL Command to Match StarRocks To ensure your encrypted password in 
plugin.conf
exactly matches what the StarRocks plugin expects, use this specific sequence: 1. Prepare your Key: Let's say your 
secret_key
is 
abc123
. 2. Convert Key to 32-char Hex (padded with zeros):
Copy code
bash
    # String 'abc123' to hex is 616263313233.
    # To make it 32 chars (16 bytes), add twenty 0s:
    # 61626331323300000000000000000000
3. Encrypt the Password:
Copy code
bash
    echo -n "your_actual_password" | openssl enc -aes-128-ecb -K 61626331323300000000000000000000 -nosalt -base64
Checklist for the 401 Error If you still see 401 after using the command above: 1. Check for Newlines: When you copy the Base64 string into 
plugin.conf
, ensure there are no trailing spaces or hidden newline characters. 2. Restart/Reinstall: StarRocks plugins often cache configurations. You must 
UNINSTALL PLUGIN AuditLoader
and 
INSTALL PLUGIN...
again after modifying the zip file to ensure the new 
plugin.conf
is loaded. 3. Plaintext Test: Temporarily remove the 
secret_key
from 
plugin.conf
and put the password in plaintext. If it still gives a 401, the issue is not encryption—it's likely the 
user
host (e.g., the user needs to be allowed to connect from 
127.0.0.1
). References • administration/management/audit_loader.md
s
@Rocky having special character 
\
in the encrypted password will have an issue .?
r
Yes, having a backslash (
\
) in any value inside 
plugin.conf
(including the encrypted password or the secret key) will cause issues because 
plugin.conf
is parsed as a standard Java Properties file. In Java Properties files, the backslash is a special escape character. If the parser sees a 
\
, it attempts to escape the character following it (e.g., 
\n
becomes a newline, 
\t
becomes a tab). If the character following the backslash isn't a valid escape sequence, the backslash is often simply dropped or results in an incorrect string. Why this happens The 
AuditLoader
plugin uses the internal StarRocks plugin loader, which reads 
plugin.conf
using 
java.util.Properties
. * Encrypted Password: Standard Base64 strings (the output of 
AES_ENCRYPT
+ 
TO_BASE64
) do not typically contain backslashes (they use 
+
, 
/
, and 
=
). If you see a 
\
in your encrypted string, it may have been added by an external tool or a copy-paste error. * Secret Key: If your 
secret_key
is something like 
my\key
, Java will interpret it as 
mykey
(dropping the 
\
) or fail to parse it. This means the plugin will use a different key for decryption than the one you used for encryption, leading to a 
401 Access Denied
error. How to Fix It If you must use a backslash in your password or secret key, you have two options: Option 1: Escape the Backslash In 
plugin.conf
, you must use double backslashes (
\\
) to represent a single literal backslash.
Copy code
properties
# If your key is 'abc\123', write it as:
secret_key=abc\\123

# If your encrypted password somehow contains a '\', double it:
password=AAbc\\def/ghi==
Option 2: Avoid Special Characters (Recommended) To prevent parsing issues and "hex string too short" warnings: 1. Use a Simple Secret Key: Use a 16-character alphanumeric string (e.g., 
1234567890abcdef
) for your 
secret_key
. This avoids both Java parsing issues and OpenSSL padding warnings. 2. Generate the Encrypted String via SQL: Instead of using OpenSSL, use StarRocks itself to generate the exact string it expects. This ensures no hidden characters or formatting issues:
Copy code
sql
    -- Run this in StarRocks to get the exact value for plugin.conf
    SELECT TO_BASE64(AES_ENCRYPT('your_actual_password', 'your_simple_key'));
3. Re-install the Plugin: After updating 
plugin.conf
, you must uninstall and reinstall the plugin for the changes to take effect:
Copy code
sql
    UNINSTALL PLUGIN AuditLoader;
    -- (Update zip file with new plugin.conf)
    INSTALL PLUGIN FROM "/path/to/auditloader.zip";
Summary Checklist * Is there a 
\
? Change it to 
\\
in 
plugin.conf
. * Is there a 
#
? If a 
#
appears in your password or key, it might be treated as a comment. Ensure it's not at the start of a line or escape it. * Hex warning still appearing? Ensure your 
secret_key
is exactly 16 characters long to avoid the "padding with zero bytes" behavior which can lead to mismatches between OpenSSL and Java. References • administration/management/audit_loader.md • administration/management/FE_configuration.md • loading/Flink-connector-starrocks.md
Open in Slack
PreviousNext
Powered by