Container Asset Overview
What Is a Container Asset?
In a container environment, there are often dozens, even hundreds, of containers running on a cluster node. As containers increases and the runtime changes, it becomes difficult to manage complex container asset conditions, which may leave blind spots and expose risks.
HSS container asset management collects information about clusters, nodes, containers, images, and container fingerprints to help you clearly learn the asset status of the container environment, improve O&M efficiency, and comprehensively manage risks.
Container Asset Collection Items
Information about clusters, nodes, containers, images, and container fingerprints (including accounts, open ports, processes, software, auto-started items, web applications, web services, web frameworks, websites, middleware, and databases) can be collected. For details, see Container Asset Collection Items.
|
Asset Type |
Collection Description |
Collected Information |
|---|---|---|
|
Clusters |
Collect information about the cluster list, workloads, services, and pods, helping you learn the cluster status. |
|
|
Nodes |
Collect information about cluster nodes and independent nodes to help you learn about the node status. |
|
|
Containers |
Collect container information to help you learn the container running status and identify abnormal containers. |
Container name, cluster information, status, pod, cluster type, image name, and creation time |
|
Images |
Collect information about local images, repository images (including SWR, Harbor, and Jfrog), and CI/CD images to help you manage image sources and versions. |
|
|
Accounts |
Collect container system accounts to help you identify suspicious accounts. |
Account name, number of associated containers, server name and IP address, login permission, root permission, user group, user directory, user startup shell, and container ID |
|
Open ports |
Collect ports in the container system to help you identify risky ports. For details about the risky ports defined by HSS, see High-risk port list. |
Local port, protocol type, number of associated servers, server name and IP address, listening IP address, status, PID, program file, server port, and container ID |
|
Processes |
Collect processes running in the container system to help you detect abnormal processes (such as hidden processes and unknown hash processes). If a process has been inactive for 30 consecutive days, it will be automatically removed from the process list. |
Process path, number of associated containers, server name and IP address, startup parameter, startup time, the user who ran it, file permission, PID, file hash, and container ID |
|
Software |
Collect information about the software installed in the container system using the package manager (such as rpm and dpkg) to help you count software assets and identify insecure software versions. |
Software name, number of associated containers, server name and IP address, software version, and container ID |
|
Auto-started items |
Collect auto-started services, startup folders, pre-loaded dynamic libraries, Run registry keys, and scheduled tasks in the container system, helping you detect abnormal auto-started items in time and quickly locate Trojans. |
Auto-started item name, type, number of containers, server name and IP address, path, file hash, the user who ran it, and container ID |
|
Websites |
Collect information about web content directories and externally accessible websites, helping you comprehensively learn the website structure and access paths and preventing unauthorized access. Information about the following websites can be collected: Linux-based Apache, Nginx, and Tomcat. |
External domain name, number of containers, server name and IP address, external port, URL, web directory, directory permission, directory UID, last directory modification time, SSL certificate, certificate issuer, certificate user, certificate issuing time, certificate expiration time, associated PID, and container ID |
|
Web frameworks |
Collect information about the development framework used by web pages to help you identify framework vulnerabilities. The following types of web frameworks run on Linux and support data collection:
|
Web framework name, number of containers, server name and IP address, version number, path, associated PID, process path, and container ID |
|
Middleware |
Collect the JAR packages loaded by the Java process in the container system and the JAR packages that the Java process depends on, helping you understand the service support components and identify abnormal components. |
Middleware name, number of containers, server name and IP address, version number, path, associated PID, process path, and container ID |
|
Web services |
Collect details about the software that provides web content access for external systems, helping you learn the website hosting service settings and prevent vulnerabilities and unsafe settings. Data can be collected from the following web services: Apache, Nginx, Tomcat, WebLogic, WebSphere, JBoss, Wildfly, and Jetty. |
Web service name, number of containers, server name and IP address, version number, software directory, directory permission, directory UID, last modification time of the directory, configuration file, associated PID, process path, and container ID |
|
Web applications |
Collect details about the software that is used to push and publish web content, helping you learn the content transmission channels and prevent application vulnerabilities. Data of the following web applications can be collected: PHPMailer, PHPMyadmin, DedeCMS, WordPress, ThinkPHP, BigTree, JPress, Jenkins, Zabbix, Discuz!, and ThinkCMF. |
Web application name, number of containers, server name and IP address, version number, software directory, directory permission, directory UID, last modification time of the directory, configuration file, associated PID, process path, and container ID |
|
Databases |
Collect details about data storage software, helping you manage important data storage media and prevent database vulnerabilities and unsafe settings. Data can be collected from the following types of databases: MySQL, Redis, Oracle, MongoDB, Memcache, PostgreSQL, HBase, DB2, Sybase, Dameng database management system, and KingbaseES database management system. |
Database name, number of containers, server name and IP address, version number, software directory, directory permission, directory UID, last modification time of the directory, configuration file, associated PID, process path, and container ID |
Container Asset Collection Methods
Container asset information can be collected automatically or manually. You can set the automatic collection period or manually collect fingerprints as required.
- Automatic collection
After the container edition is enabled for a server, HSS container security automatically collects all asset information. For details about the collection types and intervals, see Table 2. The start time of the automatic collection period is the time when the agent is successfully installed.
Collection frequency can be customized for middleware, web frameworks, kernel modules, web applications, websites, web services, and databases. For details, see Asset Discovery.
Table 2 Asset types and frequencies of automatic collection Asset Type
Automatic Collection Frequency
Clusters
Automatic collection every 24 hours
Nodes
- Cluster nodes: Data is automatically collected every 24 hours.
- Independent nodes: Data is automatically collected after the agent is installed.
Containers
Automatic collection every 24 hours
Images
- Local images: After the agent is installed, data is collected for the first time. After that, data is automatically collected every 2.5 hours.
- Repository images: After the SWROperatePolicy and CCEOperatePolicy permissions are granted, the service automatically collects image information in the early morning every day. For details, see Authorization.
- CI/CD image: Data is automatically collected during CI/CD project building.
Accounts
Automatic collection every hour
Open ports
Automatic collection every 30 seconds
Processes
Automatic collection every hour
Software
Data is collected when the container is started. After the container is stopped, the collected data is automatically cleared.
Auto-started items
Automatic collection every hour
Websites
Once a week, at 04:10 a.m. every Monday (with a random delay of up to 1 hour)
Web frameworks
Once a week, at 04:10 a.m. every Monday (with a random delay of up to 1 hour)
Middleware
Once a week, at 04:10 a.m. every Monday (with a random delay of up to 1 hour)
Web services
Once a week, at 04:10 a.m. every Monday (with a random delay of up to 1 hour)
Web applications
Once a week, at 04:10 a.m. every Monday (with a random delay of up to 1 hour)
Databases
Once a week, at 04:10 a.m. every Monday (with a random delay of up to 1 hour)
- Manual collection
To check the latest asset fingerprints, use the one-click collection function provided by HSS container security to collect container fingerprints.
- For details about how to manually collect fingerprint information about all containers, see Manually Collecting the Latest Asset Fingerprints of All Containers.
- For details about how to manually collect information about the web applications, web services, web frameworks, websites, middleware, and databases on a single node, see Manually Collecting the Latest Container Fingerprints of a Single Node.
- For details about how to manually collect cluster, node, and container information, see Manually Collecting Cluster, Node, and Container Information.
- For details about how to manually collect image information, see Manually Collecting Image Information.
Notes and Constraints
- Container asset management is supported only by the HSS container edition. For details about how to purchase or upgrade to the container edition, see Purchasing HSS and Upgrading a Protection Quota..
- Before using container asset management, ensure the container asset has been connected to HSS.
- Accessing image assets: Connecting to a Third-party Image Repository and Integrating Image Security Scan in CI/CD
- Accessing cluster assets: Installing the Container Security Agent
- Supported container runtimes are Docker, Containerd, CRI-O, Podman, and iSulad.
- The CCE cluster version must be 1.19 or later.
Feedback
Was this page helpful?
Provide feedbackThank you very much for your feedback. We will continue working to improve the documentation.See the reply and handling status in My Cloud VOC.
For any further questions, feel free to contact us through the chatbot.
Chatbot