Topics on this page

Define a policy for a cluster

Assign a policy to a cluster

Add a policy definition for a namespace

Protect a namespace

Test a policy

About the rules

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

Open the Trend Micro Cloud One console and select Container Security.
Go to the Policies page.
Do one of the following:
- If this is your first policy, click + New policy.
- If this is not your first policy, click + New.
Provide a unique Name for the policy that will help you identify its purpose, and optionally add a Description.
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.
To finalize the policy, select Create.

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

Assign a policy to a cluster

This section assumes you have added a cluster.

Go to the Clusters page.
Select the Kubernetes cluster where you want to apply the policy.
Select the policy from the Policy list.
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.

On the Policies page, select the name of an existing cluster-wide policy.
In the Policy Definitions section, next to the Cluster-Wide Policy Definition heading, select +.
Scroll to the bottom of the page and select in the new section that was added.
Provide a unique Name for the policy that will help you identify its purpose.
In the Namespaces area, add one or more Kubernetes namespaces that you want to protect with this new policy.
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.
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:

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

Test a policy

After you have created and configured a policy, you can use Container Security to protect your Kubernetes cluster.

Any deployment (kubectl, helm, etc.) is 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.

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.

Ensure your kubectl context is set to your cluster.
Use the following command to create the pod:

$ kubectl apply -f busybox.yaml

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).

If you go to the Events page in the Container Security console, you'll see a corresponding event:

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 are supported by Trend Micro Artifact Scanner (TMAS):

images that are not scanned
images with malware
images with vulnerabilities whose severity is severity level
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:
- 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:
- 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

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

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.

Topics on this page

Create a policy

Define a policy for a cluster

Assign a policy to a cluster

Add a policy definition for a namespace

Protect a namespace

Test a policy

About the rules

Pod properties

Container properties

Image properties

Scan results

Kubectl access

Exceptions

Pod properties

Container properties

Image properties

Exceptions

Previous

Next