[[["易于理解","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-09-04。"],[],[],null,["# Overview\n\nThis page provides an overview of project network policies in\nGoogle Distributed Cloud (GDC) air-gapped appliance.\n\nProject network policies define either ingress or egress rules. Unlike Kubernetes network policies, you can only specify one policy type for a policy.\n\nFor traffic within a project, GDC applies a predefined project network policy, the intra-project policy, to each project by default.\n\nServices and workloads in a project are isolated from external services and workloads by default. However, services and workloads from different project namespaces can communicate with each other by applying cross-project traffic network policies.\n\nIngress and egress firewall rules are the main components of project network policies and determine which types of traffic are allowed in and out of your network. To set firewall rules for your project namespace in GDC, use the GDC console.\n\nSecurity and connectivity\n-------------------------\n\nBy default, services and workloads in a project are isolated within that\nproject. They cannot communicate with external services and workloads without\nconfiguring a network policy.\n\nTo set a network policy for your project namespace\nin GDC, use the `ProjectNetworkPolicy` resource. This resource\nlets you define policies, which allow communication within projects,\nbetween projects, to external IP addresses, and from external IP addresses. Also, you can transfer workloads out from a project only if you [disable data exfiltration protection for the project](/distributed-cloud/hosted/docs/latest/appliance/platform/pa-user/data-exfiltration#prevent-data-exfiltration).\n\nGDC project network policies are additive. The resulting enforcement for a\nworkload is an *any* match for the traffic flow against the union of all\npolicies applied to that workload. When multiple policies are present, the rules for each\npolicy are additively combined, allowing traffic if it matches at least one of the\nrules.\n\nFurthermore, after you apply a single policy,\nall traffic you don't specify is denied. Therefore, when you apply one or more\npolicies that select a workload as the subject, only the traffic that a policy specifies\nis allowed.\n\nWhen you use a well-known IP address you allocate for the project, it performs a\nsource network address translation (NAT) on the outbound traffic from the\norganization.\n\nWorkload-level network policies\n-------------------------------\n\nYou can create workload-level network policies to define fine-grained access control for individual VMs and pods within a project. These policies act like firewalls for your workloads, controlling traffic flow based on labels to enhance security and isolate applications. This granularity allows stricter control over which workloads can communicate with each other within and across projects.\n\nPrepare predefined roles and access\n-----------------------------------\n\nTo configure project network policies, you must have the necessary identity and access roles:\n\n- Project NetworkPolicy Admin: manages project network policies in the project namespace. Ask your Organization IAM Admin to grant you the Project NetworkPolicy Admin (`project-networkpolicy-admin`) cluster role.\n\nWhat's next\n-----------\n\n- [Create intra-project traffic network policies](/distributed-cloud/hosted/docs/latest/appliance/platform/pa-user/pnp/intra-project-traffic)\n- [Create cross-project traffic network policies](/distributed-cloud/hosted/docs/latest/appliance/platform/pa-user/pnp/cross-project-traffic)"]]
