The inspection feature in Container Service for Kubernetes (ACK) scans your cluster workloads for security misconfigurations and generates a report. Review failed inspection items to understand your cluster's security posture and fix vulnerabilities before they become incidents.
Prerequisites
Before you begin, make sure that you have:
A cluster running Kubernetes 1.14 or later. To update a cluster, see Manually update ACK clusters.
(RAM users only) RAM authorization and role-based access control (RBAC) authorization completed, as described below.
RAM and RBAC authorization for RAM users
Skip this section if you use an Alibaba Cloud account instead of a Resource Access Management (RAM) user.
RAM authorization
Grant the RAM user permissions to operate the Inspections page. Without these permissions, the page is inaccessible. For instructions, see Create a custom RAM policy.
Use the following policy to grant permissions for the Inspections page:
{
"Statement": [
{
"Action": [
"cs:DescribePolarisConfig",
"cs:DescribePolarisJob",
"cs:DescribePolarisCronJob",
"cs:UpdatePolarisJob",
"cs:UpdatePolarisCronJob"
],
"Effect": "Allow",
"Resource": [
"acs:cs:*:*:cluster/<yourclusterID>"
]
}
],
"Version": "1"
}To view inspection reports, also grant the RAM user read permissions for the Simple Log Service (SLS) project used by your cluster's log collection component. For instructions, see Use custom policies to grant permissions to a RAM user.
Use the following policy to grant SLS read permissions:
{
"Version": "1",
"Statement": [
{
"Action": [
"log:Get*",
"log:List*"
],
"Resource": "acs:log:*:*:project/<Project name>/*",
"Effect": "Allow"
}
]
}RBAC authorization
After completing RAM authorization, grant the RAM user administrator-level RBAC permissions to manage your cluster. This authorizes the RAM user to manage the Kubernetes resources displayed on the Inspections page. For instructions, see Grant RBAC permissions to RAM users or RAM roles.
Run an inspection
Log on to the ACK console. In the left navigation pane, click Clusters.
On the Clusters page, click the name of the target cluster. In the left-side pane, choose Security > Inspections.
(Optional) Install or update the security-inspector component. The security-inspector component is free of charge but consumes pod resources. For details, see security-inspector.
Run an inspection: By default, all inspection items are enabled. To customize which items are checked, click Configure Periodic Inspection in the upper-right corner and configure inspection items in the panel that appears. For a full list of items, see Inspection items.
Immediate inspection: Click Inspect in the upper-right corner.
Scheduled inspection: Click Configure Periodic Inspection in the upper-right corner, select Configure Periodic Inspection, and set the inspection cycle.
ImportantRun inspections during off-peak hours to reduce impact on running workloads.
After the inspection completes, go to the Inspections tab, find the result, and click Details in the Actions column.
Review inspection results
Inspection details
The Inspections tab shows per-workload results. Use the Passed or Failed, Namespace, and Workload Type filters to focus on workloads with security issues.
For each workload, the table shows the Number of Passed Items and Number of Failed Items. Click Details to see:
Pass/fail status for each inspection item, broken down by pod and container
Description and security hardening suggestions for each failed item
To suppress a false positive, click Add to Whitelist next to the failed item.
To view the raw configuration, click the workload's YAML link.
Inspection reports
The Reports tab shows the results from the most recent inspection, including:
Overview: total inspection items, count and percentage of each resource type, and overall cluster health status
Category breakdown: results grouped by health checks, images, networks, resources, and security conditions
Workload details: resource category, name, namespace, inspection type, inspection item, and result for each workload configuration
Handle inspection alerts
When the inspection feature finds security risks, it emits the following events:
| Event type | Event name | Example content | Description | Action |
|---|---|---|---|---|
| Normal | SecurityInspectorConfigAuditStart | Start to running config audit | Inspection started | None required |
| Normal | SecurityInspectorConfigAuditFinished | Finished running once config audit | Inspection completed | None required |
| Warning | SecurityInspectorConfigAuditHighRiskFound | 2 high risks have been found after running config audit | Security risks detected | See steps below |
When you receive a SecurityInspectorConfigAuditHighRiskFound warning:
Go to the Inspections tab of the Inspections page.
Use the Passed or Failed, Namespace, and Workload Type filters to locate the affected workloads.
Click Details to review each failed item.
To ignore an acceptable risk, click Add to Whitelist.
To fix a risk, follow the security hardening suggestion in the Details view.
Inspection items
The inspection feature checks 17 items across four security categories.
Host isolation
These checks detect pod configurations that break namespace isolation between containers and the host.
| Item ID | Item | Triggered when | Risk | Fix |
|---|---|---|---|---|
| hostNetworkSet | Disable sharing of network namespaces between containers and hosts | hostNetwork: true is set | Containers can attack the host network and sniff host network traffic | Delete the hostNetwork field from the pod spec |
| hostIPCSet | Disable sharing of IPC namespaces between containers and hosts | hostIPC: true is set | Containers can attack host processes and sniff inter-process communication (IPC) data | Delete the hostIPC field from the pod spec |
| hostPIDSet | Disable sharing of PID namespaces between containers and hosts | hostPID: true is set | Containers can attack host processes and collect process ID (PID) data | Delete the hostPID field from the pod spec |
| hostPortSet | Prevent processes in containers from listening on host ports | hostPort field is set | The host port can be occupied without authorization; the container port may receive unexpected requests | Delete the hostPort field from the pod spec |
Privilege control
These checks detect configurations that grant containers elevated privileges, the most common path for container breakouts.
| Item ID | Item | Triggered when | Risk | Fix |
|---|---|---|---|---|
| runAsRootAllowed | Disable container startup as a root user | runAsNonRoot: true is not set | Malicious processes can intrude into your applications, hosts, or cluster | Add runAsNonRoot: true to the pod spec |
| runAsPrivileged | Disable container startup in privileged mode | privileged: true is set | Malicious processes can intrude into your applications, hosts, or cluster | Delete the privileged field from the pod spec |
| privilegeEscalationAllowed | Disable privilege escalation for child processes in containers | allowPrivilegeEscalation: false is not set | Malicious processes can gain escalated privileges and perform unauthorized operations | Add allowPrivilegeEscalation: false to the pod spec |
| capabilitiesAdded | Disable unnecessary Linux capabilities | capabilities field includes SYS_ADMIN, NET_ADMIN, ALL, or other capabilities | Malicious processes can intrude into applications, cluster components, or the cluster | Remove all unnecessary Linux capabilities; keep only the minimum required set |
| notReadOnlyRootFileSystem | Enable the read-only mode for file systems in containers | readOnlyRootFilesystem: true is not set | Malicious processes can modify the root file system | Add readOnlyRootFilesystem: true to the pod spec. For directories that need write access, set the volumeMounts field |
Resource governance
These checks detect missing CPU and memory constraints. Pods without requests may be scheduled onto nodes with insufficient resources. Pods without limits can consume all node resources, triggering OOM kills or node-level evictions that affect other workloads.
| Item ID | Item | Triggered when | Risk | Fix |
|---|---|---|---|---|
| cpuRequestsMissing | Set the minimum usage of CPU resources available for running containers | resources.requests.cpu is not set | Pod may be scheduled to a node with insufficient CPU, causing slow processes | Add resources.requests.cpu to the pod spec |
| cpuLimitsMissing | Set the maximum amount of CPU resources available for running containers | resources.limits.cpu is not set | Abnormal processes can consume excessive CPU or exhaust node CPU resources | Add resources.limits.cpu to the pod spec |
| memoryRequestsMissing | Set the minimum memory resources available for running containers | resources.requests.memory is not set | Pod may be scheduled to a node with insufficient memory, causing processes to be terminated by the OOM killer | Add resources.requests.memory to the pod spec |
| memoryLimitsMissing | Set the maximum memory resources available for running containers | resources.limits.memory is not set | Abnormal processes can consume excessive memory or exhaust the memory resources of the node or cluster | Add resources.limits.memory to the pod spec |
Image integrity and service reliability
These checks detect configuration gaps that can cause service disruptions.
| Item ID | Item | Triggered when | Risk | Fix |
|---|---|---|---|---|
| readinessProbeMissing | Configure container readiness probes | readinessProbe field is not set | Requests are sent to containers that are not yet ready to process them, causing service errors | Add a readinessProbe to the pod spec |
| livenessProbeMissing | Configure container liveness probes | livenessProbe field is not set | Application failures that require a container restart go undetected, interrupting the service | Add a livenessProbe to the pod spec |
| tagNotSpecified | Specify image versions for containers | image field has no version tag or is set to latest | Containers may pull an unintended image version, causing service disruptions | Set an explicit version tag in the image field (not latest) |
| anonymousUserRBACBinding | Prohibit anonymous access to cluster | RBAC role bindings allow access from anonymous users | Anonymous users can access sensitive information and attack or intrude into the cluster | Remove anonymous user entries from RBAC role bindings |
What's next
To further strengthen pod security, configure pod security policies. See Configure pod security policies.
To identify broader cluster-level risks such as insufficient resource quotas or high resource watermarks, use the cluster inspection feature. See Work with the cluster inspection feature.