This topic describes the security system of Container Service for Kubernetes (ACK) from the following three dimensions: runtime security, trusted software supply chains, and infrastructure security. The security system is supported by a variety of features provided by ACK, including security inspection, policy management, runtime monitoring and alerting, image scanning, image signing, cloud-native application delivery chain, default security, identity management, and fine-grained access control.
Runtime security
Security inspection
Developers must follow the principle of least privilege when they configure pod templates. Otherwise, attackers can exploit unnecessary pod permissions that are granted to users to launch escape attacks against containers. ACK supports security inspections for runtimes. This allows you to inspect pod configurations of running applications and check potential risks in real time.
An inspection report is generated after a security inspection is performed. The report includes the description of each inspection item and suggestions on how to fix security issues. You can also configure periodic inspections. The results of each periodic inspection are logged to the specified Logstore in Simple Log Service. For more information, see Use the inspection feature to detect security risks in the workloads of an ACK cluster.
Policy management
ACK uses Open Policy Agent (OPA) as a Gatekeeper admission controller to provide extended features such as policy governance status monitoring, log collection, and log retrieval. In addition, a variety of policy libraries are preinstalled to provide more security policies that are applicable to Kubernetes scenarios. You can configure security policies in the ACK console in a visualized manner, which greatly simplifies policy governance configuration. For more information, see Configure pod security policies.
The policy management feature of ACK helps automatically block risky applications during application deployments for security O&M engineers. This improves application security and reduces communication and learning costs for application development and O&M teams in enterprises.
Runtime monitoring and alerting
Cloud-native applications are deployed in containers after they pass the authentication and admission control of the API server. However, in accordance with the zero trust principle for application security, monitoring and alerting are required to ensure the security of application runtimes. Therefore, ACK is deeply integrated with the alerting and vulnerability detection capabilities of Security Center. This allows cluster administrators to monitor application runtimes and receive alerts upon security events. Runtime monitoring and alerting are used to prevent the following attacks that are launched against containers:
Loading of malicious images
Implanting of viruses and malicious programs
Intrusion into containers
Container escapes and high-risk operations
To view the received alerts in real time and deal with alerts, go to the cluster details page in the ACK console. In the left-side pane, choose . For more information, see Use security monitoring.
Sandboxed containers
A sandboxed container is an alternative to the Docker runtime that allows you to run applications in a sandboxed and lightweight virtual machine with a dedicated kernel. This enhances resource isolation and improves security.
Sandboxed containers are applicable to scenarios such as untrusted application isolation, fault isolation, performance isolation, and workload isolation among multiple users. Sandboxed containers provide enhanced security, have minor impacts on application performance, and offer the same user experience as Docker in terms of logging, monitoring, and elastic scaling. For more information, see Overview of Sandboxed-Container.
TEE-based confidential computing
ACK provides trusted execution environment (TEE)-based confidential computing, which is a cloud-native and all-in-one solution based on hardware encryption technologies. TEE-based confidential computing ensures data security, integrity, and confidentiality. It simplifies the development and delivery of trusted or confidential applications and reduces the management costs of these applications.
Confidential computing allows you to isolate sensitive data and code in a TEE. This prevents the data and code from being accessed by the rest of the system. The data stored within TEEs is inaccessible to external applications, the BIOS, the operating system, the kernel, administrators, O&M engineers, cloud service providers, and hardware components except the CPU. This reduces the possibility of data leakage and simplifies data management. For more information, see TEE-based confidential computing.
Trusted software supply chains
Image scanning
Container Registry allows you to scan all Linux-based container images for known vulnerabilities. After you run a scan, you can receive a report that contains information about the detected vulnerabilities and suggestions on how to fix them. Image scanning helps you reduce the risks in container images. Container Registry is also integrated with the scan engine of Security Center. This engine can be used to detect system vulnerabilities, application vulnerabilities, and malicious samples in images.
Image signing
When you manage container images, you can use the content trust mechanism to verify that the images and their publishers are trusted. Image publishers can use digital signatures to sign images. The digital signatures are stored in Container Registry. You can verify the signatures of images to ensure that only images signed by trusted authorities are deployed. This reduces the risk of malicious code execution and ensures the security and traceability of container images from the software supply chain to application deployment. For more information about how to verify the signatures of container images, see Use kritis-validation-hook to automatically verify the signatures of container images.
Cloud-native application delivery chains
Container Registry provides the cloud-native application delivery chain feature that allows you to develop containerized applications with high security and efficiency. You can streamline tasks such as image building, image scanning, global image synchronization, and image deployment in a delivery chain. You can also customize fine-grained security policies. The way, the entire lifecycle of application development is secure, observable, and traceable. After you use a cloud-native application delivery chain, you need to only submit the code once for each application. The image is distributed and deployed across all regions worldwide in a secure and efficient manner. This updates the development pipeline from DevOps to DevSecOps. For more information, see Create a delivery chain.
Infrastructure security
Default security
In an ACK cluster, the security of nodes and components on the control plane is reinforced based on the security hardening feature. In addition, the configurations of all system components are reinforced by following the ACK best practices for security. No component image contains critical vulnerabilities that are identified by Common Vulnerabilities and Exposures (CVE).
Each newly created ACK cluster is assigned a security group that allows only inbound Internet Control Message Protocol (ICMP) packets from the Internet. By default, you cannot connect to an ACK cluster by using SSH over the Internet. For more information about how to connect to an ACK cluster by using SSH over the Internet, see Connect to the master nodes of an ACK dedicated cluster by using SSH.
You can enable Internet access for nodes in an ACK cluster by using NAT gateways. This secures Internet access and reduces security risks.
Worker nodes in a managed ACK cluster are assigned Resource Access Management (RAM) roles that are authorized by following the principle of least privilege. These RAM roles have only the minimum permissions on Alibaba Cloud resources. For more information, see [Product Changes] ACK reduces the permissions of worker RAM roles in managed Kubernetes clusters.
Identity management
The communication and data transmission between all components in an ACK cluster must be secured by using TLS-based authentication. In addition, ACK automatically renews the certificates of system components. You can log on to the ACK console or call the ACK API as a RAM user or by assuming a RAM role to obtain the kubeconfig file of the specified cluster. For more information, see Query the kubeconfig file of a cluster. The cluster credentials are maintained by ACK. If the cluster credentials in the returned kubeconfig file are leaked, you must immediately revoke the kubeconfig file. For more information, see Revoke the kubeconfig file of a cluster.
When you create an ACK cluster, you can enable service account token volume projection. This feature enhances the security when you use service accounts in applications. For more information, see Enable service account token volume projection.
Fine-grained access control
ACK provides fine-grained access control of Kubernetes resources in an ACK cluster based on role-based access control (RBAC). This is a basic but essential reinforcement for application security. On the Authorizations page in the ACK console, you can grant fine-grained permissions of a namespace to a RAM user or RAM role. This authorization method provides the following benefits:
Provides the following predefined RBAC roles: administrator, O&M engineer, developer, and restricted user. This allows you to easily grant permissions to employees in hierarchical departments of an enterprise.
Allows you to grant permissions on multiple clusters or authorize multiple RAM users at a time.
Allows you to authorize a RAM user to be assumed by a RAM role.
Allows you to assign custom cluster roles.
For more information, see Grant RBAC permissions to RAM users or RAM roles.
You can install the gatekeeper component on the Add-ons page in the ACK console. This component provides fine-grained access control by using the OPA policy engine. For more information, see gatekeeper.
Auditing
ACK is deeply integrated with Simple Log Service. You can collect, retrieve, and visualize the following types of audit logs:
The audit logs of the API server of a cluster. This type of audit logs records the operations that are performed by users when they access the cluster. You can check the audit logs to trace each operation. This is a key component to maintain clusters in a secure way. On the Cluster Auditing page, you can view a variety of auditing reports and configure alerting for operations that are performed on specific resource types based on the log content. For more information, see Work with cluster auditing.
The audit logs of Ingress traffic. Multiple visualized traffic reports are provided to show the status of Ingresses in a cluster. The reports provide information such as the page views (PVs) and unique visitors (UVs) of services, ratios of request successes and failures, and latency. Exceptions can also be automatically detected by using the machine learning algorithms provided by Simple Log Service and time series analysis algorithms. For more information, see Analyze and monitor the access log of nginx-ingress-controller.
The audit logs of event monitoring. Event monitoring records cluster events in the audit logs. You can diagnose exceptions and security risks in a cluster based on these events. For more information, see Event monitoring.
Secret encryption
Kubernetes Secrets are encoded in Base64 when they are stored in etcd. To further reinforce the security of the stored Kubernetes Secrets, you can use keys that are created in Key Management Service (KMS) to encrypt Secrets of ACK Pro clusters. For more information, see Use KMS to encrypt Kubernetes Secrets.