Table of contents

Create a policy

Policies define the rules that are used to control what is allowed to run in your Kubernetes cluster.

You will define one policy for each cluster that you want to protect, with a default set of rules (also known as a "policy definition") that apply to the entire cluster. If your cluster contains more than one namespace, you can also define separate sets of rules for the namespaces. Any namespace rules take precedence over the cluster-wide rules.

To begin with, we recommend that you create a policy with log-only rules. When you're satisfied that the policy is working as expected, change the rules to block objects that violate the policy.

Define a policy for a cluster

  1. Open the Trend Micro Cloud One console and select Container Security.
  2. Go to the Policies icon Policies page.
  3. Do one of the following:
    • If this is your first policy, click + New policy.
      A screen displayed only if there are no existing policies.
    • If this is not your first policy, select + New.
      An example of a cluster-wide policy defintion with all properties set to log
  4. Provide a unique Name for the policy that will help you identify its purpose, and optionally add a Description.
  5. In the Cluster-Wide Policy Definition area, configure the rules that you want to enforce with this policy. There are three tabs, corresponding to three different types of rules:

    • Deployment: These rules are enforced when an image is about to be deployed. Select the checkboxes for the rules that you want to enforce and use the drop-downs to choose what happens when a rule is violated: log an event (and allow the deployment) or block deployment.
    • Continuous: These rules are checked periodically while a pod is running. Select the checkboxes for the rules that you want to enforce and use the drop-downs to choose what happens when a rule is violated: log an event and allow the pod to keep running, isolate the pod's network traffic, or terminate the pod.
    • Runtime: On this tab, add one or more rulesets that contain rules you want to enforce while a pod is running. See Configure runtime security for information on how to enable runtime security and define a ruleset. The ruleset also defines what action Container Security takes if a pod violates any rule during runtime: log and event and allow the pod to keep running, isolate the pod's network traffic, or terminate the pod.

    For details about the rules, see About the rules.

    Deployment and continuous rules must be deployed in specific combinations:

    Deployment actions Continuous actions
    log log
    block log
    block isolate
    block terminate

    Container Security also has a default rule. For more information, see Trusted images.

  6. To finalize the policy, select Create.

Assign a policy to a cluster

This section assumes you have added a cluster.

  1. Go to the Clusters icon Clusters page.
  2. Select the Kubernetes cluster where you want to apply the policy.
  3. Select the policy from the Policy list.
  4. Select Save.

Add a policy definition for a namespace

If your cluster contains more than one namespace, you can create separate policy definitions for the namespaces. The namespace policy definition takes precedence over the cluster-wide policy definition.

  1. On the Policies icon Policies page, select the name of an existing cluster-wide policy.
  2. In the Policy Definitions section, next to the Cluster-Wide Policy Definition heading, select +.

    The Policy Definitions interface with the + button highlighted

  3. Scroll to the bottom of the page and select Expand icon in the new section that was added.

  4. Provide a unique Name for the policy that will help you identify its purpose.
  5. In the Namespaces area, add one or more Kubernetes namespaces that you want to protect with this new policy.
  6. Configure the deployment rules, continuous rules, and runtime rules as required, using the corresponding tabs. Select the checkboxes for the rules that you want to enforce and use the drop-downs to choose what happens when an object violates the rule. For information about the rules, see About the rules.
  7. Select Save.

If you want to add another set of namespace rules, select + to add a new namespace policy definition section.

Protect a namespace

To prevent attacks via Kubernetes credentials or misconfigured role-based access control, it is important to set up rules to log or block attempts to access those containers with special privileges. We recommend enabling this in the trendmicro-system namespace:

  1. Create a policy for a namespace for namespaces that you want to protect.
  2. Enable Kubectl access rules.

    Kubectl access

Test a policy

After you have created a policy and configured it to your liking, you're ready to use Container Security to protect your Kubernetes cluster.

Any deployment (kubectl, helm, etc.) will be reviewed by the deployment controller. In this example, we'll attempt to deploy a privileged busybox container.

This example assumes that you selected "Block" as the action for the privileged containers rule.

  1. Create a file named busybox.yaml with the following contents:

    apiVersion: v1
    kind: Pod
    metadata:
        name: busyboxpod
        labels:
            app: busyboxpod
    spec:
        containers:
        - image: busybox
          command:
              - sleep
              - "3600"
          imagePullPolicy: IfNotPresent
          name: busybox-container
          securityContext:
              privileged: true
        restartPolicy: Always

    In this pod definition, the securityContext is set to privileged = true. The policy that we created earlier should block this pod because we set the policy to block privileged containers.

  2. Ensure your kubectl context is set to your cluster.

  3. Use the following command to create the pod:

    $ kubectl apply -f busybox.yaml

  4. You should see that your request was denied:

    $ kubectl apply -f busybox.yaml
    Error from server: error when creating "busybox.yaml": admission webhook "trendmicro-admission-controller.default.svc" denied the request:
    - containerSecurityContext violates rule privileged "true" in container(s) "busybox-container" (block).
  5. If you go to the Events icon Events page in the Container Security console, you'll see a corresponding event:

    The Events page with a Block action in a policy named NewPolicy2

About the rules

Deployment rules

The rules on the Deployment tab are enforced when an image is about to be deployed or an action is about to be applied. You can choose to Log (and allow) or Block deployment based on these rules.

Pod properties

  • containers that run as root
  • containers that run in the host network namespace
  • containers that run in the host IPC namespace
  • containers that run in the host PID namespace

Container properties

  • containers that run as root
  • privileged containers
  • containers with privilege escalation rights
  • containers that can write to the root filesystem
  • containers with capabilities that violate a pre-defined policy

    Possible capability policies are:

    • restrict-nondefaults: Allows capabilities which are one of the default Docker capabilities.
    • baseline: Allows default capabilities but not the NET_RAW capability.
    • restricted: Allows only the NET_BIND_SERVICE capability.
    • restrict-all: Allows no capability.

    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.

    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.

    The CIS Kubernetes Benchmarks advises to not add any new capabilities and to drop, at the very least, the NET_RAW capability.

    Trend Micro 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.

Image properties

  • images from registries that meet specified criteria
  • images with names that meet specified criteria
  • images with tags that meet specified criteria

Scan results

The following rules require Deep Security Smart Check:

  • images that are not scanned
  • images with malware
  • images with content findings whose severity is severity level
  • images with checklists whose severity is severity level
  • images with vulnerabilities whose severity is severity level

The following rules require the latest version of Deep Security Smart Check:

  • images with vulnerabilities whose CVSS Attack Vector is vector and whose severity is severity

    For information on Attack Vector, see Attack Vector (AV) in the CVSS specification.


    Possible vectors are:

    • Local or physical
    • Adjacent
    • Network

    Possible severities are:

    • defcon 1
    • critical or higher
    • high or higher
    • medium or higher
    • low or higher
    • negligible or higher
    • any
  • images with vulnerabilities whose CVSS Attack Complexity is complexity and whose severity is severity

    For information on Attack Complexity, see Attack Complexity (AC) in the CVSS specification.


    Possible complexities are:

    • high
    • low

    Possible severities are:

    • defcon 1
    • critical or higher
    • high or higher
    • medium or higher
    • low or higher
    • negligible or higher
    • any
  • images with vulnerabilities whose CVSS Availability Impact is impact and whose severity is severity

    For information on Availability Impact, see Availability (A) in the CVSS specification.


    Possible impacts are:

    • high
    • low

    Possible severities are:

    • defcon 1
    • critical or higher
    • high or higher
    • medium or higher
    • low or higher
    • negligible or higher
    • any
  • images with a negative checklist type checklist result with severity severity.

    When Smart Check scans an image, it evaluates the images against pre-defined sets of rules to determine how well it adheres to common compliance standards (PCI-DSS v2, NIST 800-190, and HIPAA). In Container Security, you can log or block the deployment of a cluster if the associated image has a negative scan result for a checklist rule above a threshold severity.


    The checklist feature is currently supported for CentOS and Red Hat images only.


    Possible checklists are:

    • PCI-DSS v2: Trend Micro PCI-DSS v3 Container Image Compliance
    • NIST 800-190: Trend Micro NIST 800-190 Container Image Compliance
    • HIPAA: Trend Micro HIPAA Container Image Compliance

    Possible severities are:

    • defcon1
    • critical or higher
    • high or higher
    • medium or higher
    • low or higher
    • negligible or higher
    • any

    Some checklists don't include all of these severity levels. For example, the PCI-DSS v2 checklist currently has rules that range from low to high. The NIST 800-190 checklist currently only has high severity rules. The HIPAA profile currently has medium and high severity rules.

    Kubectl access

    We recommend setting up a namespaced policy using these rules to protect containers with special privileges including Container Security.

    • attempts to execute into a container
    • attempts to establish port-forward on a container

    Exceptions

    Use the Exceptions section to add exceptions that override the other deployment rules. For example, if you have a deployment rule that blocks images with names that contain "dev" but want to allow an image called "devone", add an exception for "images with names that equal devone".


    Possible exceptions are:

    • Allow images from registries with names that meet specified criteria
    • Allow images with names that meet specified criteria
    • Allow images with tags that meet specified criteria

Continuous rules

The rules on the Continuous tab are checked periodically while a pod is running. You can choose to Log and allow it to continue running, Isolate its network traffic, or Terminate the pod when a rule is violated.

Pod properties

  • containers that run as root
  • containers that run in the host network namespace
  • containers that run in the host IPC namespace
  • containers that run in the host PID namespace

Container properties

  • containers that run as root
  • privileged containers
  • containers with privilege escalation rights
  • containers that can write to the root filesystem
  • containers with capabilities that violate a pre-defined policy

    Possible capability policies are:

    • restrict-nondefaults: Allows capabilities which are one of the default Docker capabilities.
    • baseline: Allows default capabilities but not the NET_RAW capability.
    • restricted: Allows only the NET_BIND_SERVICE capability.
    • restrict-all: Allows no capability.

    For more information about the container capability rule, see the corresponding rule in Container properties of Deployment Rules above.

Image properties

  • images from registries that meet specified criteria
  • images with names that meet specified criteria
  • images with tags that meet specified criteria

Scan results

The following rules require Deep Security Smart Check:

  • images that are not scanned
  • images with malware
  • images with content findings whose severity is severity level
  • images with checklists whose severity is severity level
  • images with vulnerabilities whose severity is severity level

The following rules require the latest version of Deep Security Smart Check:

  • images with vulnerabilities whose CVSS Attack Vector is vector and whose severity is severity

    For information on Attack Vector, see Attack Vector (AV) in the CVSS specification.


    Possible vectors are:

    • Local or physical
    • Adjacent
    • Network

    Possible severities are:

    • defcon 1
    • critical or higher
    • high or higher
    • medium or higher
    • low or higher
    • negligible or higher
    • any
  • images with vulnerabilities whose CVSS Attack Complexity is complexity and whose severity is severity

    For information on Attack Complexity, see Attack Complexity (AC) in the CVSS specification.


    Possible complexities are:

    • high
    • low

    Possible severities are:

    • defcon 1
    • critical or higher
    • high or higher
    • medium or higher
    • low or higher
    • negligible or higher
    • any
  • images with vulnerabilities whose CVSS Availability Impact is impact and whose severity is severity

    For information on Availability Impact, see Availability (A) in the CVSS specification.

    Possible impacts are:

    • high
    • low

    Possible severities are:

    • defcon 1
    • critical or higher
    • high or higher
    • medium or higher
    • low or higher
    • negligible or higher
    • any
  • images with a negative checklist type checklist result with severity severity.

    When Smart Check scans an image, it evaluates the images against pre-defined sets of rules to determine how well it adheres to common compliance standards (PCI-DSS v2, NIST 800-190, and HIPAA). In Container Security, you can log or block the deployment of a cluster if the associated image has a negative scan result for a checklist rule above a threshold severity.


    The checklist feature is currently supported for CentOS and Red Hat images only.


    Possible checklists are:

    • PCI-DSS v2: Trend Micro PCI-DSS v3 Container Image Compliance
    • NIST 800-190: Trend Micro NIST 800-190 Container Image Compliance
    • HIPAA: Trend Micro HIPAA Container Image Compliance

    Possible severities are:

    • defcon1
    • critical or higher
    • high or higher
    • medium or higher
    • low or higher
    • negligible or higher
    • any

    Some checklists don't include all of these severity levels. For example, the PCI-DSS v2 checklist currently has rules that range from low to high. The NIST 800-190 checklist currently only has high severity rules. The HIPAA profile currently has medium and high severity rules.

Exceptions

Use the Exceptions section to add exceptions that override the other continuous rules. For example, if you have a continuous rule that blocks images with names that contain "dev" but want to allow an image called "devone", add an exception for "images with names that equal devone".

Possible exceptions are:

  • Allow images from registries with names that meet specified criteria
  • Allow images with names that meet specified criteria
  • Allow images with tags that meet specified criteria

Runtime rules

On the Runtime tab, add one or more rulesets that contain rules you want to enforce while a pod is running. See Configure runtime security for information on how to enable runtime security and define a ruleset, including how to add labels to control which pods the rules are applied to.