Security Architecture Overview

更新时间:
复制 MD 格式

ACK's security system spans three layers: runtime security, trusted software supply chains, and infrastructure security. Together, these layers protect your containerized workloads from build time through production.

61

What ACK secures for you:

  • Inspect running pod configurations and block policy violations before deployment

  • Monitor container runtimes and alert on threats in real time

  • Scan container images for vulnerabilities and enforce image signing

  • Harden cluster nodes, enforce least-privilege access, and encrypt Kubernetes Secrets

  • Audit every API server operation, Ingress request, and cluster event

Runtime security

Security inspection

Misconfigured pods are a primary attack vector. Overly permissive pod templates give attackers a foothold for container escape. ACK's security inspection feature scans running workloads against a set of security rules and reports configuration risks in real time.

Each inspection produces a report listing every flagged item with a description and remediation steps. Schedule periodic inspections to continuously track your risk posture—results are automatically logged to a Logstore in Simple Log Service (SLS) for historical analysis. For more information, see Use the inspection feature to detect security risks in the workloads of an ACK cluster.

Policy management

ACK integrates Open Policy Agent (OPA) as a Gatekeeper admission controller to enforce security policies across your cluster. The integration provides:

  • Policy libraries: Preinstalled Kubernetes-specific policy sets, ready to apply without authoring rules from scratch

  • Visualized configuration: Manage and monitor policy governance status directly in the ACK console

  • Log collection and log retrieval: Collect and retrieve policy governance logs for audit and analysis

  • Automated blocking: Risky workloads are rejected at admission time, before they reach your nodes

This reduces the burden on security O&M engineers and removes the need for manual audits of application deployments. For more information, see Enable the policy governance feature.

Runtime monitoring and alerting

Passing admission control doesn't mean a workload is safe throughout its lifetime. ACK integrates with Security Center's alerting and vulnerability detection engines to monitor application behavior after deployment. The integration detects and alerts on:

  • Loading of malicious images

  • Implanting of viruses and malicious programs

  • Intrusion into containers

  • Container escapes and high-risk operations

View and respond to alerts in real time from the cluster details page: go to Security > Security Monitoring in the left-side navigation pane. For more information, see Use security monitoring.

Sandboxed containers

For workloads that require stronger isolation—such as untrusted third-party code, multi-tenant environments, or scenarios requiring fault and performance isolation—sandboxed containers are an alternative to the Docker runtime that run each application inside a lightweight virtual machine with a dedicated kernel. This prevents cross-container interference while maintaining the same operational experience as Docker for logging, monitoring, and elastic scaling. Sandboxed containers provide enhanced security and have minor impacts on application performance.

For more information, see Overview of Sandboxed-Container.

TEE-based confidential computing

For sensitive workloads where even the host OS, kernel, or cloud provider must not access application data, ACK provides trusted execution environment (TEE)-based confidential computing. This cloud-native and all-in-one solution based on hardware encryption technologies isolates code and data inside a TEE so they remain inaccessible to external applications, the BIOS, the OS, the kernel, administrators, O&M engineers, cloud service providers, and hardware components except the CPU.

TEE-based confidential computing ensures data security, integrity, and confidentiality throughout the workload lifecycle. 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

A vulnerability in a base image can compromise every container built on top of it. Container Registry scans all Linux-based container images for known vulnerabilities and produces a report with vulnerability details and fix recommendations. The scan engine is powered by Security Center, which detects system vulnerabilities, application vulnerabilities, and malicious samples embedded in images.

Image signing

Scanning identifies known vulnerabilities, but it doesn't verify who built an image. Image signing uses the content trust mechanism: publishers sign images with digital signatures stored in Container Registry, and ACK verifies those signatures at deployment time using the kritis-validation-hook component. Only images signed by trusted authorities are deployed—reducing the risk of malicious code execution and making the full pipeline from build to deployment auditable. For more information, see Use kritis-validation-hook to automatically verify the signatures of container images.

Cloud-native application delivery chain

Container Registry's cloud-native application delivery chain feature brings image building, scanning, global synchronization, and deployment into a single, automated pipeline with customizable security policies at each stage. Submit code once and the resulting image is distributed and deployed across all regions worldwide in a secure, traceable manner—shifting your pipeline from DevOps to DevSecOps. For more information, see Create a delivery chain.

Infrastructure security

Default security

ACK applies security hardening to all nodes and control plane components before they reach your cluster. The hardening baseline covers:

  • Component images: No component image ships with critical CVE (Common Vulnerabilities and Exposures) vulnerabilities

  • Network defaults: Each new cluster is assigned a security group that allows only inbound Internet Control Message Protocol (ICMP) traffic from the internet; SSH access over the internet is disabled by default. To enable SSH access when needed, see Connect to the master nodes of an ACK dedicated cluster by using SSH

  • Internet access: Route outbound internet traffic through NAT gateways to avoid exposing node IP addresses

  • Worker node permissions: Worker nodes in managed ACK clusters are assigned RAM roles with only the minimum permissions required—following the principle of least privilege. For more information, see \[Product Changes\] ACK reduces the permissions of worker RAM roles in managed Kubernetes clusters

Identity management

All communication between ACK cluster components is secured with Transport Layer Security (TLS)-based authentication. ACK automatically renews the certificates of system components, so you don't need to manage certificate lifecycles manually.

To access a cluster, log in to the ACK console or call the ACK API as a RAM user or by assuming a RAM role to retrieve the kubeconfig file. For more information, see Query the kubeconfig file of a cluster. If a kubeconfig file is compromised, revoke it immediately. For more information, see Revoke the kubeconfig file of a cluster.

When creating a cluster, enable service account token volume projection to strengthen how applications authenticate using service accounts. For more information, see Use ServiceAccount token volume projection.

Fine-grained access control

ACK enforces Kubernetes resource permissions through role-based access control (RBAC), managed on the Authorizations page in the ACK console. Key capabilities include:

  • Predefined roles: administrator, O&M engineer, developer, and restricted user—covering common permission profiles in enterprise teams

  • Batch authorization: Grant permissions across multiple clusters or authorize multiple RAM users in a single operation

  • Role assumption: Authorize a RAM user to assume a RAM role

  • Custom roles: Define cluster roles tailored to your organization's requirements

For more information, see Use RBAC to manage the operation permissions on resources in a cluster.

For policy-based access control beyond RBAC, install the Gatekeeper component from the Add-ons page. Gatekeeper uses the OPA policy engine to enforce fine-grained admission policies. For more information, see gatekeeper.

Auditing

ACK integrates with Simple Log Service to collect, index, and visualize three categories of audit logs:

  • API server audit logs (Cluster Auditing page): Every operation a user or system performs against the cluster API is recorded. Use these logs to trace the origin of any change. Configure alerts based on resource type or operation pattern to detect anomalies early. For more information, see Work with cluster auditing.

  • Ingress traffic audit logs: Visualized reports show page views (PVs), unique visitors (UVs), request success and failure ratios, and latency for your cluster's Ingress traffic. Machine learning algorithms and time series analysis automatically detect anomalies. For more information, see Analyze and monitor the access log of nginx-ingress-controller.

  • Event monitoring audit logs: Cluster events are recorded and queryable, helping you diagnose exceptions and security risks. For more information, see Event monitoring.

Secret encryption

Kubernetes Secrets are Base64-encoded when stored in etcd—Base64 is encoding, not encryption. To encrypt Secrets at rest, use Key Management Service (KMS) keys to encrypt Secrets in ACK Pro clusters. For more information, see Use KMS to encrypt Kubernetes Secrets.