Check the security configuration of cluster workloads - Container Service for Kubernetes

ACK provides the inspection feature to scan your cluster workloads for security risks in their configuration. After an inspection task runs, the system generates an inspection report. You can use the report to view and address risk items and monitor the health status of your workloads in real time.

Prerequisites

The cluster runs Kubernetes v1.14 or later. To upgrade your cluster, see Manually update an ACK cluster.
If you are a RAM user, complete the RAM authorization and RBAC authorization as described in the following sections.
- RAM authorization
  Complete the RAM authorization on the Inspections page to ensure that the current RAM user has the permissions to use the Inspections page for the current cluster. Otherwise, you will have insufficient permissions and be unable to use the features on the Inspections page. For more information, see Grant permissions to access clusters and cloud resources by using RAM.
  Inspection 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 want to use the inspection report feature, you must grant the RAM user read permissions on the specified Simple Log Service (SLS) project. The project is used by the log collection component of your cluster. Otherwise, insufficient permissions will prevent you from viewing inspection reports. For more information, see Examples of custom RAM authorization.
  SLS log 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 the resources on the Inspections page to grant administrator permissions for the specified cluster to the RAM user. This ensures that the RAM user has the permissions to operate on the Kubernetes resources on the Inspections page. For more information, see Use RBAC to authorize operations on resources within a cluster.

Run an inspection

Log on to the ACK console. In the left navigation pane, click Clusters.
On the Clusters page, click the name of your cluster. In the left navigation pane, click Security > Inspections.
Optional: Follow the on-screen instructions to install or update the inspection component.
The security-inspector component is free of charge but consumes pod resources. For more information about the component and its release notes, see security-inspector.
Run an inspection.
Important
- We recommend running inspections during off-peak hours.
- By default, the inspection scans all supported items. In the upper-right corner of the Inspections page, you can click Configure Periodic Inspection to specify the items to scan. For more information, see Inspection items.
- To run an immediate inspection, in the upper-right corner of the Inspections page, click Inspect.
- To run periodic inspections, in the upper-right corner of the Inspections page, click Configure Periodic Inspection. Then, select Configure Periodic Inspection and configure the inspection period.
After the inspection is complete, on the Inspections tab, find the desired inspection result and click Details in the Actions column.

Inspection details

The Inspections page lists detailed inspection results for different workloads. The page provides 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 Risk Item for each workload.
View details for each inspection item, including the check status (Passed or Failed) at the pod and container levels, a detailed description, and remediation suggestions. If a failed item does not require remediation, you can add it to the whitelist.
View the YAML file of a workload.

Inspection reports

The Reports page displays the results of the most recent inspection. The page includes the following information:

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

Inspection items

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

Check ID	Check item	Description and security risk	Remediation
hostNetworkSet	Prevent containers from sharing the host network namespace	Checks whether `hostNetwork: true` is configured in the pod spec of a workload. If this setting is enabled, containers can access the host's network namespace, creating a risk of network attacks and data sniffing from within the pod.	Modify the pod spec to remove the `hostNetwork` field. Example: `labels: app: nginx spec: containers: - name: nginx image: nginx:1.14.2`
hostIPCSet	Prevent containers from sharing the host IPC namespace	Checks whether `hostIPC: true` is configured in the pod spec of a workload. If this setting is enabled, containers can access the host's IPC namespace, which allows them to attack or sniff data from other processes on the host.	Modify the pod spec to remove the `hostIPC` field. Example: `labels: app: nginx spec: containers: - name: nginx image: nginx:1.14.2`
hostPIDSet	Prevent containers from sharing the host PID namespace	Checks whether `hostPID: true` is configured in the pod spec of a workload. If this setting is enabled, containers can access the host's process ID (PID) namespace, which allows them to attack or collect data from other processes on the host.	Modify the pod spec to remove the `hostPID` field. Example: `labels: app: nginx spec: containers: - name: nginx image: nginx:1.14.2`
hostPortSet	Prevent container processes from listening on node ports	Checks whether `hostPort` is configured in the pod spec of a workload. If a container port is mapped to a port on the host node, it can occupy the host port and may receive requests from unintended sources.	Modify the pod spec to remove the `hostPort` field. Example: `spec: containers: - name: nginx image: nginx:1.14.2 ports: - containerPort: 80`
runAsRootAllowed	Prevent containers from running as the root user	Checks whether `runAsNonRoot: true` is configured in the pod spec of a workload. If this setting is not configured, containers run as the root user by default. This creates a risk of malicious processes compromising your applications, the host, or the entire cluster.	Modify the pod spec to add `runAsNonRoot: true`. Example: `spec: containers: - name: nginx image: nginx:1.14.2 ports: - containerPort: 80 securityContext: runAsNonRoot: true`
runAsPrivileged	Prevent containers from running in privileged mode	Checks whether `privileged: true` is configured in the pod spec of a workload. If this setting is enabled, the container has root access to the host. This creates a severe risk of malicious processes compromising your applications, the host, or the entire cluster.	Modify the pod spec to remove the `privileged` field. Example: `spec: containers: - name: nginx image: nginx:1.14.2 ports: - containerPort: 80 securityContext: {}`
privilegeEscalationAllowed	Prevent privilege escalation in containers	Checks whether `allowPrivilegeEscalation: false` is configured in the pod spec of a workload. If this setting is not configured, a child process in a container can gain more privileges than its parent process. This creates a risk of privilege escalation attacks.	Modify the pod spec to add the `allowPrivilegeEscalation: false` field. Example: `ports: - containerPort: 80 securityContext: allowPrivilegeEscalation: false readOnlyRootFilesystem: true runAsNonRoot: true volumeMounts:`
capabilitiesAdded	Drop unnecessary Linux capabilities	Checks the `capabilities` field in the pod spec of a workload for high-privilege Linux capabilities such as `SYS_ADMIN`, `NET_ADMIN`, or `ALL`. If these capabilities are granted, malicious processes can use them to compromise your applications, components, or cluster.	Modify the pod spec to add only the required Linux capabilities and drop all others. If no extra Linux capabilities are required, drop all of them. Example: `spec: containers: - name: nginx image: nginx:1.14.2 ports: - containerPort: 80 securityContext: capabilities: drop: - ALL` If specific capabilities are required, add only the necessary ones and drop all others. Example: `spec: containers: - name: nginx image: nginx:1.14.2 ports: - containerPort: 80 securityContext: capabilities: add: - CHOWN drop: - ALL`
notReadOnlyRootFilesystem	Use a read-only root filesystem for containers	Checks whether `readOnlyRootFilesystem: true` is configured in the pod spec of a workload. If this setting is not configured, the container's root filesystem is writable. This creates a risk of malicious processes modifying system files.	Modify the pod spec to add `readOnlyRootFilesystem: true`. If you need to write to a specific directory, use `volumeMounts`. 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, use a `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	Set CPU requests for containers	Checks whether `resources.requests.cpu` is configured in the pod spec of a workload. If this setting is not configured, pods may be scheduled to nodes with insufficient CPU resources, which can cause slow performance.	Modify the pod spec to add a `resources.requests.cpu` field. Example: `spec: containers: - name: nginx image: nginx:1.14.2 resources: requests: cpu: 100m`
cpuLimitsMissing	Set CPU limits for containers	Checks whether `resources.limits.cpu` is configured in the pod spec of a workload. If this setting is not configured, abnormal processes in a container may consume excessive node resources, potentially exhausting the CPU resources of the node or the entire cluster.	Modify the pod spec to add a `resources.limits.cpu` field. Example: `spec: containers: - name: nginx image: nginx:1.14.2 resources: requests: cpu: 100m limits: cpu: 100m`
memoryRequestsMissing	Set memory requests for containers	Checks whether `resources.requests.memory` is configured in the pod spec of a workload. If this setting is not configured, pods may be scheduled to nodes with insufficient memory, leading to out-of-memory (OOM) errors.	Modify the pod spec to add a `resources.requests.memory` field. Example: `spec: containers: - name: nginx image: nginx:1.14.2 resources: requests: cpu: 100m memory: 128Mi`
memoryLimitsMissing	Set memory limits for containers	Checks whether `resources.limits.memory` is configured in the pod spec of a workload. If this setting is not configured, abnormal processes in a container may consume excessive node resources, potentially exhausting the memory of the node or the entire cluster.	Modify the pod spec to add a `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`
readinessProbeMissing	Configure readiness probes for containers	Checks whether a `readinessProbe` is configured in the pod spec of a workload. Without a readiness probe, traffic may be sent to a container before it is ready to serve requests, which can cause application errors.	Modify the pod spec to add a `readinessProbe` field. Example: `spec: containers: - name: nginx image: nginx:1.14.2 readinessProbe: httpGet: path: /health port: 8080 initialDelaySeconds: 5 periodSeconds: 20`
livenessProbeMissing	Configure liveness probes for containers	Checks whether a `livenessProbe` is configured in the pod spec of a workload. Without a liveness probe, an unresponsive container is not automatically restarted, which can lead to application downtime.	Modify the pod spec to add a `livenessProbe` field. Example: `spec: containers: - name: nginx image: nginx:1.14.2 livenessProbe: httpGet: path: /health port: 8080 initialDelaySeconds: 5 periodSeconds: 20`
tagNotSpecified	Use a specific image tag for containers	Checks whether the `image` field in the pod spec of a workload lacks an image tag or uses the `latest` tag. If a specific image tag is not used, the workload might run an unexpected version of the container image, which can cause application errors.	Modify the `image` field in the pod spec to use a specific image tag. Do not use the `latest` tag. Example: `spec: containers: - name: nginx image: nginx:1.14.2`
anonymousUserRBACBinding	Prohibit anonymous user access to the cluster	Checks the Role-Based Access Control (RBAC) bindings in the cluster to find any configurations that grant access to anonymous users. If anonymous access is allowed, malicious users can steal sensitive information or attack the cluster.	Modify the RBAC bindings to remove any permissions that allow anonymous users to access cluster resources. Example: `- apiGroup: rbac.authorization.k8s.io kind: Group name: 'foo-group'`

Events

Event type	Event name	Content example	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	Found 2 high-risk items after config audit	After the inspection, unmitigated high-risk items were found in some workloads.	On the Inspections page of the cluster, go to the Inspections tab to view the detailed inspection results. Filter the results by Passed or Failed, Namespace, and Workload Type to identify the at-risk workloads. Click Details for a workload to view the results for each of its inspection items. For an item that you confirm does not need to be fixed, click Add to Whitelist. For an item that requires a fix, click Details and follow the remediation suggestion to fix the item.