Updated on 2025-09-17 GMT+08:00

Cluster Environment Security Overview

What Is Cluster Environment Security?

A cluster is a combination of cloud resources, such as cloud servers and load balancers, for container running. A cluster can be seen as one or more elastic cloud servers (nodes) in a same subnet. It provides compute resources for running containers.

Cluster environment security scans the resources on the Kubernetes cluster management plane and data plane; identifies infrastructure as code (IaC) risks, vulnerabilities, unsafe settings, configuration compliance, sensitive information, and permissions management issues; and provides solutions, helping you build a comprehensive cluster security system.

Regarding cluster security, the following items are checked:

  • System vulnerabilities: The vulnerabilities at the OS layer of the core components in the control plane, data plane, and image repositories of Kubernetes clusters.
  • Application software vulnerabilities: The application vulnerabilities in the core components of the Kubernetes cluster control plane, data plane, and image repositories.
  • Emergency vulnerabilities: The high-risk security vulnerabilities, such as 0-day vulnerabilities, in containers, container runtime components, and dependency packages.
  • Unsafe configuration: Kubernetes cluster settings, workloads, network policies, and role-based access control (RBAC) permissions are comprehensively checked to ensure that cluster deployment complies with best security practices.
  • Security and compliance: The security and compliance of Kubernetes cluster settings, workloads, network policies, and RBAC permissions are checked to ensure that cluster deployment complies with industry standards and regulations.
  • IaC risks: The risks in infrastructure as code (IaC).

System Vulnerability Scan Principles

HSS obtains the container images used by the core components of the Kubernetes cluster control plane, data plane, and image repositories. It scans these images for system vulnerabilities. For more information, see Table 1.

Table 1 Cluster components scanned by HSS

Namespace

Component

kube-system

kube-apiserver, kube-controller-manager, kube-scheduler, etcd, kube-proxy, coredns, metrics-server, calico/node, weaveworks/weave-kube

goharbor

harbor-core, harbor-portal, harbor-registry, harbor-jobservice, trivy-adapter, redis, PostgreSQL

docker.bintray.io

artifactory-pro, fluentd, bitnami/nginx

releases.jfrog.io

artifactory-pro, xray-server, pipelines, distribution

If the preceding components in a cluster are not running in containers or the cluster network is unreachable, the cluster cannot be scanned for system vulnerabilities.

The following OSs can be scanned for system vulnerabilities:
  • EulerOS 2.2, 2.3, 2.5, 2.8, 2.9, 2.10, 2.11, 2.12 (64-bit)
  • CentOS 7.4, 7.5, 7.6, 7.7, 7.8, 7.9, 8, 8.1, 8.2 (64-bit)
  • Ubuntu 16.04, 18.04, 20.04, 22.04, 24.04 (64-bit)
  • Debian 9, 10, 11, 12 (64-bit)
  • Kylin V10, V10 SP1, V10 SP2, and V10 SP3 (64-bit)
  • HCE 1.1 and 2.0 (64-bit)
  • SLES 12 SP5, 15 SP1, and 15 SP2 (64-bit)
  • UnionTech OS V20 server E, V20 server D, 1050u2e, 1050e, 1060e, 1070e (64-bit)
  • Rocky Linux 8.4, 8.5, 8.6, 8.10, 9.0, 9.1, 9.2, 9.4, 9.5 (64-bit)
  • openEuler 20.03 LTS, 20.03 LTS SP1, 20.03 LTS SP2, 20.03 LTS SP3, 20.03 LTS SP4
  • openEuler 22.03 LTS, 22.03 LTS SP1, 22.03 LTS SP2, 22.03 LTS SP3, 22.03 LTS SP4
  • openEuler 24.03 LTS
  • CTyunOS 3-23.01 (64-bit)
  • AlmaLinux 8.4 (64-bit)
  • Oracle Enterprise Linux 7, 8, 9 (64-bit)
  • Red Hat Enterprise Linux 7, 8, 9 (64-bit)

Application Vulnerability Scan Principles

Kubernetes clusters can be set up in image or binary mode. In image-based deployment, Kubernetes core components are packaged into images and deployed as containers on nodes. In binary deployment, Kubernetes core components are binary executable files (non-container images), and they can run after you manually configure system service management components.

  • Application vulnerability scan on container images

    HSS obtains the container images used by the core components of the Kubernetes cluster control plane, data plane, and image repositories. It scans these images for application vulnerabilities. For more information, see Table 2.

    Table 2 Cluster components scanned by HSS

    Namespace

    Component

    kube-system

    kube-apiserver, kube-controller-manager, kube-scheduler, etcd, kube-proxy, coredns, metrics-server, calico/node, weaveworks/weave-kube

    goharbor

    harbor-core, harbor-portal, harbor-registry, harbor-jobservice, trivy-adapter, redis, PostgreSQL

    docker.bintray.io

    artifactory-pro, fluentd, bitnami/nginx

    releases.jfrog.io

    artifactory-pro, xray-server, pipelines, distribution

    If the preceding components in a cluster are not running in containers or the cluster network is unreachable, the cluster cannot be scanned for application vulnerabilities.

    The applications and middleware that can be scanned include: log4j, slf4j, Tomcat, apache, jetty, mysql, druid, commons, spring, shiro, struts, struts2, websocket, json, fastjson, xstream, maven, junit, activemq, libintl, ca-certificates-java, httpclient, httpcore, java, javac2, javaee, Apache2, adaptive_server_enterprise, DB2, http_server, Memcached, nginx, PostgreSQL, bootstrap, zookeeper, plexus-utils, and core.

  • Application vulnerability scan on binary files

    To perform an application vulnerability scan, HSS obtains the binary files of critical Kubernetes components, including kube-apiserver, kube-controller-manager, kubelet, kube-proxy, kube-scheduler, etcd, and cni-plugins.

Unsafe Configuration and Compliance Scan Principles

To identify unsafe configuration and non-compliance issues, HSS uses a pre-defined security framework and dynamic policy engine to perform in-depth checks on Kubernetes cluster configuration, workloads, network policies, and RBAC permissions. The two types of issues are checked in different dimensions and scenarios. For details, see Table 3.

Table 3 Comparison between unsafe configuration checks and compliance checks

Difference

Unsafe Configuration

Security and Compliance

Dimension

Based on Huawei Cloud's years of experience in cloud security, this service checks the configuration of Kubernetes components, workloads, network policies, and more resources, helping to ensure it complies with best security practices.

Based on industry standards and regulations, this service checks the configuration of Kubernetes components, workloads, network policies, and more resources, helping to ensure it meets security and compliance requirements.

Risk type

Control plane, access control, key management, network, workload, and node escape.

For details, see Table 4.

Control plane, access control, network, and workload.

For details, see Table 4.

Scenario

Security assurance during critical periods or events. A comprehensive evaluation can be performed on a cluster, helping to ensure each of its components uses the recommended security configuration, thereby reducing risks.

Compliance check. It helps to ensure the configuration of each component in a cluster complies with industry standards and existing laws and regulations, reducing compliance risks.

Table 4 describes the types of risks that can be detected in unsafe configuration checks and compliance checks.

Table 4 Risk types

Risk Type

Description

Control plane

Check the security of Kubernetes control plane components, including API Server, Controller Manager, Scheduler, and etcd. For example, check whether etcd data is encrypted.

Access control

Check the security rules related to Kubernetes authentication, authorization, and RBAC configuration. For example, check whether a user or account has excessive permissions.

Key management

Check how secrets are stored, used, and protected in Kubernetes. For example, check whether the access to secrets is restricted.

Network

Check the Kubernetes network policies and security rules related to inter-service communication. For example, check whether a proper network policy is defined to restrict the communication between pods.

Workload

Check the security configuration of workloads, such as pods, Deployments, StatefulSets, and DaemonSets. For example, check whether containers are run by non-root users.

Node escape

Check whether there are security risks that can be exploited by attackers to escape from containers to hosts. For example, check whether the Docker socket (/var/run/docker.sock) is mounted.

Emergency Vulnerability Scan Principles

Version comparison and PoC verification are performed to check for vulnerabilities in runc and other container runtime components, dependency packages, and the software running in containers.

IaC Risk Scan Principles

The Infrastructure as Code (IaC) files uploaded by users are checked against the built-in IaC risk rule library to detect risks.

Currently, the following file types can be scanned: Dockerfile (image configuration file) and Kubernetes YAML (cluster resource configuration file).

Application Scenarios of Cluster Environment Security

  • Improving cluster environment security

    Scan the cluster environment to detect and fix security vulnerabilities, unsafe settings, and IaC risks as soon as possible, improving environment security and reducing intrusion risks.

  • Ensuring cluster environment compliance

    Cluster environment security scans help you ensure that containerized applications and related settings comply with the strict regulations and standards in different industries.

  • Improving the quality of containerized applications and services

    Regular cluster security scans and problem rectification help the development team better understand related specifications, improving the development quality and efficiency of containerized applications and services.

Constraints

  • Kubernetes cluster version: Cluster security scans are supported for version 1.19 and later.
  • Prerequisites for IaC risk scan: You have purchased the container edition. For details, see Purchasing an HSS Quota.
  • Prerequisites for the scans for system vulnerabilities, application vulnerabilities, unsafe configuration, and security & compliance:
    1. The cluster has been connected to HSS and the connection is normal. For details, see Overview of Agent Installation in a Cluster.
    2. At least one node in the cluster is protected by the container edition. For details, see Enabling Protection.
  • Prerequisites for emergency vulnerability scans: The nodes to be scanned are protected by the container edition. For details, see Enabling Protection.

Cluster Environment Scan Process

Figure 1 Usage process
Table 5 Usage process

Operation

Description

Checking Cluster Environment Security

Manually scan clusters, nodes, and IaC for risks.

Viewing and Handling Security Risks in a Cluster

Check the security scan results and mitigate risks in the cluster environment in a timely manner.