私人endpoints和内部网络

1）为什么要建立私人网络

• 将PaaS/DB/存储与公共 IP隔离；
• 法规遵从性简化（PCI DSS/GDPR）；
• 可预见的延迟和路由。

2）基本模型： VPC/VNet和枢纽

地址空间：单个CIDR计划，没有交叉点（例如'10。0.0.0/12'切入周围和中心）。
细分：具有单独路由/ACL/SG的"ingress"，"app"，"data"，"ops"，"shared"子网。
公交枢纽：带网关的中央VPC/VNet （VPN/DirectConnect/ExpressRoute/Interconnect）、VPC同步/公交网关和网络门户。
双堆栈：提前IPv6规划（节省NAT,提高地址规模）。

3）私人endpoints： 原则

• 流量在提供商网络内（不通过Internet）。
• Endpoint策略限制了可以行走的位置（前缀/ARN/资源）。
• DNS被覆盖为私有IP（请参阅§6）。

类型目标：对象堆栈（S3/GCS/Blob），秘密/KMS，队列，DB驱动的事件总线，分析服务，寄存器工件。

4）进入和平衡内部

仅从私人子网中看到用于L4/7的内部负载平衡器（ILB）。

Kubernetes:

带有内部注释的"服务"类型"LoadBalancer"。
通过私人地址上的Internal Ingress（Nginx/Contour/Gateway API）登录。
Gateway API（私人）：私人后端集成；向外-如果需要的话,只能通过边缘。

示例： Ingress作为内部K8s

yaml apiVersion: networking. k8s. io/v1 kind: Ingress metadata:
name: api-internal annotations:
kubernetes. io/ingress. class: "nginx"
alb. ingress. kubernetes. io/scheme: internal # or provider equivalent spec:
rules:
- host: api. internal. corp http:
paths:
- path: /v1/
pathType: Prefix backend:
service:
name: api port: { number: 8080 }

5）Egress路径： "默认为deny"

• NAT Gateway（用于更新/存储库）+通过FQDN/IP的egress allowlist；
• TLS检查/代理，如果政策需要控制；
• Private endpoints到PaaS/寄存器而不是 NAT。
• SG/NACL：明确的per服务权限，"东西向"是最低权限。
• Egress K8s政策（CNI/OPA Gatekeeper/Calico NetworkPolicy）-禁止外部IP，群集/扩展权限。

6) DNS: split-horizon и private zones

分隔内部区域（'.internal.公司）和公开。
提供商服务的私人DNS区域：覆盖公共名称（例如,'bucket。s3.region.amazonaws.com'）用于私有A/AAAA记录。

Forwarders/Conditional DNS между on-prem ↔ cloud.

名称格式：封装环境/区域（'api.eu1.internal.公司,避免PII。

api. internal. corp. A  10. 20. 30. 40 s3. bucket. corp. A  10. 100. 0. 25 # via private endpoint

7）网络连接模式

Peering （VPC↔VPC/VNet↔VNet）：简单快捷；不总是支持公交→使用公交Gateway/Virtual WAN/Cloud Router for star （hub-and-spoke）。
On-prem ⇄ Cloud：IPsec VPN用于启动，然后是带有BGP和备份（两个提供商，不同的入口点）的专用线（DC/ER/IC）。
VRF/路线域分割： prod/stage/dev隔离和卡外围。

8）Zero Trust和内部身份验证

mTLS默认值（服务主题：Istio/Linkerd/Consul）,机器标识：SPIFFE/SPIRE。
L7策略：通过JWT/claims/scopes授权,在代理级别限制路由/方法。
Secrets: HashiCorp Vault/КMS + External Secrets Operator;短寿命的credenschels（STS）。
基地/特权访问：仅通过经纪人/JIT会议（MFA，团队记录）访问私有化。

示例： Envoy mTLS+JWT-authz过滤器（片段）

yaml transport_socket:
name: tls typed_config: {... spiffe://svc. api... }
http_filters:
- name: envoy. filters. http. jwt_authn typed_config:
providers:
oidc: { issuer: https://idp. corp, audiences: ["api"], remote_jwks: {...} }
rules: [{ match: { prefix: "/v1" }, requires: { provider_name: oidc } }]

9）数据和PaaS内部私有

基地/集群：仅限私人地址；通过bastion/JIT进行管理。
存储：从VPC通过私人终端访问；endpoint策略只允许您想要的垃圾箱/容器。
队列/总线：私人接口；同一VPC/peering中的生产者/消费者。
文物寄存器：从CI/CD运行者在私人子网中的私有访问。

10）私人网络的可观察性

OpenTelemetry Collector-作为遥测网关：内部出口商在自我托管的（Prometheus/Tempo/Loki/ClickHouse）或通过私人终端管理后端。
Flow logs/NSG/NACL logs和reachability analyzer-是强制性的。
SLO切片："site/region/vpc/subnet"，超出了egress泄漏和出乎意料的"互联网方向"。

11）测试和验证

用于网络规则/输入/服务的策略作为代码（OPA/Gatekeeper）。
Canary路由：私有DNS中的测试域,来自不同子网/AZ/地区的合成检查。
混沌网络：VPC/AZ inter-AZ（netem/Toxiproxy）中的延迟/损失，定时检查和返回策略。

12）配置示例

12.1 Terraform：标签和路线（想法）

hcl resource "aws_route_table" "app" {
vpc_id = aws_vpc. core. id tags = { Name = "rt-app", env = var. env, zone = "private" }
}
Route on PrivateLink endpoint (interface endpoint is created separately)
resource "aws_vpc_endpoint_route_table_association" "s3" {
route_table_id = aws_route_table. app. id vpc_endpoint_id = aws_vpc_endpoint. s3. id
}

12.2 K8s NetworkPolicy：禁止除必要以外的所有内容

yaml apiVersion: networking. k8s. io/v1 kind: NetworkPolicy metadata: { name: deny-all }
spec:
podSelector: {}
policyTypes: ["Ingress","Egress"]
kind: NetworkPolicy metadata: { name: allow-core }
spec:
podSelector: { matchLabels: { app: api } }
egress:
- to:
- namespaceSelector: { matchLabels: { ns: db } }
ports: [{ port: 5432, protocol: TCP }]
- to:
- ipBlock: { cidr: 10. 100. 0. 0/16 }  # private endpoints ports: [{ port: 443, protocol: TCP }]

12.3 Nginx Ingress (internal scheme) + HSTS

yaml metadata:
annotations:
alb. ingress. kubernetes. io/scheme: internal nginx. ingress. kubernetes. io/hsts: "true"

13）反模式

来自私人子网的通用"管理互联网"；缺乏控制。
拆分DNS和随机手动"/etc/hosts"。
相交的CIDR和"NAT矩阵"。
为了方便起见，公开为DB/金库提供 endpoint。

没有线程/规则审核日志；"开放"SG'0。0.0.0/0`.

代码/CI中的长寿命静态访问密钥。

14）成本和性能

私人结帐通常比永久性NAT egress便宜，更安全。
规划NAT 群集/az-local的带宽,以免创建bottleneck。
缓存/边缘和SWR可减少跨区域流量。
协议选择：HTTP/2/gRPC内部→较少的连接和TLS overhead。

15） iGaming/财务细节

PCI DSS：一个单独的网络/VRF中的卡路径（CDE），没有互联网；仅通过私人端口/PSP登录器访问；不可更改的审计（WORM/对象锁）。
KMS/Vault：按区域/品牌细分；签名操作（HSM）仅可通过mTLS从CDE获得。
PSP/KYC：如果有私人连接/标记-使用；否则-通过具有HMAC/mTLS 和显式allowlist的受信任代理来进行表述。
多影子："tenant"/"brand"标签和政策；单独的私有DNS名称和SG层。

16）准备就绪支票清单

• CIDR无交叉计划；双堆栈就绪（IPv6）。

[] Hub-and-Spoke, Transit, peering;on-prem ⇄ cloud-BGP，备用链接对。

• 所有PaaS/存储/DB-通过私人endpoints+endpoint政策。

[] Internal LB/Ingress;公共外围-仅在边缘/WAF上。

• 已配置Split-horizo​​n DNS，private zones和condition-forwarding。
• Egress默认为"deny"；NAT/代理受到限制和日志记录。

[] Mesh mTLS + SPIFFE;L7上的JWT-authz；Vault/ESO，简短的秘密。

• NetworkPolicy/SG/NACL-"最低要求"、流记录和可重复性分析。
• 内部的OTel收藏家；通过"站点/区域/vpc"对egress泄漏进行SLO。
• PCI/审计：WORM日志，KMS/HSM，CDE隔离，访问运行簿。

17) TL;DR

以清晰的CIDR计划构建集线器与分频器模式网络,在每个PaaS/存储/DB上使用专用端点,并且仅通过托管的egress点向外通信。内部-内部LB/Ingress，mTLS+SPIFFE，split-horizo​​n DNS，严格的NetworkPolicy/SG和通过OTel的遥测。对于iGaming/financial，请添加PCI细分，KMS/Vault和不可更改的审计；PSP/KYC通过私人渠道或严格控制的代理输出。