网络云原生网络安全【免费下载链接】calicoCloud native networking and network security项目地址https://gitcode.com/gh_mirrors/cal/calico点击查看免费下载本文以 app-policy/README.md 为核心骨架结合本仓库app-policy/目录下的源码、配置清单与测试用例系统讲解 Calico Application Layer Policy应用层策略简称 ALP的架构原理、数据流、策略匹配机制与部署验证方法。读完本文你将掌握ALP 如何借助 Istio 的加密身份与 mTLS 通道、通过 Envoyext_authz过滤器把授权决策外置到 Dikastes以及如何基于本仓库的配置清单完成安装、演示与源码级调试验证。概述把授权从 L3/L4 提升到 L7Application Layer Policy 是 Project Calico 的一项安全能力它使用 Istio 建立的服务网格基础设施在网络层L3/L4与应用层L7两个维度上对 Pod 间的通信执行授权策略。其核心思路是身份与通道Istio 为工作负载签发并分发加密身份SPIFFE 证书并用这些身份在 Pod 之间建立双向认证的 TLSmTLS连接策略判定Calico 在这条加密通信链路上实施授权策略同时把加密身份service account、namespace、SPIFFE ID和网络层属性IP、端口、协议整合进同一个策略模型执行点注入到 Envoy 代理中的envoy.ext_authz过滤器在处理服务请求时把授权检查外呼给 Dikastes数据来源策略基于一个**全局策略存储global store**计算得出该存储由每个节点上运行的本机 Felix 组件分发到 Dikastes。正如 app-policy/README.md 中的架构图所示ALP 的完整链路是全局策略 → Felix 分发 → Dikastes 本地策略库 → Envoyext_authz外呼 → 策略判定返回。下面逐层展开。Dikastes应用层策略引擎的核心Dikastes取自希腊语裁判/仲裁者是 ALP 的执行引擎位于app-policy/目录是一个独立可构建的 Go 程序。它的职责有两个监听 Envoy 的 gRPC 授权请求envoy.service.auth.v3.Authorization对每次服务请求给出OK/PERMISSION_DENIED等判定从本机 Felix 同步全局策略数据维护一份本地只读的策略存储供判定时查询。启动与命令行接口Dikastes 使用 cobra 组织命令树入口在 app-policy/pkg/dikastes/command.go包含三个子命令子命令用途dikastes server运行授权服务器监听 Unix domain socket同步策略并阻塞等待信号dikastes client namespace account向服务器发送一次测试授权检查构造一个 SPIFFE 格式的源身份可用--method指定 HTTP 方法dikastes health (liveness\|readiness)通过 gRPC 查询健康状态--dial-path指定健康检查服务的 socket 路径全局持久化标志位如下-l, --listenUnix domain socket 监听路径默认/var/run/dikastes/dikastes.sock-d, --dial策略同步服务器的拨号目标默认localhost:50051--debug以 Debug 级别输出日志。server子命令最终调用 app-policy/pkg/dikastes/dikastes.go 中的RunServer其启动流程可以拆解为清理并重建监听 socketos.Chmod为0o777以保证 sidecar 容器可写创建 gRPC 服务器注册授权检查服务与健康检查服务通过syncher.NewClient建立与策略同步服务器的连接异步执行syncClient.Sync(ctx)若设置了环境变量DIKASTES_HTTP_BIND_PORT同时启动一个 HTTP 服务器/terminate端点用于优雅终止阻塞等待SIGINT/SIGTERM或 HTTP 终止请求后GracefulStop。数据平面到策略判定的完整调用链一次请求的判定路径如下源码可循Envoy 的ext_authz过滤器把请求包装为authz.CheckRequest通过 gRPC 发往 Dikastesapp-policy/checker/server.go 中的Check获取当前策略存储的读锁遍历已注册的CheckProvider对启用的 provider 依次执行检查ALP 默认注册的 provider 是 app-policy/checker/alp_check_provider.go 中的ALPCheckProvider其EnabledForRequest判定策略存储中是否配置了本工作负载端点ps.Endpoint ! nil即每 Pod sidecar 模式Check把CheckRequest通过 adapter_checkrequest.go 的CheckRequestToFlowAdapter适配为统一的Flow接口L4 的 IP/端口/协议 L7 的 HTTP 方法/路径/SPIFFE principal/标签进入 checker/check.go 的Evaluate/checkStore最终由checkTiers按层级tier逐条匹配策略返回OK或PERMISSION_DENIED。server.go同时通过authServerV2提供了 v2/v2alpha 协议的兼容适配因此不同版本的 Envoy 都能接入。策略存储与分发从全局存储到本机只读快照双缓冲的 PolicyStoreManagerapp-policy/policystore/store.go 定义了PolicyStore它保存 Calico 策略信息核心字段包括PolicyByID按 PolicyID 索引的策略ProfileByID按 ProfileID 索引的 profile默认拒绝的兜底IPSetByIDIP/IP端口集合Endpoint/Endpoints本机工作负载端点ServiceAccountByID/NamespaceByID用于解析身份标签。policyStoreManager维护current与pending两个存储实现双缓冲切换同步连接断开时调用OnReconnecting()创建新的 pending 存储重新建连并收到InSync消息后OnInSync()将 pending 原子切换为 current。DoWithLock/DoWithReadLock封装了读写锁保证检查路径与同步写入路径互不干扰。syncher 的订阅与重连app-policy/syncher/syncserver.go 中的SyncClient通过 gRPC 流式接口订阅 Felix 的策略同步服务proto.NewPolicySyncClient支持两种订阅类型per-pod-policies默认面向每个 Pod 的策略per-host-policies面向主机粒度的策略通过WithSubscriptionType选项设置。它持续Recv数据平面更新ToDataplane_InSync消息触发OnInSync切换存储其余更新写入当前目标存储并调用ProcessUpdate连接断开后按PolicySyncRetryTime1000ms自动重连。Readiness()返回是否已同步完成供健康检查使用。uds.GetDialOptions()见 app-policy/uds/uds.go为 gRPC 配置了unix拨号器与不安全传输这是因为 Dikastes 与 Felix 之间走本机 Unix domain socket同一节点内无需 TLS。策略评估层级、规则与默认拒绝checkTierschecker/check.go是策略判定的主体核心语义如下按方向取策略getPoliciesByDirection根据rules.RuleDirEgress/RuleDirIngress从端点的 tier 中取出出/入站策略列表逐策略检查checkPolicy对每条策略的InboundRules/OutboundRules依次调用checkRules一旦某条规则匹配按规则动作ALLOW/DENY/PASS结束或跳转层级默认动作若整层策略均未匹配则应用该 tier 的DefaultAction——Deny直接拒绝Passv1 资源中叫next-tier见actionFromString则放行到下一层Profile 兜底所有层级结束后若端点挂有 profiles逐 profile 匹配允许则放行若没有任何 profile则无条件 PERMISSION_DENIED——这体现了默认拒绝的零信任语义Stage 策略隔离PolicyScope区分EnforcedOnly只评估实际执行的策略与StagedAsEnforced把 staged 策略当作已提升来评估用于待生效演练staged 策略在EnforcedOnly下整层被跳过。check_test.goapp-policy/checker/check_test.go通过 1348 行的用例验证了上述行为例如TestEvaluateEndpointNoTiersNoProfiles断言无 tier 无 profile 时返回默认 Deny 且 trace 指向__PROFILE__。规则匹配的完整维度app-policy/checker/match.go 的match函数把规则所有条件做AND 求值并刻意按开销从低到高排序协议/端口整数比较 → CIDR/IP set → 标签选择器 → HTTP 匹配以便大规模策略下尽快短路。可匹配的维度包括L4 协议matchL4Protocol支持tcp/udp/icmp/icmpv6/udplite/sctp等协议名映射见stringToProto也支持notProtocol反选协议号为 0未分配时直接判不匹配端口matchSrcPort/matchDstPort支持端口区间PortRange与命名端口 IP set以IP,protocol:port形式存储的集合成员CIDRmatchSrcNet/matchDstNet支持srcNet/dstNet与notSrcNet/notDstNetIP setmatchSrcIPSets/matchDstIPSets/matchDstIPPortSetIds支持源/目的 IP 集合与IP协议端口集合身份matchSrcIdentity/matchDstIdentity解析 SPIFFE ID 得到 service account 与 namespace再与规则中的serviceAccounts.names/selector、namespace 标签选择器匹配HTTP 七层规则matchRequest→matchHTTP匹配 HTTP 方法与路径。matchServiceAccounts/matchNamespace注释明确了一个安全语义明文无 mTLS请求没有 principal 身份此时视为匹配空身份Dikastes 退化为仅依赖 IP 地址——因此只有显式的 IP/IP set 规则才能约束明文流量。HTTP 路径匹配的规范化防护matchHTTPPaths与normalizeHTTPPathchecker/match.go对请求路径做了严格的 RFC 3986/RFC 7230 规范化后再比较这是防绕过攻击的关键剥离 query 与 fragmentEnvoy 的:path伪头可能携带令牌/凭据服务端日志也会剥掉 query做一次百分号解码——因为上游服务器只解码一次二次解码会过度授权例如%252e%252e会变成..拒绝仍残留%2e/%2f/%5c的双重编码路径reStillEncodedPathSensitive因为会二次解码的上游如某些 WAF/nginx 配置会解析出不同路径拒绝 NUL 字节/admin\x00/../public这类 C 字符串截断攻击把反斜杠折叠为正斜杠对抗 Windows/IIS 后端的\..\穿越剥离每段的 matrix 参数;后缀对齐 Tomcat/Jetty/Spring MVC 等容器的行为最后path.Clean折叠连续斜杠并解析./..段。前缀匹配segmentPrefixMatch锚定在路径段边界前缀/pub不会授权/public-leak。路径无法规范化时按不匹配处理而非回退到原始字节比较。请求身份解析SPIFFE ID 与标签app-policy/checker/requestcache.go 实现了请求级缓存与身份解析SPIFFEIDPattern ^spiffe://[^/]/ns/([^/])/sa/([^/])$从 Envoy 报告的 principal如spiffe://cluster.local/ns/default/sa/customer中提取 namespace 与 service accountinitPeer解析成功后从策略存储的ServiceAccountByID/NamespaceByID中合并该服务账号与命名空间上的标签供标签选择器匹配解析失败principal 无法解析时记录聚合日志peer 置 nil——按空身份匹配任何规则处理即退化为 IP 匹配该结构对 IP 字符串、IP,protocol:port键、身份、L4 协议做请求级 memoize避免对同一请求的每条规则重复计算分配这是应对一个端点挂成千上万条规则的性能设计bench_test.go/bench_egress_test.go提供了基准测试佐证。值得注意的还有 check.go 的日志策略评估路径上的日志全部限速newEvalPathLogger30 秒窗口 突发 10 条或聚合missingIPSets/unparseablePrincipals避免每流每规则打一条日志导致日志风暴。部署与接入Istio EnvoyFilter 与 ServiceEntryapp-policy/config/install/目录给出了 ALP 的安装与接入资源05-calico.yaml自托管 Calico 安装清单calico-node DaemonSet、RBAC、CRD 等。其中与 ALP 直接相关的关键配置是ALPHA_FEATURES: serviceaccounts,httprules开启 service account 身份与 HTTP 规则两个实验特性FELIX_POLICYSYNCPATHPREFIX: /var/run/nodeagent指定策略同步服务的 Unix socket 前缀路径Dikastes 从中读取策略数据。20-app-policy.yaml把 Dikastes 接入 Istio 的三个资源这是 ALP 生效的核心接线ServiceEntry把dikastes.calico.cluster.local解析为 Unix domain socket 端点unix:///var/run/dikastes/dikastes.sockIstio 通过 UDS 访问 DikastesDestinationRule对该主机关闭 mTLStls.mode: DISABLE避免 Envoy 到 Dikastes 的调用再被套一层 TLSEnvoyFilter在SIDECAR_INBOUND监听器上、HTTP与TCP两种监听器协议下、以FIRST位置插入envoy.ext_authz过滤器cluster_name指向outbound|1||dikastes.calico.cluster.local从而保证每个入站请求先经过授权检查。演示示例yaobank 三层应用app-policy/config/demo/提供了一套可直接运行的演示spikecurtis/yaobank 应用 攻击 Pod10-yaobank.yamlcustomer → summary → database 三层的微服务应用每个 Deployment 绑定独立的 ServiceAccount20-attack-pod.yaml模拟攻击者的 Pod30-policy.yaml对应的 GlobalNetworkPolicy展示了 ALP 的两种核心规则形态apiVersion: projectcalico.org/v3 kind: GlobalNetworkPolicy metadata: name: customer spec: selector: app customer ingress: - action: Allow http: methods: [GET] # 七层规则只允许 GET 方法 egress: - action: Allow --- apiVersion: projectcalico.org/v3 kind: GlobalNetworkPolicy metadata: name: summary spec: selector: app summary ingress: - action: Allow source: serviceAccounts: names: [customer] # 身份规则只允许 customer 服务账号 egress: - action: Allow上述策略体现了 ALP 的两个标志性能力HTTP 方法级控制http.methods: [GET]意味着对customer应用只放行 GET 请求POST/PUT 等将被 Dikastes 拒绝服务账号级授权serviceAccounts.names: [customer]意味着只有携带customer这个 SPIFFE 身份的调用才能访问summarydatabase只信任summary账号。这等价于把 Kubernetes 的 RBAC 语义下沉到了网络授权层。健康检查与可运维性Dikastes 内置了两套健康机制gRPC 健康服务app-policy/health/service.go 实现HealthzServer——CheckLiveness恒为 healthyCheckReadiness委托给SyncClient.Readiness()即只有策略同步完成后才认为就绪避免在策略库未就绪时放行请求造成授权空洞HTTP 终止端点RunServer在设置DIKASTES_HTTP_BIND_PORT可搭配DIKASTES_HTTP_BIND_ADDR时启动/terminate用于优雅下线。运维侧可用dikastes client namespace account快速验证授权行为它会构造一个spiffe://cluster.local/ns/namespace/sa/account的源身份发起Check并打印判定结果是排查为什么这个账号被拒/放行的得力工具。总结与源码导航Calico Application Layer Policy 的实质是把 Calico 成熟的网络策略模型层级 tier、规则 action、IP set、选择器延伸到 L7并借助 Istio 的加密身份体系完成身份感知授权。整条链路中Felix 负责全局策略的本地化分发Dikastes 负责在请求热路径上做低开销判定Envoy 的ext_authz过滤器负责把每个请求交给 Dikastes 仲裁。想深入源码可以按以下路径继续阅读关注点文件架构图与整体说明app-policy/README.md、app-policy/docs/arch.png引擎入口与命令app-policy/pkg/dikastes/command.go、app-policy/pkg/dikastes/dikastes.go授权服务器与 v2 兼容app-policy/checker/server.go层级评估与默认拒绝app-policy/checker/check.go规则匹配与路径规范化app-policy/checker/match.go身份解析与请求缓存app-policy/checker/requestcache.go策略存储与双缓冲切换app-policy/policystore/store.go策略同步客户端app-policy/syncher/syncserver.go安装接线EnvoyFilter 等app-policy/config/install/20-app-policy.yaml演示与策略示例app-policy/config/demo/30-policy.yaml行为验证测试app-policy/checker/check_test.go注意本仓库中的安装清单如05-calico.yaml属于较早的历史版本ALP 能力在仓库当前主线中仍作为实验特性存在实际启用时请以你所使用 Calico/Istio 版本的官方文档为准并确认已开启serviceaccounts,httprules对应的特性开关。赞分享网络云原生网络安全【免费下载链接】calicoCloud native networking and network security项目地址https://gitcode.com/gh_mirrors/cal/calico点击查看免费下载相关推荐Rocket.Chat 授权体系深度解析基于角色与权限的 Rocket.Chat 权限模型设计与实践Rocket.Chat 授权体系深度解析基于角色与权限的 Rocket.Chat 权限模型设计与实践 Rocket.Chat 的服务端授权authoriza即时通讯后端前端Lightdash 授权体系深度解析基于 CASL 的组织/项目双层能力模型与自定义角色契约Lightdash 授权体系深度解析基于 CASL 的组织/项目双层能力模型与自定义角色契约 本篇技术指南以 Lightdash 仓库中 授权模块文档 htt后端前端数据分析数据可视化人工智能AI AgentLightdash 授权体系与权限模型深度解析CASL Ability、双层角色叠加与自定义作用域Lightdash 授权体系与权限模型深度解析CASL Ability、双层角色叠加与自定义作用域 Lightdash 的授权模块位于 packages/co后端前端数据分析数据可视化人工智能AI Agent上一篇堆与优先队列Learn-Algorithms项目中的Top-K问题解决方案下一篇SOAR错误排查终极指南10个常见问题与快速解决方案创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考