[[["容易理解","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-07-31 (世界標準時間)。"],[],[],null,["# Security\n\nThis page describes the security features included in\nGKE on AWS, including each layer of its infrastructure, and\nhow you can configure security features to suit your needs.\n\nOverview\n--------\n\nGKE on AWS offers several features to help secure your [workloads](/kubernetes-engine/docs/how-to/deploying-workloads-overview),\nincluding the contents of your container image, the container runtime, the\ncluster network, and access to the cluster API server.\n\nIt's best to take a layered approach to protecting your clusters and workloads.\nYou can apply the [principle of least privilege](https://en.wikipedia.org/wiki/Principle_of_least_privilege) to the level of\naccess you provide to your users and workloads. You might need to make tradeoffs\nto allow the right level of flexibility and security.\n\nShared responsibilities\n-----------------------\n\nWhen you use GKE on AWS, you agree to take on certain\nresponsibilities for your clusters. For more information, see\n[GKE clusters shared responsibilities](/anthos/docs/concepts/gke-shared-responsibility).\n\nAuthentication and authorization\n--------------------------------\n\nYou authenticate to an GKE on AWS user cluster through one of the\nfollowing methods:\n\n- Using the [`anthos-gke`](/kubernetes-engine/multi-cloud/docs/aws/previous-generation/how-to/creating-user-cluster#authenticate) tool.\n- Using a Kubernetes Service Account token with the [Google Cloud console](/kubernetes-engine/multi-cloud/docs/aws/previous-generation/how-to/connecting-to-a-cluster).\n- Using [Open-ID Connect (OIDC)](/kubernetes-engine/multi-cloud/docs/aws/previous-generation/how-to/oidc).\n\nTo configure more granular access to Kubernetes resources at the cluster level\nor within Kubernetes namespaces, you use Kubernetes\n[Role-based access control (RBAC)](/kubernetes-engine/docs/how-to/role-based-access-control).\nRBAC lets you create detailed policies to define which operations and\nresources you allow users and service accounts to access. With RBAC, you\ncan control access for any validated identity provided.\n\nTo further simplify and streamline your authentication and\nauthorization strategy for Kubernetes Engine, GKE on AWS disables\n[Legacy attribute-based access Control (ABAC)](/kubernetes-engine/docs/reference/rest/v1/projects.zones.clusters#LegacyAbac).\n\nEncryption\n----------\n\nBy default, GKE on AWS encrypts\n[data in `etcd` at rest](https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/), EBS volumes, Kubernetes Secrets, and\n[control plane components](#control-plane) with the\n[AWS Key Management Service (KMS)](https://aws.amazon.com/kms/).\n\nTo encrypt sensitive data in your user clusters, you can use one of the\nfollowing:\n\n- Kubernetes Secrets\n- [Hashicorp Vault](/kubernetes-engine/multi-cloud/docs/aws/previous-generation/how-to/secrets-with-vault)\n\n### Kubernetes Secrets\n\nKubernetes [Secrets](https://kubernetes.io/docs/concepts/configuration/secret/)\nresources store sensitive data, such as passwords, OAuth\ntokens, and SSH keys, in your clusters. Storing sensitive data in Secrets is\nmore secure than storing them in plaintext\n[ConfigMaps](https://kubernetes.io/docs/concepts/configuration/configmap/)\nor in Pod\nspecifications. Using Secrets gives you control over how sensitive data is used,\nand reduces the risk of exposing the data to unauthorized users.\n\n### Hashicorp Vault\n\nGKE on AWS can use\n[Hashicorp Vault](https://www.vaultproject.io/) to\nsecure Secrets on your user clusters.\nSee [Using HashiCorp Vault on GKE on AWS](/kubernetes-engine/multi-cloud/docs/aws/previous-generation/how-to/secrets-with-vault)\nfor more information.\n\nControl plane security\n----------------------\n\nThe control plane components include the management service and the user\ncluster's Kubernetes API server, scheduler, controllers, and the\n[etcd database](https://github.com/coreos/etcd). In GKE on AWS, local administrators\nmanage the control plane components.\n\nIn GKE on AWS, the control plane components run on AWS. You can\nprotect GKE on AWS's API server by using AWS security groups and\nnetwork ACLs.\n\nAll communication in GKE on AWS is over Transport Layer Security\n(TLS) channels governed by the following certificate authorities (CAs):\n\n- The etcd CA secures communication from the API server to the etcd replicas and also traffic between etcd replicas. This CA is self-signed.\n- The user cluster CA secures communication between the API server and all internal Kubernetes API clients (kubelets, controllers, schedulers). This CA is KMS encrypted.\n- The management service CA is AWS KMS encrypted. It is created when you run `anthos-gke init` and stored in your Terraform workspace. When you use `terraform apply` to create the management service, the CA key is passed as AWS EC2 [user data](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/user-data.html) and decrypted by AWS KMS when the cluster starts.\n\nFor the management service, control plane keys are stored on control plane\n\\[nodes\\]{:.external}. For user clusters, the keys are stored as Kubernetes\nSecrets in the management service's control plane.\n\nCluster authentication in GKE on AWS is handled by certificates\nand service account bearer tokens. As the administrator, you authenticate to the\ncontrol plane using with the administrative certificate to the management\nservice (which you use for initial role binding creation, or for emergency\npurposes).\n\nCertificate rotation is handled in the following ways:\n\n- For the API server, control planes, and nodes, GKE on AWS rotates TLS certificates at each upgrade.\n- You can also [Rotate security credentials](/kubernetes-engine/multi-cloud/docs/aws/previous-generation/how-to/rotate-credentials) manually.\n\nNode security\n-------------\n\nGKE on AWS deploys your workloads onto node pools of AWS EC2\ninstances. The following sections explain how to use the node-level security\nfeatures in GKE on AWS.\n\n### Ubuntu\n\nGKE on AWS uses an optimized version of [Ubuntu](http://www.ubuntu.com) as the\noperating system on which to run the Kubernetes control plane and nodes. Ubuntu\nincludes a rich set of modern [security features](https://wiki.ubuntu.com/Security/Features), and\nGKE on AWS implements several security-enhancing features for\nclusters, including:\n\n- Optimized [package](https://cloud-images.ubuntu.com/bionic/current/bionic-server-cloudimg-amd64-root.manifest) set.\n- Google Cloud-tailored [Linux kernel](https://git.launchpad.net/%7Ecanonical-kernel/ubuntu/+source/linux-gcp/+git/bionic/).\n- Limited user accounts and disabled root login.\n\nAdditional security guides are available for Ubuntu, such as:\n\n- [CIS Benchmark](https://www.cisecurity.org/benchmark/ubuntu_linux/)\n- [DISA STIG](https://public.cyber.mil/stigs/)\n- [FIPS 140-2](https://wiki.ubuntu.com/Security/Certification)\n\n### Node upgrades\n\nYou should [upgrade your nodes](/kubernetes-engine/multi-cloud/docs/aws/previous-generation/how-to/upgrading-user-cluster) on a\nregular basis. From time to time, security issues in the container runtime,\nKubernetes itself, or the node operating system might require you to upgrade\nyour nodes more urgently. When you upgrade your user cluster, each node's\nsoftware is upgraded to their latest versions. Additionally, upgrading nodes\n[rotates encryption credentials](/kubernetes-engine/multi-cloud/docs/aws/previous-generation/how-to/rotate-credentials).\n\nSecuring your workloads\n-----------------------\n\nKubernetes allows users to quickly provision, scale, and update container-based\nworkloads. This section describes tactics that you can use to limit side-effects\nof running containers on cluster and the Google Cloud services.\n\n### Limiting Pod container process privileges\n\nLimiting the privileges of containerized processes is important for your\ncluster's security. You can set security-related options with the\n[Security Context](https://kubernetes.io/docs/tasks/configure-pod-container/security-context/) of Pods and containers. These settings let you\nchange the security settings of your processes such as:\n\n- User and group running the process.\n- Available Linux capabilities.\n- Privilege escalation.\n\nThe default GKE on AWS node operating system, Ubuntu, applies the\ndefault [Docker AppArmor security policies](/container-optimized-os/docs/how-to/secure-apparmor#using_the_default_docker_apparmor_security_profile) to all containers started by\nKubernetes. You can view the profile's template on [GitHub](https://github.com/moby/moby/blob/master/profiles/apparmor/template.go). Among\nother things, the profile denies the following abilities to containers:\n\n- Writing to files directly in a process ID directory (`/proc/`).\n- Writing to files that are not in `/proc/`.\n- Writing to files in `/proc/sys` other than `/proc/sys/kernel/shm*`.\n- Mounting file systems.\n\nWhat's next\n-----------\n\n- [Install a management service](/kubernetes-engine/multi-cloud/docs/aws/previous-generation/how-to/installing-management).\n- [Use HashiCorp Vault on GKE on AWS](/kubernetes-engine/multi-cloud/docs/aws/previous-generation/how-to/secrets-with-vault).\n- [Rotate your security credentials](/kubernetes-engine/multi-cloud/docs/aws/previous-generation/how-to/rotate-credentials)."]]
