Get started with NeuVector, a cloud-native security platform

About the author Shaoyuan Wan, an officially certified Kubernetes CKA&CKS engineer by CNCF Foundation, a cloud native solution architect. In-depth research on ceph, Openstack, Kubernetes, prometheus technology and other cloud-native related technologies. Participated in the design and implementation of IaaS and PaaS platform design and application cloud native transformation guidance in multiple industries such as finance, insurance, and manufacturing.

foreword

NeuVector is the industry's first end-to-end open source container security platform and the only solution that provides enterprise-grade zero-trust security for containerized workloads. NeuVector can provide real-time in-depth container network visualization, east-west container network monitoring, active isolation and protection, container host security, and container internal security. The container management platform seamlessly integrates and automates application-level container security, suitable for various cloud environments. , container production environments such as cross-cloud or on-premises deployments.

Previously, we introduced the installation and deployment of NeuVector, high-availability architecture design and multi-cloud security management . This article will demonstrate the basic functions of NeuVector, including:

1. Security Vulnerability Management
2. Compliance Checks and Confidentiality Checks
3. Policy management
4. Admission Control Policy
5. Dynamic Security Response
6. behavior monitoring

Project address: https://github.com/neuvector/neuvector

This article is mainly based on NeuVector's first open source version, NeuVector:5.0.0-preview.1.

1. Security Vulnerability Management

NeuVector integrates the CVE vulnerability library, which is automatically updated every day, and supports security vulnerability scanning for platforms (Kubernetes), hosts, containers, and image warehouses.

Configure automatic scanning. When the platform vulnerability library is updated, or new nodes and containers are added, the scanning will be performed automatically.

For different vulnerabilities, there are different risk level prompts, corresponding component version prompts and repair version prompts.

For each vulnerability, NeuVector can display the corresponding vulnerability release time, vulnerability impact scope, and corresponding component impact version.

Filter the vulnerabilities to detect whether they have been fixed, as well as the vulnerability level, release time, etc.

1.1. Configuring Vulnerability Scanning for Connected Mirror Warehouses

Supports docking with various image repositories such as docker-registry (harbor), JFrog Artifactory, Nexus, etc.

Take docking Harbor as an example. Configure the connection method, fill in the connection method and authentication information, and the filter indicates the scope to be uat/* . Test setups can verify the association of expressions written.

2. Compliance Checks and Confidentiality Checks

NeuVector's compliance audits include CIS baseline testing, custom checks, confidential audits, and industry-standard template scans for PCI, GDPR, and other regulations.

"Type" indicates the corresponding baseline standard. For example, K.4.1.1 corresponds to the Kubernetes CIS baseline test, 4.1.1 The baseline standard corresponding to the container starts with D, and the baseline standard corresponding to the image starts with I.

Note: GDPR (General Data Protection Regulation) is an EU regulation.

The compliance check also checks for ciphertext leaks.

Including the following ciphertext leaks:

 General Private Keys
General detection of credentials including 'apikey', 'api_key', 'password', 'secret', 'passwd' etc.
General passwords in yaml files including 'password', passwd', 'api_token' etc.
General secrets keys in key/value pairs
Putty Private key
Xml Private key
AWS credentials / IAM
Facebook client secret
Facebook endpoint secret
Facebook app secret
Twitter client Id
Twitter secret key
Github secret
Square product Id
Stripe access key
Slack API token
Slack web hooks
LinkedIn client Id
LinkedIn secret key
Google API key
SendGrid API key
Twilio API key
Heroku API key
MailChimp API key
MailGun API key

3. Policy management

NeuVector manages containers and hosts through groups, and performs compliance checks, network rules, process and file access rules, and DLP/WAF detection configurations for groups.

NeuVector will automatically add the current cluster host to the nodes group, and automatically create a group starting with nv. for the container in the cluster.

NeuVector's group supports 3 modes: learning mode, monitoring mode and protection mode; the implementation of each mode is as follows:

• Learning mode learns and records containers, network connections between hosts, and process execution information.
  Automatically build a whitelist of network rules to protect the normal behavior of application networks.
  Set a security baseline for the processes running in each service's container and create a whitelist of process profile rules.
• monitor mode
  NeuVector monitors the network and process running of containers and hosts, and will alert NeuVector when encountering behaviors recorded in non-learning mode.
• protected mode
  NeuVector monitors the network and process operation of containers and hosts, and directly rejects the behavior recorded in non-learning mode.

The newly created container service is automatically discovered to be the learning mode by default, and the default mode can also be set to monitor mode or protection mode by setting.

In the case of different group policy conflicts, the applicable valid modes are as follows:

In order to ensure the stable operation of the business, when the mode is inconsistent, the effective mode runs in the mode with the least restriction.

The production environment best practice usage path can be:

• When launching a new service, first run the learning mode for a period of time, conduct a complete functional test and call test, and obtain information on the network connection and process execution of the actual service.
• The monitoring mode runs for a period of time to see if there are any additional special cases, make judgments, and add rules.
• Finally, all containers are switched to protected mode to determine the final form.

3.1. Dynamic Micro-Isolation

Scenario 1: PODs are isolated from each other through network policies

Create four Nginx in the Kubernetes platform with the following names and purposes:
workload_name: test-web1 image: nginx Purpose: web server
workload_name: test-con1 image: nginx Purpose: connect to client 1
workload_name: test-con2 image: nginx Purpose: connect to client 2
workload_name: test-con3 image: nginx Purpose: connect to client 3

Create workload

 kubectl create deployment test-web1 --image=nginx
kubectl expose deployment/test-web1 --port=80 --type=NodePort
kubectl create deployment test-con1 --image=nginx
kubectl create deployment test-con2 --image=nginx
kubectl create deployment test-con3 --image=nginx

At this point, these groups are automatically generated in NeuVector:

Access test-web1 via curl in test-con1

At this point, normal access is possible because NeuVector also automatically adds this access rule in learning mode.

Set both test-web1 and test-con2 to monitor mode

Then curl in test-con2 to access test-web1

At this point, test-con2 can access test-web1 normally, but an alarm will be generated in NeuVector

At the same time, correspondingly, in the network activity topology map, you can also see that the corresponding connection link turns red.

Set both test-web1 and test-con2 to protected mode, go to curl test-web1 through test-con2

Because curl is not used in learning mode, nor is it an executable process that NeuVector allows by default, the process is directly inaccessible.

Set test-con1 to protected mode, at which time test-con1 cannot access the external network.

Access can be opened by custom adding network rules.

On the Network Rules page, here the rules are already a list of rules generated in learning mode.

Add external access rules

NeuVector has a deep understanding of application behavior and will analyze the payload to determine the application protocol. Protocols include: HTTP, HTTPS, SSL, SSH, DNS, DNCP, NTP, TFTP, ECHO, RTSP, SIP, MySQL, Redis, Zookeeper, Cassandra, MongoDB, PostgresSQL, Kafka, Couchbase, ActiveMQ, ElasticSearch, RabbitMQ, Radius, VoltDB , Consul, Syslog, Etcd, Spark, Apache, Nginx, Jetty, NodeJS, Oracle, MSSQL and GRPC.

Now the curl of test-con1 can access www.baidu.com normally

Summarize:
In addition to the above strategies, NeuVector also has built-in network threat detection, which can quickly identify common network attacks and protect the safe operation of business containers.

Regardless of protected mode, in "Learn and Monitor" mode NeuVector will alert and these threats can be found in "Notifications > Security Events". You will be alerted and blocked in protected mode; you can also create response rules based on threat detections.

The included threat detections are as follows:

 SYN flood attack
ICMP flood attack
IP Teardrop attack
TCP split handshake attack
PING death attack
DNS flood DDOS attack
Detect SSH version 1, 2 or 3
Detect SSL TLS v1.0
SSL heartbeed attack
Detect HTTP negative content-length buffer overflow
HTTP smugging attack
HTTP Slowloris DDOS attack
TCP small window attack
DNS buffer overflow attack
Detect MySQL access deny
DNS zone transfer attack
ICMP tunneling attack
DNS null type attack
SQL injection attack
Apache Struts RCE attack
DNS tunneling attack
TCP Small MSS attack
Cipher Overflow attack
Kubernetes man-in-the-middle attack per CVE-2020-8554

3.2. Process management

NeuVector supports the management of processes in containers and hosts. In learning mode, running processes and commands are automatically added to the rules.

At this point, if you execute df -h in test-con1, you will find an error bash: /bin/df: Operation not permitted. Add the df process rule to the nv.test-con1.default group:

Then execute it again.

Process management also supports node nodes, which can be restricted in the node group to constrain the execution of the host process. For example, if the execution of docker cp is restricted, it can be learned from the learning mode that the docker-tar process is executed in the backend, switch the node to the protected mode, and limit the docker-tar process.

These cannot be executed on the node docker cp

4. Admission Policy Control

NeuVector supports docking with the Kubernetes admission control (admission-control) function, implements UI configuration admission control rules, intercepts requests, and verifies the requested resource objects.

NeuVector supports a variety of admission control policy rate configurations, such as image CVE vulnerability limit, deployment privileged mode, use of root user in the image, specific tags, etc.

Enable this function in Policy-Admission Control. Note: The admission-control function needs to be enabled in the Kubernetes cluster in advance

NeuVector admission policy control supports two modes: monitoring mode and protection mode, the corresponding meanings are the same as group mode. Here we switch directly to protected mode and add policies.

After adding, deploy the privileged mode in Rancher, the container will prompt to resolve, and the policy will take effect.

5. Dynamic Security Response

NeuVector Incident Response Mechanism can set response rules to dynamically respond to security incidents, including the following events: Vulnerability Scan Results, CIS Benchmarks, Admission Control Events, etc.

Response actions include quarantine, webhook notification, and log suppression:

• Isolation mode: All traffic in and out of the corresponding container network will be cut off.
• Webhook notification: Alert the trigger information through webhook.
• Log Suppression: Suppress triggering alarm information.

6. Behavior Monitoring

Taking the CVE vulnerability configuration as an example, configure the container containing the CVE vulnerability named CVE-2020-16156 to enter the isolation mode.

The group name corresponds to the scope of influence. If it is empty, it means that it is valid for all groups. Fill in the group name to set it to be valid for a specific group.

After configuring the policy, go to the cluster to curl the nginx container and find that it cannot be accessed. Check the container status in NeuVector as the isolated state.

When deleting a policy, you can also configure to release the corresponding quarantined container from quarantine.

Notice:

• Quarantine actions are not available for rules fired for host events.
• Each rule can have multiple actions.

6.1. Network Traffic Visualization

Network traffic visualization, you can clearly see the network connection relationship in the container cluster, the current container connection session, filter the network connection information, and display the icon; it can quickly locate network problems.

6.2. POD traffic capture

Network packet capture can be performed for containers, so that faults can be in-depth troubleshooting of network problems without entering the host to obtain high permissions.

The collected data packets can be downloaded directly and unpacked and analyzed by Wireshark.

Summarize

This time, we mainly explain the basic functions of NeuVector, and then we will introduce the configuration strategy and management of DLP and WAF in depth.