Security Center:Use the container file protection feature

Limits

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

• Only clusters that are connected to Security Center can be protected. If you want to use Security Center to protect a self-managed cluster, you must connect the cluster to Security Center. For more information, see Connect a self-managed Kubernetes cluster to Security Center.

• The operating systems and kernel versions of the servers on which your cluster is deployed must be supported by the container file protection feature. For more information about the operating systems and kernel versions that are supported by the container file protection feature, see Supported operating systems and kernel versions.

• The number of protected directories to which a pod label is added in a cluster cannot exceed 10. Only the protected directories for which rules are enabled are counted. If the number of protected directories exceeds 10, the container file protection feature becomes unavailable for the cluster.

• The number of pod labels that are specified in all enabled rules in a cluster cannot exceed 10 after deduplication. If the number of pod labels exceeds 10, the container file protection feature becomes unavailable for the cluster.

  For example, Cluster01 is created and contains Pod01. Only Label01 is added to Pod01. In addition, 12 rules are created for Cluster01. The rules range from Rule01 to Rule12.

  In Rule01, Label01 of Cluster01 is specified as the pod label.

  In Rule02, Label02 of Cluster01 is specified as the pod label. You can use Label02 regardless of whether it is added to a pod in Cluster01.

  ...

  In Rule09, Label09 of Cluster01 is specified as the pod label.

  In Rule10, Label10 of Cluster01 is specified as the pod label.

  In Rule11. Label10 of Cluster01 is specified as the pod label.

  In Rule12, Label10 of Cluster01 is specified as the pod label.

  A total of 12 pod labels are specified for Cluster01. After deduplication, the number becomes 10. In this case, the container file protection feature can take effect for the cluster as expected.

  If you create Rule13 by specifying Label10 and Label11 for Cluster01, the total number of pod labels after deduplication is 11. In this case, the container file protection feature becomes unavailable for Cluster01.

Prerequisites

The Security Center agent is installed on the servers on which your cluster is deployed. For more information, see Install the Security Center agent.

Create a rule

1. Log on to the Security Center console. In the top navigation bar, select the region of the asset that you want to protect. You can select China or Outside China.

2. In the left-side navigation pane, choose Protection Configuration > Container Protection > Container File Protection.

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

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

   You can use wildcard characters when you specify values for the Protected File Directory, Whitelist, and Excluded File Path parameters. A rule takes effect in exact match mode. In the following list, the /dir1/test directory is used as an example to describes the matching logic of rules:

   • If you specify /dir1/test for the Protected File Directory, Whitelist, or Excluded File Path parameter, only the /dir1/test directory is matched when the rule takes effect. Directories such as /dir1/test/1.html and /dir1/test/dir1/2.html are not matched.

     • If you specify /dir1/test for the Protected File Directory parameter, only the /dir1/test directory is protected. If the /dir1/test directory is deleted or renamed, an alert is generated or the process is blocked. Subdirectories and files in the /dir1/test directory are not protected.

     • If you specify /dir1/test for the Whitelist parameter, only the /dir1/test directory is added to the whitelist. If the processes created by the executable file /dir1/test access the protected directory, no alert is generated and the processes are not blocked. However, if the processes created by the /dir1/test/1.html directory access the protected directory, an alert is generated or the processes are blocked.

     • If you specify /dir1/* for the Protected File Directory parameter and /dir1/test for the Excluded File Path parameter, only the /dir1/test directory is added to the whitelist. If the /dir1/test directory is deleted or renamed, no alert is generated and the process is not blocked. If the content in the /dir1/test/1.html directory is modified, an alert is generated or the process is blocked.

       Note

       All rules take effect only on the paths that are matched based on the Protected File Directory, Whitelist, and Excluded File Path parameters.

   • If you specify /dir1/test* for the Protected File Directory, Whitelist, or Excluded File Path parameter, directories such as /dir1/test, /dir1/test/1.html, /dir1/test/dir1/2.html, /dir1/test1/1.html, and /dir1/test2/2.html can be matched.

   • If you specify /dir1/test/*.html for the Protected File Directory, Whitelist, or Excluded File Path parameter, directories such as /dir1/test/index.html and /test/dir1/index.html can be matched.

   Parameter		Description	Example
   Rule Name		Enter a name for the rule. The name must be 6 to 50 characters in length and can contain letters, digits, underscores (_), and hyphens (-). It must start with a letter.	Cluster01
   Rule Configuration	Protected File Directory	Enter the directory that you want to protect. When you configure this parameter, take note of the following items: The directory must start with a forward slash (/). You can enter only one directory. The length of a directory must be less than 500 characters. You can enter only one directory each time. To protect multiple directories, click Add in the Actions column. You can specify up to 10 directories in a rule.	/home/app/label/* Note If you want to protect the /home directory and all subdirectories and files in the directory, we recommend that you create two rules for the following directories: /home /home/* You can also create a rule for the /home* directory. In this case, directories such as /home1/ and /home2/ can also be protected.
   	Whitelist	Enter the processes that are allowed to modify the protected directory, or enter the directories that can be modified. If a process is added to the whitelist or a directory is added to the Excluded File Path parameter, no alert is generated and the process is not blocked when the process modifies files or the directory is modified. When you configure the two parameters, take note of the following items: A single process or directory can be up to 50 characters in length. You must separate multiple processes or directories with semicolons (;). You can specify a maximum of 10 whitelist processes and 10 excluded file paths for a protected directory. You must follow the following principles when you configure a whitelist and excluded file path: Least privilege: Specify a process, file, or directory only when access of the process, file, or directory is required in the normal workloads of your containers. Exactness: Specify an exact process, file, or directory. Use wildcard characters with caution to minimize security risks.	/bin/cp;/usr/bin/mv;/bin/vi
   	Excluded File Path		/home/app/label/logs/*
   	Action	Select the action that you want Security Center to perform when a tampering operation is detected. Valid values: Alert: When Security Center detects tampering operations on files in the directory, Security Center only generates alerts. Block: When Security Center detects tampering operations on files in the directory, Security Center generates alerts and blocks the tampering processes. Note We recommend that you first set the Action parameter to Alert. After you confirm that no false alerts are generated, change the Action parameter to Block. This prevents normal processes from being blocked. If a blocked process is required in your workloads, you can add the process to the whitelist.	Alert

5. Select the cluster on which you want the rule to take effect in the Cluster Name column, select a pod label in the Pod Tag column, and then click OK.

   We recommend that you select a pod label that starts with app. In Kubernetes, labels are key-value pairs and are used to label and classify Kubernetes resources, such as pods, Deployments, and services. You can add custom labels to Kubernetes resources based on scenarios, features, or purposes to better manage the resources. Labels that start with app are used to organize resources by application. For more information about labels, see Recommended Labels.

   If no labels are displayed in the drop-down list, you must enter a label. If you want the rule to take effect on multiple clusters or multiple pod labels in a cluster, you can click Add in the Actions column to specify multiple clusters or pod labels.

Manage a rule

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

• Enable or disable the rule

  Find the rule and turn on or turn off the switch in the Enable column to enable or disable the rule.

• Modify the rule

  Find the rule and click Edit in the Actions column to modify the name, configurations, and scope of the rule.

• Delete the rule

  Important

  After a rule is deleted, it cannot be restored. Make sure that you no longer need a rule before you delete it.

  Find the rule and click Delete in the Actions column. In the message that appears, click OK.

View alerting results

After you create and enable a rule, choose Detection and Response > Alerts, click the Container tab, and then set Alert Type to Container Active Defense. In the alert list, you can view the alerts that are generated by the container file protection feature. The names of the alerts start with File Defense. Alert states vary based on the action specified in the rule that triggers the alerts.

• If an alert is triggered by a rule whose Action is Alert, the alert is in the Unhandled state. We recommend that you handle this type of alert at the earliest opportunity. For more information, see View and handle security alerts.

  

• If an alert is triggered by a rule whose Action is Block, the alert is in the Blocked state. This type of alert is automatically handled by Security Center. You can view this type of alert in the list of handled alerts.

  

Supported operating systems and kernel versions