We are investigating a CIS compliance finding on AKS Azure Linux 3 worker nodes using Microsoft-managed node images.
The finding is caused by the following Azure monitoring agent files under /var/log being created with 0644 permissions:
ls -l /var/log/omsagent-fblogs.db*
-rw-r--r-- 1 root root 45056 Aug 13 13:40 /var/log/omsagent-fblogs.db
-rw-r--r-- 1 root root 32768 Aug 13 13:41 /var/log/omsagent-fblogs.db-shm
-rw-r--r-- 1 root root 4140632 Aug 13 13:41 /var/log/omsagent-fblogs.db-wal
Because these files are 0644, the other-read permission is enabled, causing our CIS host configuration assessment for log-file permissions to fail.
We opened a case with Microsoft AKS Support. AKS Support confirmed that /var/log/omsagent-fblogs.db-wal is owned by the managed monitoring agent component and advised against directly modifying the file permissions on AKS worker nodes because OS-level modifications may not persist through node image upgrades, scaling, or node replacement.
AKS Support recommended contacting the Azure Monitor component-owning team regarding the agent's configuration/design.
Questions
Could you please clarify:
Is 0644 the expected/default permission for the omsagent-fblogs.db, omsagent-fblogs.db-shm, and omsagent-fblogs.db-wal files?
If so, is there a specific reason these database files need to be readable by users outside the owner/group?
Is there a supported configuration for the monitoring agent to create these files with more restrictive permissions, such as 0640 or 0600?
If the permissions are not configurable today, is there a Microsoft-supported remediation for AKS customers who need these files to satisfy CIS log-file permission requirements?
Would changing these permissions externally (for example, using chmod) interfere with the managed monitoring agent or be reverted when the files are recreated?
We would prefer not to implement a node-level permission enforcement workaround because AKS Support has advised against directly modifying managed component files on AKS worker nodes.
Our goal is to determine whether the current permissions are by design and identify the Microsoft-supported approach for maintaining CIS compliance.
Thank you.
We are investigating a CIS compliance finding on AKS Azure Linux 3 worker nodes using Microsoft-managed node images.
The finding is caused by the following Azure monitoring agent files under /var/log being created with 0644 permissions:
ls -l /var/log/omsagent-fblogs.db*
-rw-r--r-- 1 root root 45056 Aug 13 13:40 /var/log/omsagent-fblogs.db
-rw-r--r-- 1 root root 32768 Aug 13 13:41 /var/log/omsagent-fblogs.db-shm
-rw-r--r-- 1 root root 4140632 Aug 13 13:41 /var/log/omsagent-fblogs.db-wal
Because these files are 0644, the other-read permission is enabled, causing our CIS host configuration assessment for log-file permissions to fail.
We opened a case with Microsoft AKS Support. AKS Support confirmed that /var/log/omsagent-fblogs.db-wal is owned by the managed monitoring agent component and advised against directly modifying the file permissions on AKS worker nodes because OS-level modifications may not persist through node image upgrades, scaling, or node replacement.
AKS Support recommended contacting the Azure Monitor component-owning team regarding the agent's configuration/design.
Questions
Could you please clarify:
Is 0644 the expected/default permission for the omsagent-fblogs.db, omsagent-fblogs.db-shm, and omsagent-fblogs.db-wal files?
If so, is there a specific reason these database files need to be readable by users outside the owner/group?
Is there a supported configuration for the monitoring agent to create these files with more restrictive permissions, such as 0640 or 0600?
If the permissions are not configurable today, is there a Microsoft-supported remediation for AKS customers who need these files to satisfy CIS log-file permission requirements?
Would changing these permissions externally (for example, using chmod) interfere with the managed monitoring agent or be reverted when the files are recreated?
We would prefer not to implement a node-level permission enforcement workaround because AKS Support has advised against directly modifying managed component files on AKS worker nodes.
Our goal is to determine whether the current permissions are by design and identify the Microsoft-supported approach for maintaining CIS compliance.
Thank you.