Security Center:Container file protection

Limitations

• Only the Ultimate edition of Security Center supports this feature. Other editions do not support this feature. For more information about how to purchase or upgrade Security Center, see Purchase Security Center and Upgrade and downgrade Security Center.

• The Security Center agent must be installed on the servers where the clusters you want to protect are deployed. For more information, see Install the Security Center agent.

• Only clusters connected to Security Center are protected. To protect a self-managed Kubernetes cluster, connect it to Security Center first. For more information, see Connect a self-managed Kubernetes cluster to Security Center.

• The operating system and kernel version of the servers that host your cluster must be within the supported range. For the full compatibility list, see Supported operating systems and kernel versions.

• The number of protected directories per pod label in a single cluster (counting only enabled rules) cannot exceed 10. Otherwise, container file protection becomes unavailable for the entire cluster.

• The total number of unique pod labels (after deduplication) across all enabled rules in a single cluster cannot exceed 10. Otherwise, container file protection becomes unavailable for the entire cluster.

  Example: Cluster01 has one pod (Pod01) with one label (Label01). You create 12 container file protection rules (Rule01–Rule12) for Cluster01:

  Rule01: references Label01 of Cluster01.

  Rule02: references Label02 of Cluster01 (a pod label can be referenced even if no pod currently uses it).

  ...

  Rule09: references Label09 of Cluster01.

  Rule10: references Label10 of Cluster01.

  Rule11: references Label10 of Cluster01.

  Rule12: references Label10 of Cluster01.

  After deduplication, 10 unique labels (Label01–Label10) are referenced. Container file protection works normally.

  If you create and enable Rule13 that references Label10 and Label11 of Cluster01, the deduplicated count becomes 11, and container file protection becomes completely unavailable for Cluster01.

Create a rule

1. Log on to Security Center console.

2. In the left-side navigation pane, choose Protection Configuration > Container Protection > Container File Protection. In the upper-left corner of the console, select the region where the asset to be protected is located: Chinese Mainland or Outside Chinese Mainland.

3. On the Container File Protection page, click Create Rule.

4. In the Create Rule panel, configure rule parameters and click Next.

   Protected File Directory, Processes in Whitelist, and Excluded File Path all support wildcards. Rules use exact matching. The following examples use /dir1/test to illustrate the matching logic:

   • /dir1/test (exact path): Matches only /dir1/test. Does not match /dir1/test/1.html or /dir1/test/dir1/2.html.

     • Protected File Directory: If set to /dir1/test, only the /dir1/test directory itself is protected (deleting or renaming /dir1/test triggers an alert or block). Subdirectories and files inside /dir1/test are not protected.

     • Whitelist: If set to /dir1/test, only processes spawned by the executable /dir1/test can modify the protected directory without triggering an alert or block. Processes spawned by /dir1/test/1.html still trigger alerts or blocks.

     • Excluded File Path: If Protected File Directory is set to /dir1/* and Excluded File Path is set to /dir1/test, only the /dir1/test directory itself is excluded. Deleting or renaming /dir1/test does not trigger the rule. However, modifying content inside /dir1/test/1.html still triggers an alert or block.

       Note

       All rules follow similar matching logic for Protected File Directory, Processes in Whitelist, and Excluded File Path. They only apply to matched paths.

   • /dir1/test* (wildcard suffix): Matches /dir1/test, /dir1/test/1.html, /dir1/test/dir1/2.html, /dir1/test1/1.html, /dir1/test2/2.html, and more.

   • /dir1/test/*.html (wildcard in path): Matches /dir1/test/index.html and /test/dir1/index.html.

   Parameter		Description	Example
   Rule Name		Enter a rule name. The name must be 6 to 50 characters in length, start with a letter or Chinese character, and can contain digits, underscores (_), and hyphens (-).	Cluster01
   Rule Configuration	Protected File Directory	Specify the directory to protect. Requirements: The path must start with a forward slash (/). Only one directory can be entered per line. The directory path must be fewer than 500 characters. Each rule can protect only one directory. To protect multiple directories, click Add in the Actions column. A single container file protection rule supports up to 10 protected directories.	Note To protect the /home directory and all its subdirectories and files, configure two protected directories: /home /home/* Alternatively, you can configure /home*, which also covers /home1/, /home2/, and similar directories.
   	Processes in Whitelist	Specify processes that can modify the protected directory and file paths that are excluded from protection. Processes in the whitelist or modifications to excluded file paths do not trigger alerts or blocks. Requirements: Each process or file path must be no longer than 50 characters. Separate multiple entries with semicolons (;). Each protected directory supports up to 10 whitelist processes and 10 excluded file paths. Follow these principles when configuring the whitelist and excluded file paths: Principle of least privilege: Add a process, file, or directory to the whitelist only when its access is essential for normal container operations. Be specific: Specify exact processes, files, and directories. Use wildcards with caution and avoid overly broad paths to minimize security risks.	/bin/cp;/usr/bin/mv;/bin/vi
   	Excluded File Path		/home/app/label/logs/*
   	Action	Select the action to take when tampering is detected. Options: Alerts: Security Center generates an alert only when the protected directory is tampered with. Block: Security Center generates an alert and blocks the corresponding process when the protected directory is tampered with. Note Note: Start with Alerts mode first. After you confirm that normal business operations do not trigger file protection alerts, switch to Block mode to avoid blocking legitimate processes. If a legitimate process is blocked, add it to the process whitelist.	Alert

5. Select the cluster and pod labels for the rule to take effect, then click OK.

   Use pod labels that start with app. In Kubernetes, labels are key-value pairs used to tag and classify resources such as Pods, Deployments, and Services. You can define custom labels based on scenarios, features, or purposes to better manage Kubernetes resources. Labels prefixed with app group resources by application. For more information, see Recommended labels.

   If no labels appear in the dropdown list, enter the pod label manually. To apply the rule to multiple pod labels in the same cluster or to multiple clusters, click Add in the Actions column.

Manage rules

After you create a rule, you can perform the following operations on the rule list on the Container File Protection page:

• Enable or disable a rule

  Toggle the switch in the Enable column of the target rule to enable or disable the rule.

• Edit a rule

  Click Edit in the Actions column of the target rule to modify the rule name, configuration, and scope.

• Delete a rule

  Note

  Deleted rules cannot be recovered. Confirm that you no longer need the rule before you delete it.

  Click Delete in the Actions column of the target rule, then click OK in the confirmation dialog box.

View alerting results

After you create and enable a container file protection rule, go to the Detection and Response > Alerts page. Click the Container tab, set the alert type to Proactive Defense for Containers, and look for alerts named File Protection. These are the alerts generated by the container file protection feature. Depending on the action configured in the rule, the following alerts are generated:

• Rules with the Alerts action generate security alerts in the Unhandled state. Handle these alerts promptly. For more information, see View and handle security alerts.

  On the Security Alerts page, set the status filter to Unhandled and set Alert Type to Container Active Defense to view and handle the corresponding File Defense alerts.

• Rules with the Block action generate security alerts in the Blocked state. Security Center automatically handles these alerts. You can view them in the handled alerts list.

  On the Security Alerts page, set the status filter to Handled and set Alert Type to Container Active Defense to view the blocking results for File Defense alerts.

Supported operating systems and kernel versions