Use the inspection feature to check for security risks in the workloads of a registered Kubernetes cluster - Container Service for Kubernetes

Container Service for Kubernetes (ACK) provides the inspection feature to help you detect security risks in the workloads of ACK clusters. After an ACK cluster completes an inspection task, the cluster generates an inspection report. You can view and address the failed inspection items in the inspection report. This way, you can learn the real-time health status of the cluster.

Prerequisites

An external Kubernetes cluster is registered in the Container Service for Kubernetes (ACK) console. For more information, see Create ACK One registered clusters.
Logtail is installed. For more information, see Step 2: Install logtail-ds.

Perform an inspection task

Log on to the ACK console. In the navigation pane on the left, click Clusters.
On the Clusters page, find the cluster you want and click its name. In the left-side pane, choose Security > Inspections.
Optional: Install and update the security-inspector component.
The security-inspector component is free of charge but occupies pod resources. For more information about the introduction and release notes for the security-inspector component, see security-inspector.
Perform an inspection task.
Important
- We recommend that you perform inspection tasks during off-peak hours.
- By default, all inspection items are enabled for an inspection task. In the upper-right corner of the Inspections page, click Configure Periodic Inspection. In the panel that appears, you can configure inspection items for inspection tasks. For more information, see Inspection items.
- Immediately perform an inspection task: In the upper-right corner of the Inspections page, click Inspect.
- Perform inspection tasks on a regular basis: In the upper-right corner of the Inspections page, click Configure Periodic Inspection. Then, select Configure Periodic Inspection and configure the inspection cycle.
After the inspection task is completed, go to the Inspections tab, find the inspection result, and then click Details in the Actions column.

Inspection details

The Inspections page provides a table to show the inspection results of different workloads. The following features are provided to display the inspection results:

Filters inspection results based on conditions such as Passed or Failed, Namespace, and Workload Type. Displays the values of Number of Passed Items and Number of Failed Items for each inspected workload.
Displays detailed information about each inspection item on the inspection details page, including the passed and failed inspection items of each pod and container, description of each inspection item, and suggestions on security reinforcement. To ignore failed inspection items, add them to the whitelist.
View the YAML files of the workloads.

Inspection items

The following table describes the inspection items.

Inspection item ID	Inspection item	Inspection content and potential security risk	Suggestion
hostNetworkSet	Disable sharing of network namespaces between containers and hosts	Checks whether the pod specification of a workload contains the `hostNetwork: true` setting. This setting specifies that the pod uses the network namespace of the host. If the hostNetwork:true setting is specified, the host network may be attacked by containers in the pod and the data transfer in the host network may be sniffed.	Delete the `hostNetwork` field from the pod specification. Example:
hostIPCSet	Disable sharing of IPC namespaces between containers and hosts	Checks whether the pod specification of a workload contains the `hostIPC: true` setting. This setting specifies that the pod uses the inter-process communication (IPC) namespace of the host. If the hostIPC:true setting is specified, containers in the pod may attack the host processes and sniff process data.	Delete the `hostIPC` field from the pod specification. Example:
hostPIDSet	Disable sharing of PID namespaces between containers and hosts	Checks whether the pod specification of a workload contains the `hostPID: true` setting. This setting specifies that the pod uses the process ID (PID) namespace of the host. If the hostPID: true setting is specified, containers in the pod may attack the host processes and collect process data.	Delete the `hostPID` field from the pod specification. Example:
hostPortSet	Prevent processes in containers from listening on host ports	Checks whether the pod specification of a workload contains the `hostPort` field. This field specifies the host port to which the listening port of the pod is mapped. If the hostPort field is specified, the specified host port may be occupied without authorization and the container port may receive unexpected requests.	Delete the `hostPort` field from the pod specification. Example:
runAsRootAllowed	Disable container startup as a root user	Checks whether the pod specification of a workload contains the `runAsNonRoot: true` setting. This setting specifies that containers in the pod are not allowed to run as the root user. If the runAsNonRoot: true setting is not specified, malicious processes in the containers may intrude into your applications, hosts, or cluster.	Add the `runAsNonRoot: true` setting to the pod specification. Example:
runAsPrivileged	Disable container startup in privileged mode	Checks whether the pod specification of a workload contains the `privileged: true` setting. This setting specifies that containers in the pod are allowed to run in privileged mode. If the privileged: true setting is specified, malicious processes in the containers may intrude into your applications, hosts, or cluster.	Delete the `privileged` field from the pod specification. Example:
privilegeEscalationAllowed	Disable privilege escalation for child processes in containers	Checks whether the pod specification of a workload contains the `allowPrivilegeEscalation: false` setting. This setting specifies that the child processes of a container cannot be granted higher privileges than the parent process. If the allowPrivilegeEscalation:false setting is not specified, malicious processes in the container may be granted escalated privileges and perform unauthorized operations.	Add the `allowPrivilegeEscalation: false` setting to the pod specification. Example:
capabilitiesAdded	Disable unnecessary Linux capabilities	Checks whether the pod specification of a workload contains the `capabilities` field. This field is used to enable Linux capabilities for processes in containers. The capabilities include SYS_ADMIN, NET_ADMIN, and ALL. If the capabilities field is specified, malicious processes in the containers may intrude into your applications, cluster components, or cluster.	Modify the pod specification to retain only the required Linux capabilities and remove other capabilities. If processes in the containers do not require Linux capabilities, remove all Linux capabilities. Example: If processes in the containers require Linux capabilities, specify only the required Linux capabilities and remove other capabilities. Example:
notReadOnlyRootFileSystem	Enable the read-only mode for file systems in containers	Checks whether the pod specification of a workload contains the `readOnlyRootFilesystem: true` setting. This setting specifies that the root file system mounted to containers is read-only. If the readOnlyRootFilesystem: true setting is not specified, malicious processes in the containers may modify the root file system.	Add the `readOnlyRootFilesystem: true` setting to the pod specification. If you want to modify files in a specific directory, set the volumeMounts field in the pod specification. Example: If you want to modify files in a specific directory, set the `volumeMounts` field in the pod specification. Example:
cpuRequestsMissing	Set the minimum usage of CPU resources available for running containers	Checks whether the pod specification of a workload contains the `resources.requests.cpu` field. This field specifies the minimum CPU resources that are required for running each container. If the resources.requests.cpu field is not specified, the pod may be scheduled to a node that has insufficient CPU resources. This may lead to slow processes.	Add the `resources.requests.cpu` field to the pod specification. Example:
cpuLimitsMissing	Set the maximum amount of CPU resources available for running containers	Checks whether the pod specification of a workload contains the `resources.limits.cpu` field. This field specifies the maximum CPU resources that can be used by each container. If the resources.limits.cpu field is not specified, abnormal processes in containers may consume an excessive amount of CPU resources or exhaust the CPU resources of the node or cluster.	Add the `resources.limits.cpu` field to the pod specification. Example:
memoryRequestsMissing	Set the minimum memory resources available for running containers	Checks whether the pod specification of a workload contains the `resources.requests.memory` field. This field specifies the minimum memory resources that are required to run each container. If the resources.requests.memory field is not specified, the pod may be scheduled to a node that has insufficient memory resources. As a result, processes in containers may be terminated when the Out of Memory (OOM) killer is triggered.	Add the `resources.requests.memory` field to the pod specification. Example:
memoryLimitsMissing	Set the maximum memory resources available for running containers	Checks whether the pod specification of a workload contains the `resources.limits.memory` field. This field specifies the maximum memory resources that can be used by each container. If the resources.limits.memory field is not specified, abnormal processes in containers may consume an excessive amount of memory resources or exhaust the memory resources of the node or cluster.	Add the `resources.limits.memory` field to the pod specification. Example:
readinessProbeMissing	Configure container readiness probes	Checks whether the pod specification of a workload contains the `readinessProbe` field. This field specifies whether readiness probes are configured for containers. Readiness probes are used to check whether applications in the containers are ready to process requests. If the readinessProbe field is not specified, service exceptions may occur when requests are sent to applications that are not ready to process requests.	Add the `readinessProbe` field to the pod specification. Example:
livenessProbeMissing	Configure container liveness probes	Checks whether the pod specification of a workload contains the `livenessProbe` field. This field specifies whether liveness probes are configured for containers. Liveness probes are used to check whether a container restart is required to resolve application exceptions. If the livenessProbe field is not specified, the service may be interrupted when application exceptions can be resolved only by restarting containers.	Add the `livenessProbe` field to the pod specification. Example:
tagNotSpecified	Specify image versions for containers	Checks whether the `image` field in the pod specification of a workload specifies an image version or whether the value of the field is set to latest. If no image version is specified or the value of the field is set to latest, the service may be interrupted when containers use a wrong image version.	Modify the `image` field in the pod specification by specifying an image version. Set the field to a value other than latest. Example:
anonymousUserRBACBinding	Prohibit Anonymous Access to Cluster	Checks RBAC role bindings in the cluster and identifies the configurations that allow access from anonymous users. If anonymous users are allowed to access the cluster, they may gain access to sensitive information, attack the cluster, and intrude into the cluster.	Remove the configurations that allow access from anonymous users from the RBAC role bindings. Example: