[[["易于理解","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-05-15。"],[],[],null,["# Preventative controls for acceptable resource configurations\n\nWe recommend that you define policy constraints that enforce acceptable\nresource configurations and prevent risky configurations. The blueprint uses a\ncombination of organization policy constraints and infrastructure-as-code (IaC)\nvalidation in your pipeline. These controls prevent the creation of resources\nthat don't meet your policy guidelines. Enforcing these controls early in the\ndesign and build of your workloads helps you to avoid remediation work later.\n\nOrganization policy constraints\n-------------------------------\n\nThe [Organization Policy](/resource-manager/docs/organization-policy/overview)\nservice enforces constraints to ensure that certain resource configurations\ncan't be created in your Google Cloud organization, even by someone with a\nsufficiently privileged IAM role.\n\nThe blueprint enforces policies at the organization node so that these controls\nare inherited by all folders and projects within the organization. This bundle\nof policies is designed to prevent certain high-risk configurations, such as\nexposing a VM to the public internet or granting public access to storage\nbuckets, unless you deliberately allow an exception to the policy.\n\nThe following table introduces the [organization policy constraints](/resource-manager/docs/organization-policy/org-policy-constraints)\nthat are implemented in the blueprint:\n\nThese policies are a starting point that we recommend for most customers and\nmost scenarios, but you might need to modify organization policy constraints to\naccommodate certain workload types. For example, a workload that uses a\nCloud Storage bucket as the backend for Cloud CDN to host\npublic resources is blocked by `storage.publicAccessPrevention`, or a\npublic-facing Cloud Run app that doesn't require authentication is\nblocked by `iam.allowedPolicyMemberDomains`. In these cases, modify the\norganization policy at the folder or project level to allow a narrow exception.\nYou can also [conditionally add constraints to organization policy](/resource-manager/docs/organization-policy/tags-organization-policy#conditionally_add_constraints_to_organization_policy)\nby defining a tag that grants an exception or enforcement for policy, then\napplying the tag to projects and folders.\n\nFor additional constraints, see [available constraints](/resource-manager/docs/organization-policy/org-policy-constraints) and [custom constraints](/resource-manager/docs/organization-policy/creating-managing-custom-constraints).\n\nPre-deployment validation of infrastructure-as-code\n---------------------------------------------------\n\nThe blueprint uses a GitOps approach to manage infrastructure, meaning that all\ninfrastructure changes are implemented through version-controlled\ninfrastructure-as-code (IaC) and can be validated before deploying.\n\nThe [policies enforced in the blueprint](https://github.com/terraform-google-modules/terraform-example-foundation/tree/master/policy-library/policies/constraints)\ndefine acceptable resource configurations that can be deployed by your pipeline.\nIf code that is submitted to your GitHub repository does not pass the policy\nchecks, no resources are deployed.\n\nFor information on how pipelines are used and how controls are enforced through\nCI/CD automation, see [deployment methodology](/architecture/blueprints/security-foundations/deployment-methodology).\n\nWhat's next\n-----------\n\n- Read about [deployment methodology](/architecture/blueprints/security-foundations/deployment-methodology) (next document in this series)"]]
