在 Autopilot 模式下，GKE 會使用許可控制器強制執行 Pod 安全性限制。我們強制執行預設安全政策，其中包含 Pod 安全性標準基準層級的所有建議，並針對可用性進行部分修改。此外，Autopilot 的預設許可政策會強制執行 Pod 安全性標準受限制等級的許多限制，但會避免導致大多數工作負載無法執行的限制。
您可以在 Autopilot 中建立 CertificateSigningRequests，以建立由叢集憑證授權單位簽署的憑證。為避免干擾系統元件，Autopilot 會拒絕已知特殊權限身分的 CertificateSigningRequests，例如系統群組、系統代理程式或 Google 管理的 IAM 服務代理程式。
[[["容易理解","easyToUnderstand","thumb-up"],["確實解決了我的問題","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["難以理解","hardToUnderstand","thumb-down"],["資訊或程式碼範例有誤","incorrectInformationOrSampleCode","thumb-down"],["缺少我需要的資訊/範例","missingTheInformationSamplesINeed","thumb-down"],["翻譯問題","translationIssue","thumb-down"],["其他","otherDown","thumb-down"]],["上次更新時間：2025-09-01 (世界標準時間)。"],[],[],null,["# GKE Autopilot security measures\n\nAutopilot\n\n*** ** * ** ***\n\nThis page describes the security features, configurations, and settings in\nGoogle Kubernetes Engine (GKE) Autopilot. GKE Autopilot clusters\nimplement many security configurations for you, which makes Autopilot the recommended way to\nrun GKE.\n\nThis page is intended for Security specialists who want to understand the\nsecurity restrictions that Google specifically applies to Autopilot\nclusters, and the security features that are available for use in\nAutopilot. To learn more about\ncommon roles and example tasks that we reference in Google Cloud content, see\n[Common GKE user roles and tasks](/kubernetes-engine/enterprise/docs/concepts/roles-tasks).\n\nBefore reading this page, ensure that you're familiar with the following:\n\n- [General overview of GKE security](/kubernetes-engine/docs/concepts/security-overview)\n- [General overview of Autopilot mode and Standard mode](/kubernetes-engine/docs/concepts/choose-cluster-mode)\n\nSecurity measures in Autopilot\n------------------------------\n\nAutopilot clusters enable and apply security best practices and\nsettings by default, including many of the recommendations in the security\noverview and in\n[Harden your cluster security](/kubernetes-engine/docs/how-to/hardening-your-cluster).\n\nIf you want recommended resources based on your use case, skip to\n[Security resources by use case](#use-case-resources). The following sections\ndescribe the security policies that Autopilot applies for you.\n\n### Enforcement of Kubernetes Pod Security Standards\n\nThe Kubernetes project has a set of security guidelines named the\n*Pod Security Standards* that define the following policies:\n\n- **Privileged**: No access restrictions. Not used in Autopilot.\n- **Baseline**: Prevents known privilege escalation pathways. Allows most workloads to run without significant changes.\n- **Restricted**: Highest level of security. Requires significant changes to most workloads.\n\nIn Autopilot mode, GKE enforces Pod security constraints\nby using admission controllers. We\nenforce a default security policy that includes all of the recommendations in\nthe Baseline level of the Pod Security Standards, with some modifications for\nusability. Additionally, the default admission policy\nfor Autopilot enforces many constraints from the Restricted level of\nthe Pod Security Standards, but avoids restrictions that would block a majority\nof your workloads from running.\n\nIf you need to apply additional restrictions to comply with the\nfull Restricted policy, you can optionally use the\n[PodSecurity admission controller](/kubernetes-engine/docs/how-to/podsecurityadmission)\nin specific namespaces.\n\nThe following table describes how the controls in the default Autopilot\nadmission policy compare to the controls in the Baseline\nand the Restricted levels of the Pod Security Standards. For descriptions of\neach control in this table, see the corresponding entry in\n[Pod Security Standards](https://kubernetes.io/docs/concepts/security/pod-security-standards/).\n\nWhen evaluating compliance, we considered how the constraints apply to your own\nworkloads. This excludes verified Google Cloud partner workloads and\nsystem workloads that require specific privileges to function.\n\n### Built-in security configurations\n\nGoogle applies many built-in security settings to Autopilot clusters\nbased on industry best practices and our expertise. The following table\ndescribes some of the security configurations that Autopilot applies\nfor you:\n\n### Security boundaries in Autopilot\n\nAutopilot provides access to the Kubernetes API but removes permissions\nto use some highly privileged Kubernetes features, such as privileged Pods. The\ngoal is to limit the ability to access, modify, or directly control the node\nvirtual machine (VM). Autopilot implements these restrictions to limit\nworkloads from having low-level access to the node VM, so that\nGoogle Cloud can offer full management of nodes, and a Pod-level\n[SLA](/kubernetes-engine/sla).\n| **Important:** The security boundary for GKE nodes is the single-tenant VM. The ability to access the node VM from Pods is not considered a security boundary for Autopilot. Any node-level access is inconsistent with the security goals of GKE Autopilot and is not supported. Google might remove any node-level access without notice.\n\nOur intent is to prevent unintended access to the node VM. We accept submissions\nto that effect through the\n[Google Vulnerability Reward Program (VRP)](https://www.google.com/about/appsecurity/reward-program/)\nand will reward reports at the discretion of the Google VRP reward panel.\n\nBy design, privileged users such as cluster administrators have full control of\nany GKE cluster. As a security best practice, we recommend that\nyou avoid granting powerful GKE or Kubernetes privileges widely\nand instead use namespace administrator delegation wherever possible as described in our\n[multi-tenancy guidance](/kubernetes-engine/docs/best-practices/enterprise-multitenancy).\n\nAutopilot provisions single-tenant VMs in your project for your\nexclusive use. On each individual VM, your Autopilot workloads might\nrun together, sharing a security-hardened kernel. Since the shared kernel\nrepresents a single security boundary, we recommend that if you require strong\nisolation, such as high-risk or untrusted workloads, run your workloads on\n[GKE Sandbox](/kubernetes-engine/docs/concepts/sandbox-pods) Pods to provide\nmulti-layer security protection.\n\nSecurity recommendations based on use case\n------------------------------------------\n\nThe following sections provide you with links and recommendations to plan,\nimplement, and manage the security of your Autopilot clusters depending\non your use case.\n\n### Plan cluster security\n\n### Authenticate and authorize\n\nAfter setting up your Autopilot clusters, you might need to\nauthenticate your users and applications to use resources such as the Kubernetes\nAPI or Google Cloud APIs.\n\n### Harden clusters and workloads\n\nIf you have specialized isolation or hardening requirements beyond the\npre-configured Autopilot measures, consider the following resources:\n\n### Monitor your security posture\n\nAfter setting up your clusters and deploying your workloads, you should set up\nand configure monitoring and logging so that you have observability over your\ncluster security posture. We recommend that you do all of the following:\n\n- Enroll your clusters in the [GKE security posture dashboard](/kubernetes-engine/docs/concepts/about-security-posture-dashboard) to audit workloads for concerns such as problematic security configurations or vulnerabilities in your container operating system packages and get actionable mitigation information.\n- Get notified about new security bulletins and upgrade events using [cluster notifications](/kubernetes-engine/docs/how-to/cluster-notifications).\n- Observe your clusters using the [GKE dashboard](/stackdriver/docs/solutions/gke/observing) in Cloud Monitoring or the [Observability tab](/kubernetes-engine/docs/how-to/view-observability-metrics) in GKE.\n- Learn how to [view](/stackdriver/docs/solutions/gke/using-logs) and [manage](/stackdriver/docs/solutions/gke/managing-logs) your GKE audit logs in Cloud Logging.\n\nWhat's next\n-----------\n\n- Read the [GKE security overview](/kubernetes-engine/docs/concepts/security-overview).\n- Read the [GKE hardening guide](/kubernetes-engine/docs/how-to/hardening-your-cluster).\n- Subscribe to [security bulletins](/anthos/clusters/docs/security-bulletins) and [release notes](/kubernetes-engine/docs/release-notes)."]]
