This topic describes how to use the Inspection component to inspect the security of the workloads in an Alibaba Cloud Container Service for Kuebernetes (ACK) cluster and how to view inspection reports. This way, you can check whether the workloads in your ACK cluster are running in a secure environment.

Prerequisites

A managed or dedicated ACK cluster of Kubernetes 1.14.8 or later is created. For more information, see Create a managed ACK cluster.

Inspect the security of the workloads in an ACK cluster

  1. Log on to the ACK console.
  2. In the left-side navigation pane, choose Clusters > Clusters.
  3. On the Clusters page, click the target cluster or click Manage in the Actions column.
  4. In the left-side navigation pane, choose Security > Inspections.
  5. Optional:If the Inspection component is not installed, click Install Inspection Component, and then click Get Started. If you have already installed the Inspection component, skip this step.
  6. On the Inspections page, click Inspect in the upper-right corner of the page.
  7. After the inspection is complete, click Refresh to refresh the page and view the inspection report.Inspection

Inspection report

An inspection report shows the last inspection result, including the following information:
  • Overview of the inspection. This includes the number of check items, the quantity and ratio of each resource object, and the overall health status.
  • Statistics of each inspection category. This includes the results of image, network, resource, and security inspections, and the results of health checks.
  • Detailed inspection results of each workload configuration. This includes resource categories, resource names, namespaces, inspection types, check items, and inspection results of each workload.

The following table lists the check items.

Check item Content and potential security risk Suggestion
hostNetworkSet Checks whether the Pod Spec contains the hostNetwork: true setting. This setting indicates that the network namespace of the host is shared with the pod. If hostNetwork: true is configured, 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 setting from the Pod Spec.

Example:1
hostIPCSet Checks whether the Pod Spec contains the hostIPC: true setting. This setting indicates that the IPC namespace of the host is shared with the pod. If hostIPC: true is configured, the host process may be attacked by containers in the pod and the process data may be sniffed.

Delete the hostIPC setting from the Pod Spec.

Example:2
hostPIDSet Checks whether the Pod Spec contains the hostPID: true setting. This setting indicates that the PID namespace of the host is shared with the pod. If hostPID: true is configured, the host processes may be attacked by containers in the pod and the process data may be sniffed. Delete the hostPID setting from the Pod Spec.
Example:3
hostPortSet Checks whether the Pod Spec contains the hostPort parameter. This parameter specifies the host port to which the listening port of the pod is mapped. If the hostPort parameter is specified, the host port may be occupied without authorization and the container port may receive unexpected requests. Delete the hostPort parameter from the Pod Spec.
Example:4
runAsRootAllowed Checks whether the Pod Spec contains the runAsNonRoot: true setting. This setting indicates that a user can run containers in a pod as a root user. If runAsNonRoot: true is configured, malicious processes in containers may intrude your applications, hosts, or even the cluster. Delete the runAsNonRoot: true setting from the Pod Spec.
Example:5
runAsPrivileged Checks whether the Pod Spec contains the privileged: true setting. This setting indicates that a user can run containers in privileged mode. If privileged: true is configured, malicious processes in containers may intrude your applications, hosts, or even the cluster. Delete the privileged: true setting from the Pod Spec.
Example:6
privilegeEscalationAllowed Checks whether the Pod Spec contains the allowPrivilegeEscalation: true setting. This setting indicates that the child processes of a container is granted privileges higher than those of its parent. If allowPrivilegeEscalation: true is configured, malicious processes in containers may be granted escalated privileges and perform unauthorized operations. Delete the allowPrivilegeEscalation setting from the Pod Spec.
Example:7
capabilitiesAdded Check whether the Pod Spec contains the capabilities parameter. This parameter is used to grant the containers in the pod permissions on Linux capabilities, such as the SYS_ADMIN, NET_ADMIN, and ALL permissions. If privileged: true is configured, malicious processes in containers may intrude your applications, hosts, or even the cluster. Retain only the required permissions on Linux capabilities, and remove other permissions from the parameter.

Retain only required permissions on Linux capabilities. Example:

8
Grant only required permissions on Linux capabilities. Example:9
notReadOnlyRootFileSystem Check whether the Pod Spec contains the readOnlyRootFilesystem: true setting. This setting indicates that the root filesystem mounted to containers is read-only. If readOnlyRootFilesystem: true is not configured, malicious processes in the containers may modify the root filesystem. Add the readOnlyRootFilesystem: true setting to the Pod Spec. If you need to modify files in a specified directory, you can pass the volumeMounts parameter to the Pod Spec.

Example:

10

If you need to modify files in a specified directory, you can pass the volumeMounts parameter to the Pod Spec.

Example:11
cpuRequestsMissing Checks whether the Pod Spec contains the resources.requests.cpu parameter. This parameter specifies the minimum CPU resources that must be guaranteed to run each container. If the resources.requests.cpu parameter is not specified, the pod may be scheduled on nodes with insufficient CPU resources. As a result, processes in the containers run at a slow rate. Add the resources.requests.cpu parameter to the Pod Spec.

Example:

12
cpuLimitsMissing Checks whether the Pod Spec contains the resources.limits.cpu parameter. This parameter specifies the maximum CPU resources that are used to run each container. If the resources.requests.cpu parameter is not specified, abnormal processes in the containers may exhaust CPU resources of the node or even the cluster. Add the resources.limits.cpu parameter to the Pod Spec.

Example:

13
memoryRequestsMissing Checks whether the Pod Spec contains the resources.requests.memory parameter. This parameter specifies the minimum memory resources that are guaranteed to run each container. If the resources.requests.memory parameter is not specified, the pod may be scheduled on a node with insufficient memory resources. As a result, processes in the containers may be terminated due to an OOM (out-of-memory) error. Add the resources.requests.memory parameter to the Pod Spec.

Example:

14
memoryLimitsMissing Checks whether the Pod Spec contains the resources.limits.memory parameter. This parameter specifies the maximum memory resources that are used to run each container. If the resources.limits.memory parameter is not specified, abnormal processes in the containers may exhaust memory resources of the node or even the cluster. Add the resources.limits.memory parameter to the Pod Spec.

Example:

15
readinessProbeMissing Checks whether the Pod Spec contains the readinessProbe parameter. This parameter specifies whether readiness probes are configured for containers. Readiness probes are used to check whether applications in containers are ready to accept requests. If the readinessProbe parameter is not specified, service exceptions may occur when applications cannot accept requests. Add the readinessProbe parameter to the Pod Spec.

Example:

16
livenessProbeMissing Checks whether the Pod Spec contains the livenessProbe parameter. This parameter specifies whether liveness probes are configured for containers. Liveness probes are used to check whether the system needs to restart the containers to resolve application anomalies. If the livenessProbe parameter is not specified, service exceptions may occur when application anomalies can be resolved only by restarting the relevant containers. Add the livenessProbe parameter to the Pod Spec.

Example:

17
tagNotSpecified Checks whether the image parameter in the Pod Spec specifies an image tag or whether the value of the parameter is set to latest. If no image tag is specified or the value of the parameter is set to latest, service exceptions may occur when the containers use the wrong image version. Modify the image parameter in the Pod Spec by specifying an image tag. Do not set the value of the parameter to latest.

Example:

18