Check workload security with configuration inspection - Container Compute Service

Container Compute Service (ACS) provides an inspection feature for workload configurations. This feature helps you scan your clusters for workload configuration security risks. After you run an inspection task, ACS generates an inspection report. You can use the report to view and handle failed items in your cluster and monitor the real-time health status of your cluster.

Prerequisites

You have created an ACS cluster.
If you use a RAM user, complete the required RAM authorization and RBAC authorization.
- RAM authorization
  
  Complete the RAM authorization on the ACS inspection page to grant the current RAM user permissions to operate on the page for the current cluster. Otherwise, you cannot use the features on the page due to insufficient permissions. For more information, see Grant RAM permissions to a RAM user or RAM role.
  Authorization policy
```
{
  "Statement": [
    {
      "Action": [
        "cs:DescribePolarisConfig",
        "cs:DescribePolarisJob",
        "cs:DescribePolarisCronJob",
        "cs:UpdatePolarisJob",
        "cs:UpdatePolarisCronJob"
      ],
      "Effect": "Allow",
      "Resource": [
        "acs:cs:*:*:cluster/<yourclusterID>"
      ]
    }
  ],
  "Version": "1"
}
```
  If you also need to use the inspection report feature, complete the RAM authorization for the logproject that is specified for Simple Log Service. This logproject is the one used by the logtail-ds component of the current cluster. This ensures that the current RAM user has permissions to read data from the logproject. Otherwise, you cannot view inspection reports due to insufficient permissions. For more information, see RAM Custom Authorization Examples.
  Log reading authorization policy
```
{
    "Version": "1",
    "Statement": [
        {
            "Action": [
                "log:Get*",
                "log:List*"
            ],
            "Resource": "acs:log:*:*:project/<your-project-name>/*",
            "Effect": "Allow"
        }
    ]
}
```
- RBAC authorization
  
  Complete the RBAC authorization for resources on the ACS inspection page. Grant the RAM user administrator permissions for a specified cluster to ensure that the RAM user has the permissions to manage the Kubernetes resources on the inspection page. For more information, see Configure RBAC authorization for a RAM user or RAM role.

Enable the cluster workload inspection feature

Log on to the ACS console. In the left navigation pane, click Clusters.
On the Clusters page, click the name of the target cluster. In the left navigation pane, choose Security > Inspections.
Optional: Install and update the inspection component.

If the inspection component is not installed, follow the on-screen prompts to install the security-inspector component. If the component is not up-to-date, follow the prompts to update it to the latest version. After the component is installed, you can also go to the Cluster Information page, select the Overview tab, and then click Security Inspection to open the Inspections page.

For more information about the security-inspector component and its change history, see security-inspector.
In the upper-right corner of the Inspections page, click Inspect. When the inspection finishes, go to the Inspections tab and click Details in the Actions column to view the results.

Important
To minimize the impact on cluster stability and availability, run inspections during off-peak hours.
Optional: In the upper-right corner of the Inspections page, click Configure Periodic Inspection to enable or disable automatic periodic inspections and configure the items to check.

Inspection details

The Inspections page displays detailed inspection results for different workloads in a tabular format and includes the following features:

Filter results by criteria such as Passed or Failed, Namespace, and Workload Type, and view the number of Number of Passed Items and Number of Failed Items for each workload.
View details for each inspection item, including the check status at the pod and container levels (passed or failed), a detailed description, and hardening recommendations. If a failed item does not require action, you can add it to the whitelist.
View the YAML file of a workload.

Inspection report

The inspection report shows the results of the most recent scan, including:

A scan overview, including the total number of items checked, the number and percentage of checked resources, and the overall health score.
Statistics by category, including results for health checks, images, networking, resources, and security.
Detailed scan results for each workload configuration, including resource type, resource name, namespace, check type, inspection item, and check result.

Inspection items

The configuration inspection feature scans for and displays the results for the following inspection items.

Inspection item	Description	Remediation
hostNetworkSet	Check the Pod Spec of the workload for the `hostNetwork: true` setting to determine if the Pod shares the host's network namespace. If this setting is enabled, there is a risk that containers in the Pod can attack the host network or sniff host network data.	Modify the Pod Spec and delete the `hostNetwork` field. Example: `labels: app: nginx spec: - hostNetwork: true containers: - name: nginx image: nginx:1.14.2`
hostIPCSet	Check if a workload shares the host's IPC namespace by inspecting its Pod Spec for the `hostIPC: true` setting. If this setting is enabled, it poses a risk that containers in the Pod can attack processes on the host or sniff their data.	Modify the Pod Spec and remove the `hostIPC` field. Example: `labels: app: nginx spec: - hostIPC: true containers: - name: nginx image: nginx:1.14.2`
hostPIDSet	Determine if the host's PID namespace is shared by checking if `hostPID: true` is configured in the Pod Spec of the workload. If this setting is configured, there is a risk that containers in the Pod can attack or collect data from host processes.	Modify the Pod Spec and remove the `hostPID` field. Example: `labels: app: nginx spec: - hostPID: true containers: - name: nginx image: nginx:1.14.2`
hostPortSet	By checking the `hostPort` parameter in the Pod Spec of a workload, you can determine if a container's listening port is mapped to a specific port on the host. This configuration poses a risk of consuming available host ports and allowing the container port to be accessed by unintended requesters.	Modify the Pod Spec and remove the `hostPort` field. Example: `spec: containers: - name: nginx image: nginx:1.14.2 ports: - containerPort: 80 - hostPort: 80`
runAsRootAllowed	Check if a container is allowed to run as the root user by verifying that `runAsNonRoot: true` is not configured in the Pod Spec of the workload. If this setting is not configured, there is a risk that malicious processes in the container can compromise the user application, the host, or even the entire cluster.	Modify the Pod spec and add `runAsNonRoot: true`. Example: `spec: containers: - name: nginx image: nginx:1.14.2 ports: - containerPort: 80 + securityContext: + runAsNonRoot: true`
runAsPrivileged	Check the Pod spec of the workload to determine if `privileged: true` is configured, which allows a container to run in privileged mode. If this setting is configured, there is a risk that a malicious process in the container can compromise user applications, the host, or even the cluster.	Modify the Pod Spec and delete the `privileged` field. Example: `spec: containers: - name: nginx image: nginx:1.14.2 ports: - containerPort: 80 securityContext: - privileged: true`
privilegeEscalationAllowed	Check if `allowPrivilegeEscalation: false` is configured in the Pod Spec of the workload. This setting prevents child processes in a container from gaining more privileges than their parent process. If this setting is not configured, a malicious process in the container may escalate its privileges.	Modify the Pod spec to add the `allowPrivilegeEscalation: false` field. Example: `ports: - containerPort: 80 securityContext: + allowPrivilegeEscalation: false readOnlyRootFilesystem: true runAsNonRoot: true volumeMounts:`
capabilitiesAdded	Check the `capabilities` field in the Pod spec of the workload to see if privileged Linux capabilities such as SYS_ADMIN, NET_ADMIN, or ALL are configured. If they are, there is a risk that a malicious process in the container could use these privileges to compromise user applications, or compromise or disrupt components or the cluster.	Modify the pod spec to add only the necessary Linux capabilities and remove all others. If no extra Linux capabilities are needed, remove all unnecessary ones. Example: `spec: containers: - name: nginx image: nginx:1.14.2 ports: - containerPort: 80 securityContext: capabilities: - add: - - SYS_ADMIN - - NET_ADMIN - - KILL + drop: + - ALL` Add only required Linux capabilities and remove all unnecessary ones. Example: `spec: containers: - name: nginx image: nginx:1.14.2 ports: - containerPort: 80 securityContext: capabilities: add: - - SYS_ADMIN - - NET_ADMIN - - KILL + - CHOWN + drop: + - ALL`
notReadOnlyRootFileSystem	Check the Pod Spec of the workload to determine if `readOnlyRootFilesystem: true` is not configured. If this setting is not configured, the container's root filesystem is writable. This poses a risk that malicious processes within the container can modify system files.	Modify the Pod Spec and add `readOnlyRootFilesystem: true`. Example: `spec: containers: - name: nginx image: nginx:1.14.2 ports: - containerPort: 80 securityContext: + readOnlyRootFilesystem: true` If you need to modify files in a specific directory, you can use the `volumeMounts` field. Example: `spec: containers: - name: nginx image: nginx:1.14.2 ports: - containerPort: 80 securityContext: + readOnlyRootFilesystem: true runAsNonRoot: true + volumeMounts: + - mountPath: /path/to/write + name: writeable + volumes: + - emptyDir: {} + name: writeable`
cpuRequestsMissing	You can check if the minimum required CPU resources for a container are specified by inspecting the `resources.requests.cpu` field in the Pod Spec of the workload. If this field is not specified, the Pod is at risk of being scheduled to a resource-constrained node, and processes inside the container may run slowly.	Modify the Pod Spec and add the `resources.requests.cpu` field. Example: `spec: containers: - name: nginx image: nginx:1.14.2 + resources: + requests: + cpu: 100m ports:`
cpuLimitsMissing	Check if the `resources.limits.cpu` field is configured in the Pod Spec of the workload. If this field is not configured, an abnormal process within a container can consume a large amount of node resources, which poses a risk of exhausting the resources of the entire node or even the cluster.	Modify the Pod Spec and add the `resources.limits.cpu` field. Example: `spec: containers: - name: nginx image: nginx:1.14.2 resources: requests: cpu: 100m + limits: + cpu: 100m ports:`
memoryRequestsMissing	Check if the `resources.requests.memory` field is configured in the Pod Spec of the workload. If this field is not configured, the Pod is at risk of being scheduled on a resource-constrained node, which may cause processes in the container to encounter an Out of Memory (OOM) error.	Modify the Pod Spec and add the `resources.requests.memory` field. Example: `spec: containers: - name: nginx image: nginx:1.14.2 resources: requests: cpu: 100m + memory: 128Mi limits:`
memoryLimitsMissing	Check if the `resources.limits.memory` field is configured in the Pod Spec of the workload. If this field is not configured, no maximum memory limit is set for the container. This poses a risk that an abnormal process within the container can consume a large amount of node resources and even exhaust the resources of the entire node or cluster.	Modify the Pod Spec and add the `resources.limits.memory` field. Example: `spec: containers: - name: nginx image: nginx:1.14.2 resources: requests: cpu: 100m memory: 128Mi limits: cpu: 100m + memory: 128Mi ports:`
readinessProbeMissing	If the `readinessProbe` field is not configured in the Pod Spec of a workload, no probe is available to check if the application in the container can handle requests. This creates a risk that requests will continue to be sent to the container even when the application is malfunctioning, which can cause service disruptions.	Modify the Pod Spec and add the `readinessProbe` field. Example: `spec: containers: - name: nginx image: nginx:1.14.2 + readinessProbe: + httpGet: + path: /health + port: 8080 + initialDelaySeconds: 5 + periodSeconds: 20 resources:`
livenessProbeMissing	This check verifies whether a `livenessProbe` is configured in the Pod Spec of a workload. A liveness probe is used to detect if the application in a container is abnormal and needs to be restarted. If this probe is not configured, there is a risk of service exceptions because the container will not be restarted in a timely manner to recover from an application failure.	Modify the Pod Spec and add the `livenessProbe` field. Example: `spec: containers: - name: nginx image: nginx:1.14.2 + livenessProbe: + httpGet: + path: /health + port: 8080 + initialDelaySeconds: 5 + periodSeconds: 20 readinessProbe:`
tagNotSpecified	Through checking if the value of the `image` field in the Pod Spec of a workload does not contain an image tag or uses `latest` as the image tag, you can check if the container is configured to run with a container image that has a specified tag. If a specified tag is not configured, an unexpected version of the container image may be run when the container starts, which poses a risk of service abnormalities.	Modify the `image` field in the Pod Spec. Use a specific image tag and do not use `latest` as the image tag. Example: `spec: containers: - name: nginx - image: nginx:latest + image: nginx:1.14.2 livenessProbe:`
anonymousUserRBACBinding	Checks the Role-based access control (RBAC) bindings in the cluster for configurations that grant access to anonymous users. If anonymous access to cluster resources is allowed, anonymous users could steal sensitive information or attack and compromise the cluster.	Modify the identified RBAC bindings to remove permissions that allow anonymous users to access cluster resources. Example: `- apiGroup: rbac.authorization.k8s.io kind: Group name: 'foo-group' - - apiGroup: rbac.authorization.k8s.io - kind: User - name: 'system:anonymous' - - apiGroup: rbac.authorization.k8s.io - kind: Group - name: 'system:unauthenticated'`

Events

Type	Name	Example message	Description	Actions
Normal	SecurityInspectorConfigAuditStart	Starting config audit	The inspection task starts.	No action is required.
Normal	SecurityInspectorConfigAuditFinished	Config audit finished	The inspection task is complete.	No action is required.
Warning	SecurityInspectorConfigAuditHighRiskFound	Config audit found 2 high risks	The inspection found unresolved high-risk items in one or more workloads.	On the Inspections page of your cluster, view the detailed inspection results. Use the Failed, All Namespaces, and Show All Workloads filter options to locate the affected workloads. Then, click Details to view the check results and remediation recommendations for each item. For items that you confirm do not require remediation, click Add to Whitelist. For items that require remediation, follow the provided recommendations.