microsoft / microsoft/AzureMonitorCommunity

Azure Monitor managed agent creates omsagent-fblogs.db* files with world-readable permissions on AKS nodes

Open
#303 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
PowerShell
Stars
1.2k
Forks
493
PR merge metrics
No merged PRs in 30d

Description

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.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

The issue concerns /var/log/omsagent-fblogs.db, /var/log/omsagent-fblogs.db-shm, and /var/log/omsagent-fblogs.db-wal on AKS Azure Linux nodes. Start by reviewing the Azure Monitor managed agent ownership and the AKS Support guidance in the issue; done means documenting whether the permissions are expected, whether they are configurable, and what supported CIS-compliance approach exists.

Written by the indexing model from the issue text.

Assessment

Tech stack
azure, kubernetes, linux
Domain
cloud, infrastructure, observability, security
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Quiet
Clarity
Needs clarification
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.