All Products
Search
Document Center

Container Service for Kubernetes:Scan workload configuration risks

Last Updated:Mar 26, 2026

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

  1. Log on to the ACK console. In the left navigation pane, click Clusters.

  2. On the Clusters page, click the name of the target cluster. In the left-side pane, choose Security > Inspections.

  3. (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.

  4. 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.

    Important

    Run inspections during off-peak hours to reduce impact on running workloads.

  5. 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 typeEvent nameExample contentDescriptionAction
NormalSecurityInspectorConfigAuditStartStart to running config auditInspection startedNone required
NormalSecurityInspectorConfigAuditFinishedFinished running once config auditInspection completedNone required
WarningSecurityInspectorConfigAuditHighRiskFound2 high risks have been found after running config auditSecurity risks detectedSee steps below

When you receive a SecurityInspectorConfigAuditHighRiskFound warning:

  1. Go to the Inspections tab of the Inspections page.

  2. Use the Passed or Failed, Namespace, and Workload Type filters to locate the affected workloads.

  3. 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 IDItemTriggered whenRiskFix
hostNetworkSetDisable sharing of network namespaces between containers and hostshostNetwork: true is setContainers can attack the host network and sniff host network trafficDelete the hostNetwork field from the pod spec
hostIPCSetDisable sharing of IPC namespaces between containers and hostshostIPC: true is setContainers can attack host processes and sniff inter-process communication (IPC) dataDelete the hostIPC field from the pod spec
hostPIDSetDisable sharing of PID namespaces between containers and hostshostPID: true is setContainers can attack host processes and collect process ID (PID) dataDelete the hostPID field from the pod spec
hostPortSetPrevent processes in containers from listening on host portshostPort field is setThe host port can be occupied without authorization; the container port may receive unexpected requestsDelete 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 IDItemTriggered whenRiskFix
runAsRootAllowedDisable container startup as a root userrunAsNonRoot: true is not setMalicious processes can intrude into your applications, hosts, or clusterAdd runAsNonRoot: true to the pod spec
runAsPrivilegedDisable container startup in privileged modeprivileged: true is setMalicious processes can intrude into your applications, hosts, or clusterDelete the privileged field from the pod spec
privilegeEscalationAllowedDisable privilege escalation for child processes in containersallowPrivilegeEscalation: false is not setMalicious processes can gain escalated privileges and perform unauthorized operationsAdd allowPrivilegeEscalation: false to the pod spec
capabilitiesAddedDisable unnecessary Linux capabilitiescapabilities field includes SYS_ADMIN, NET_ADMIN, ALL, or other capabilitiesMalicious processes can intrude into applications, cluster components, or the clusterRemove all unnecessary Linux capabilities; keep only the minimum required set
notReadOnlyRootFileSystemEnable the read-only mode for file systems in containersreadOnlyRootFilesystem: true is not setMalicious processes can modify the root file systemAdd 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 IDItemTriggered whenRiskFix
cpuRequestsMissingSet the minimum usage of CPU resources available for running containersresources.requests.cpu is not setPod may be scheduled to a node with insufficient CPU, causing slow processesAdd resources.requests.cpu to the pod spec
cpuLimitsMissingSet the maximum amount of CPU resources available for running containersresources.limits.cpu is not setAbnormal processes can consume excessive CPU or exhaust node CPU resourcesAdd resources.limits.cpu to the pod spec
memoryRequestsMissingSet the minimum memory resources available for running containersresources.requests.memory is not setPod may be scheduled to a node with insufficient memory, causing processes to be terminated by the OOM killerAdd resources.requests.memory to the pod spec
memoryLimitsMissingSet the maximum memory resources available for running containersresources.limits.memory is not setAbnormal processes can consume excessive memory or exhaust the memory resources of the node or clusterAdd resources.limits.memory to the pod spec

Image integrity and service reliability

These checks detect configuration gaps that can cause service disruptions.

Item IDItemTriggered whenRiskFix
readinessProbeMissingConfigure container readiness probesreadinessProbe field is not setRequests are sent to containers that are not yet ready to process them, causing service errorsAdd a readinessProbe to the pod spec
livenessProbeMissingConfigure container liveness probeslivenessProbe field is not setApplication failures that require a container restart go undetected, interrupting the serviceAdd a livenessProbe to the pod spec
tagNotSpecifiedSpecify image versions for containersimage field has no version tag or is set to latestContainers may pull an unintended image version, causing service disruptionsSet an explicit version tag in the image field (not latest)
anonymousUserRBACBindingProhibit anonymous access to clusterRBAC role bindings allow access from anonymous usersAnonymous users can access sensitive information and attack or intrude into the clusterRemove anonymous user entries from RBAC role bindings

What's next

References