Managing Kubernetes protection policies

Procedure

1. Go to Cloud Security → Container Security → Configuration.
2. Click the Policy tab.
3. Create, duplicate, or modify a policy.
   • To create a new policy, click +Create.
   • To duplicate an existing policy:
     1. Click to select the base policy from the policy list.
     2. Click Duplicate.
        Container Protection creates a copy of the existing policy and appends "Policy" to the policy name.
   • To modify an existing policy, click the policy in the policy list.
4. For new and duplicated policies, enter the following policy details:
   1. Specify a unique policy name.

      Note Policy names must not contain spaces and only support alphanumeric characters, underscores (_), and periods (.). You cannot modify the policy name after creating the policy.

   2. To provide more detail about the purpose for the policy, use the Description field.
      The description appears under the policy name in the policy list.
   3. To receive CREM Risk Insights, Workbench alerts, and use the Search app to investigate security threats throughout your network environment, turn on XDR Telemetry.
      TrendAI Vision One™ can correlate and assess XDR telemetry data across all configured data sources to provide insights into your network's security and risk posture.
   4. Select Kubernetes as the target platform, then click Proceed to Security Controls.

      Note Once a platform field is set for a policy, it cannot be changed.

5. Define the cluster-wide security controls.
   Deployment rules apply before an image is deployed, and Continuous rules apply periodically while the cluster is running.
   1. Select the rules that you want applied to the cluster.
   2. Select the action (Log/Block) to apply after a rule is triggered.
   3. If the rule provides additional parameters, define the values to check.
      Click the add symbol (+) next to the rule to duplicate the rule and have multiple rules of the same rule type.

      For the Resource properties rule [action] containers with capabilities that do not conform with a [predefined] policy, reference the following table for additional information.

      Predefined policy	Description
      restrict-nondefaults	Allows capabilities which are one of the [default Docker capabilities] For more information about default Docker policies, visit the Docker website at: https://docs.docker.com/engine/reference/run/#runtime-privilege-and-linux-capabilities
      baseline	Allows default capabilities but not the NET_RAW capability Note NET_RAW is a default capability that allows the use of RAW and PACKET sockets. With this capability, a malicious user may forge packets, execute MITM attacks, and perform other network exploits. This privilege is typically only used for specific networking needs, so dropping it should not have any effect on the majority of applications.
      restricted	Allows only the NET_BIND_SERVICE capability Note NET_BIND_SERVICE is a default capability that allows the binding to internet domain privileged ports (port numbers less than 1024). It is often used by web servers and for giving non-root users access to these ports.
      restrict-all	Allows no capability

      Note The CIS Kubernetes Benchmarks advises to not add any new capabilities and to drop, at the very least, the NET_RAW capability. TrendAI™ recommends considering container needs and applying a capability policy in alignment with the principle of least privileges. For more information on capability policies and pod security best practices, see the pod security standards at: https://kubernetes.io/docs/concepts/security/pod-security-standards/

   4. Configure scan exceptions as required.

      Note An exception is automatically added to allow trusted images used by Container Security.

   5. Configure Image Signature Verification rules as required.
      This section allows you to enforce that images are signed by a trusted source before they can be deployed. This feature uses attestors, which are managed separately. For more information, see Manage attestors.

      Note Policy exceptions do not apply to the signature verification rule. Image Signature Verification has its own exceptions that can be configured using the Preconditions.

      1. Define the Condition(s) to specify which container images the rule applies to.
      2. From the Signature material dropdown menu, select one or more pre-configured attestors. Choose whether to Match all or Match any of the selected attestors. If you need to add a new attestor, you can use the Add attestor link in the dropdown menu.
      3. Choose the Action to take when an image violates the rule (Log or Block).
      4. Click Add new verification rule to create multiple, independent signature rules within the same policy.
6. Define the cluster-wide rules that apply while a pod is running by clicking the Runtime tab.
   The runtime policy consists of the rulesets you create on the Rulesets tab.
   1. Click Add Ruleset.
   2. Select the checkbox of the ruleset you want to apply to the policy.
   3. Click Submit.
7. For users that need to configure special policies for specific namespaces within clusters, click the add symbol (+) next to the Cluster-wide Policy Definition header to define a NamespacedPolicyDefinition policy.
   1. Specify a name for the namespace-specific policy settings.
   2. Click Add.
   3. Specify the namespace within the cluster on which you want the policy to apply and press ENTER.
      Click Add again to specify multiple namespaces.
   4. Configure the Deployment and Continuous settings for the policy.

      Note You cannot configure specific runtime rulesets for namespaces.

   5. Define additional namespace policies by clicking the add symbol (+) next to the NamespacedPolicyDefinition headers.
8. Click Create or Save.