[[["易于理解","easyToUnderstand","thumb-up"],["解决了我的问题","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["很难理解","hardToUnderstand","thumb-down"],["信息或示例代码不正确","incorrectInformationOrSampleCode","thumb-down"],["没有我需要的信息/示例","missingTheInformationSamplesINeed","thumb-down"],["翻译问题","translationIssue","thumb-down"],["其他","otherDown","thumb-down"]],["最后更新时间 (UTC):2025-08-18。"],[],[],null,["# Secret Manager best practices\n\nThis guide introduces some best practices when using Secret Manager. The guide is not an\nexhaustive list of recommendations. We recommend reviewing the\n[platform overview](/docs/overview) in order to understand the\noverall Google Cloud landscape and the\n[Secret Manager overview](/secret-manager/docs/overview)\nbefore you read this guide.\n\nAccess control\n--------------\n\nAccess to the Secret Manager API is protected by IAM.\nFollow the principle of least privilege when granting permissions to secrets.\n\n- Limit organization ownership to a [secured super admin\n account](/resource-manager/docs/super-admin-best-practices).\n\n- Segment applications and environments (staging or production) into separate\n projects as described in [Decide\n a resource hierarchy for your Google Cloud landing zone](/architecture/landing-zones/decide-resource-hierarchy). This can help isolate environments\n with project level IAM binding and ensures that quotas are enforced independently.\n\n- Choose a [curated-role](/secret-manager/docs/access-control)\n with the minimal necessary permissions, or create a [custom role](/iam/docs/creating-custom-roles)\n if necessary.\n\n- When secrets for many services are in a single project, use\n [secret level\n IAM bindings](/secret-manager/docs/access-control#least-privilege), or [IAM\n Conditions](/secret-manager/docs/access-control#conditions) to limit access to the necessary subset of secrets.\n\n- [IAM Recommender](/policy-intelligence/docs/role-recommendations-overview)\n can further assist in identifying over privileged IAM bindings.\n\nCredentials are required to authenticate to the Secret Manager API. The\nclient libraries all use a similar strategy to look for credentials referred to\nas [Application Default Credentials](/docs/authentication#service-accounts).\n\n- When developing locally use [`\n gcloud auth application-default login`](/sdk/gcloud/reference/auth/application-default/login). This creates a file with credentials that are\n automatically picked up by client libraries.\n\n- On Compute Engine and other Google Cloud compute platforms like\n Cloud Run functions, the client libraries obtain credentials through the\n [instance metadata server](/compute/docs/metadata/overview).\n\n- On GKE, [workload identity](/kubernetes-engine/docs/how-to/workload-identity)\n provides credentials through a metadata service, as well.\n\n- On other platforms like Amazon Web Services or Microsoft Azure, consider\n setting up [workload identity federation](/iam/docs/workload-identity-federation),\n which uses existing identity mechanisms to authenticate to Google Cloud APIs.\n\nAll of these methods are preferred to exporting a service account credential\nbecause they don't require securely storing and accessing an additional secret\noutside of the Secret Manager API.\n\nCoding practices\n----------------\n\nAvoid passing secrets to your application through the file system or through the environment\nvariables. The following are some reasons for using other methods for handling secrets:\n\n- When a secret is accessible on the file system, application vulnerabilities\n like directory traversal attacks can become higher severity as the attacker\n may gain the ability to read the secret material.\n\n- When a secret is consumed through environment variables, misconfigurations\n such as enabling debug endpoints or including dependencies that log process\n environment details may leak secrets.\n\n- When syncing secret material to another datastore (like Kubernetes\n Secrets), evaluate the access controls provided by that data store. Consider the following:\n\n - Does the datastore expand the access of the secret?\n\n - Is it possible to audit access of the secret?\n\n - Does the datastore comply with your data-at-rest encryption and\n regionalization requirements?\n\nWe recommend using the Secret Manager API directly using one of the\nprovided [client libraries](/secret-manager/docs/reference/libraries), or by following the\n[REST](/secret-manager/docs/reference/rest) or\n[GRPC](/secret-manager/docs/reference/rpc) documentation.\n\nHowever, for some product integrations such as serverless integrations, you may\npass secrets through the file system or through environment variables. For\ninformation, see \\[Use Secret Manager with other products\\](/secret-manager/docs/using-other-products).\n\nAdministration\n--------------\n\n\nChoose the [automatic replication policy](/secret-manager/docs/choosing-replication) when\ncreating secrets unless your workload has specific location requirements (enforceable\nusing the [`constraints/gcp.resourceLocations`](/resource-manager/docs/organization-policy/defining-locations) constraint).\n\nReference secrets by their\n[version number](/secret-manager/regional-secrets/add-secret-version-rs) rather than using the latest alias.\nDeploy updates to version numbers using your existing release processes. Typically this means\nconfiguring your application with a specific secret version that is read on startup. Although using the\nlatest alias might be convenient, if there is a problem with the new version of the secret, your\nworkload may be left unable to use the secret version. By pinning to a version number, the configuration\ncan be validated and rolled back using your existing release processes.\n\n[Disable](/secret-manager/docs/disable-secret-version) secret versions before\ndestroying them or deleting secrets. This helps prevent outages by putting the\nsecret in a state that appears the same as destroy but is reversible. That is,\nyou can disable and wait a week so that you can be sure there are no lingering\ndependencies before permanently deleting data.\n\nDon't set [expiration](/secret-manager/docs/creating-and-managing-expiring-secrets#safely-using-expiring-secrets)\non production secrets unless you are certain that they should be irreversibly deleted. The expiration\nfeature is best suited for automated cleanup of temporary environments. Consider\n[time-based IAM conditions](/secret-manager/docs/access-control#conditions)\nas an alternative to expiring secrets.\n\nPeriodically [rotate](/secret-manager/docs/secret-rotation)\nyour secrets to do the following:\n\n- Limit the impact in the case of a leaked secret.\n\n- Ensure that individuals who no longer require access to a secret can't continue\n to use a previously accessed secret.\n\n- Reduce the likelihood of an outage.\n\nMonitor secrets across your organization using [Cloud Asset Inventory](/asset-inventory/docs/export-asset-metadata)\nfor the following reasons:\n\n- Help identify secrets across your organization.\n\n- Identify non-conformance to organization requirements such as rotation,\n encryption configuration, and location.\n\nEnable [data access logs](/secret-manager/docs/audit-logging) to obtain and\nanalyze the `AccessSecretVersion` request information. Enable this at the folder or\norganization level to enforce logging without having to configure it on every secret or project.\n\nIn addition to IAM controls, you can limit access to the Secret Manager API\nwith network-based controls by setting up a\n[VPC Service Controls perimeter](/vpc-service-controls/docs/overview)\nfor your organization.\n\nThe [`constraints/iam.allowedPolicyMemberDomains`](/resource-manager/docs/organization-policy/restricting-domains)\norganization policy can be used to limit the identities that can be added to IAM policies\nfor secrets.\n\nEstimate your peak secret usage (considering a [thundering herd](https://sre.google/sre-book/data-processing-pipelines/#thundering-herd-problems-9ps7uyuL)\nof requests due to concurrent application deploys or autoscaling of your service) and ensure that\nyour project has [enough quota](/secret-manager/quotas) to handle such an event. If more quota\nis needed, request [an increase](/secret-manager/quotas#requesting_increases).\n\nData residency compliance\n-------------------------\n\nChoose [regional secrets](/secret-manager/regional-secrets/data-residency) if you have strict data residency and\nsovereignty requirements. Regional secrets let you store sensitive data within a specific geographic\nlocation, providing complete at-rest, in-use, and in-transit guarantees, helping you comply with legal,\nregulatory, or organizational requirements surrounding data residency."]]