Create a policy | Trend Micro Service Central

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.

Tip

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

Procedure

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

Note

This section assumes you have added a cluster.

Procedure

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.

Procedure

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:

Procedure

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.

Note

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

Procedure

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

Note

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.

Property	Description
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](https://docs.docker.com/engine/reference/run/#runtime-privilege-and-linux-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](https://kubernetes.io/docs/concepts/security/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](https://www.first.org/cvss/specification-document#2-1-2-Attack-Complexity-AC). 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](https://docs.docker.com/engine/reference/run/#runtime-privilege-and-linux-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.