이 가이드에서는 Secret Manager 사용 시 몇 가지 권장사항을 소개합니다.
이 가이드에는 권장사항이 모두 포함되어 있지 않습니다. 이 가이드를 읽기 전에 Google Cloud 환경에 대한 전반적인 이해를 돕기 위해 플랫폼 개요 및 Secret Manager 개요를 살펴보는 것이 좋습니다.
액세스 제어
Secret Manager API에 대한 액세스는 IAM으로 보호됩니다.
보안 비밀에 권한을 부여할 때 최소 권한의 원칙을 따르세요.
최신 별칭을 사용하는 대신 버전 번호로 보안 비밀 참조 기존 출시 프로세스를 사용하여 버전 번호에 업데이트를 배포합니다. 일반적으로 이는 시작 시 읽는 특정 보안 비밀 버전으로 애플리케이션을 구성하는 것을 의미합니다. 최신 별칭을 사용하는 것이 편리할 수 있지만 보안 비밀의 새 버전에 문제가 있으면 워크로드가 보안 비밀 버전을 사용하지 못할 수 있습니다. 버전 번호를 고정하면 기존 출시 프로세스를 사용하여 구성을 검증하고 롤백할 수 있습니다.
보안 비밀 버전을 폐기하거나 보안 비밀을 삭제하기 전에 보안 비밀 버전을 사용 중지합니다. 이렇게 하면 보안 비밀을 폐기된 것처럼 보이지만 되돌릴 수 있는 상태로 만들어 서비스 중단을 방지할 수 있습니다. 즉, 데이터를 영구적으로 삭제하기 전에 종속 항목이 남아 있는지 확인할 수 있도록 일주일 동안 사용 중지하고 대기할 수 있습니다.
영구적으로 삭제해야 하는 경우가 아니라면 프로덕션 보안 비밀에 만료 시간을 설정하지 마세요. 만료 기능은 임시 환경 자동 정리에 가장 적합합니다. 보안 비밀 만료의 대안으로 시간 기반 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"]],["최종 업데이트: 2024-12-21(UTC)"],[],[],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."]]
