[[["わかりやすい","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-04 UTC。"],[[["\u003cp\u003eUtilize the Cloud Storage state backend for Terraform state management to enable team collaboration and separate sensitive information from version control.\u003c/p\u003e\n"],["\u003cp\u003eEncrypt the Terraform state using customer-supplied encryption keys via the \u003ccode\u003eGOOGLE_ENCRYPTION_KEY\u003c/code\u003e environment variable, even though no secrets should be in the state file.\u003c/p\u003e\n"],["\u003cp\u003eAvoid storing secrets directly within the Terraform state file, as certain providers like \u003ccode\u003evault_generic_secret\u003c/code\u003e and \u003ccode\u003egoogle_service_account_key\u003c/code\u003e may store them in plaintext.\u003c/p\u003e\n"],["\u003cp\u003eMark sensitive outputs as such within Terraform configurations to prevent the exposure of sensitive data in command-line output and implement separation of duties by restricting access to Terraform resources.\u003c/p\u003e\n"],["\u003cp\u003eImplement pre-apply checks with tools like \u003ccode\u003egcloud terraform vet\u003c/code\u003e and continuous audits using Security Health Analytics, InSpec, or Serverspec to detect security regressions and ensure infrastructure security.\u003c/p\u003e\n"]]],[],null,["# Best practices for security\n\nThis document provides guidelines and recommendations for securely using\nTerraform for Google Cloud. Terraform requires sensitive access to your\ncloud infrastructure to operate. Following security best practices can help to\nminimize the associated risks and improve your overall cloud security.\n\nThis guide is not an introduction to Terraform. For an introduction to using\nTerraform with Google Cloud, see\n[Get started with Terraform](/docs/terraform/get-started-with-terraform).\n\nUse remote state\n----------------\n\nFor Google Cloud customers, we recommend using the\n[Cloud Storage state backend](https://www.terraform.io/docs/backends/types/gcs.html).\nThis approach locks the state to allow for collaboration as a team. It also\nseparates the state and all the potentially sensitive information from version\ncontrol.\n\nMake sure that only the build system and highly privileged administrators can\naccess the bucket that is used for remote state.\n\nTo prevent accidentally committing development state to source control, use\n[gitignore](https://github.com/github/gitignore/blob/master/Terraform.gitignore)\nfor Terraform state files.\n\nEncrypt state\n-------------\n\nThough Google Cloud buckets are encrypted at rest, you can use\n[customer-supplied encryption keys](/storage/docs/encryption#customer-supplied)\nto provide an added layer of protection. Do this by using the\n`GOOGLE_ENCRYPTION_KEY` environment variable. Even though no secrets should be\nin the state file, always encrypt the state as an additional measure of defense.\n\nDon't store secrets in state\n----------------------------\n\nThere are many resources and data providers in Terraform that store secret\nvalues in plaintext in the state file. Where possible, avoid\nstoring secrets in state. Following are some examples of providers that store\nsecrets in plaintext:\n\n- [`vault_generic_secret`](https://registry.terraform.io/providers/hashicorp/vault/latest/docs/resources/generic_secret)\n- [`tls_private_key`](https://registry.terraform.io/providers/hashicorp/tls/latest/docs/resources/private_key)\n- [`google_service_account_key`](https://registry.terraform.io/providers/hashicorp/google/latest/docs/resources/google_service_account_key)\n- [`google_client_config`](https://registry.terraform.io/providers/hashicorp/google/latest/docs/data-sources/client_config)\n\nMark sensitive outputs\n----------------------\n\nInstead of attempting to manually\n[encrypt sensitive values](https://www.terraform.io/docs/extend/best-practices/sensitive-state.html),\nrely on Terraform's built-in support for sensitive state management. When\nexporting sensitive values to output, make sure that the values are marked as\n[sensitive](https://www.terraform.io/docs/configuration/outputs.html#sensitive-suppressing-values-in-cli-output).\n\nEnsure separation of duties\n---------------------------\n\nIf you can't run Terraform from an automated system where no users have access,\nadhere to a separation of duties by separating permissions and directories. For\nexample, a network project would correspond with a network Terraform service\naccount or user whose access is limited to this project.\n\nRun pre-apply checks\n--------------------\n\nWhen running Terraform in an automated pipeline, use a tool like\n`gcloud terraform vet` to\n[check plan output against policies](/docs/terraform/policy-validation) before\nit is applied. Doing so can detect security regressions before they happen.\n\nRun continuous audits\n---------------------\n\nAfter the `terraform apply` command has executed, run automated security checks.\nThese checks can help to ensure that infrastructure doesn't drift into an\ninsecure state. The following tools are valid choices for this type of check:\n\n- [Security Health Analytics](/security-command-center/docs/how-to-use-security-health-analytics)\n- [InSpec](https://inspec.io)\n- [Serverspec](https://serverspec.org/)\n\nWhat's next\n-----------\n\n- Learn about [general style and structure best practices for Terraform on Google Cloud](/docs/terraform/best-practices/general-style-structure).\n- Learn about [best practices when using Terraform root modules](/docs/terraform/best-practices/root-modules)."]]