云原生运维安全【免费下载链接】cloud-custodianRules engine for cloud security, cost optimization, and governance, DSL in yaml for policies to query, filter, and take actions on resources项目地址https://gitcode.com/gh_mirrors/cl/cloud-custodian点击查看免费下载导读本文围绕 Cloud Custodianc7nGCP 插件中的gcp.loadbalancer-backend-bucket资源讲解如何通过一条 YAML 策略在源 GCS 存储桶被删除后按bucketName精确匹配并删除仍残留在负载均衡配置中的后端桶backend bucket。读完本文你将掌握该资源的字段结构、value过滤器与delete动作的完整用法、底层实现原理QueryResourceManagerMethodAction调用链以及配套测试用例与真实 API 响应的解读方式可直接复制策略到自己的 GCP 环境使用。问题背景删了桶backend bucket 却还在在 Google Cloud 中外部 HTTP(S) 负载均衡可以通过backend bucket将请求路由到 GCS 存储桶。backend bucket 本质上是一个引用它自身不存储数据只保存bucketName等元数据指向某个 GCS 桶。这里存在一个经典陷阱当 GCS 桶被删除时引用它的 backend bucket 并不会被级联删除。于是负载均衡配置中会残留悬空引用——backend bucket 仍然存在但指向的桶已经不存在了。如果放任不管这些残留对象会持续占用配额、干扰后续同名桶的重新创建也让配置清单与实际资源状态不一致。针对这一场景Cloud Custodian 提供了gcp.loadbalancer-backend-bucket资源类型我们可以列出项目中所有 backend bucket用bucketName字段过滤出指向已删除桶的条目然后直接执行删除。官方示例文档 loadbalancer-delete-backend-buckets.rst 给出的正是这条治理策略。完整策略按不存在的桶名删除 backend bucket以下 YAML 是本文的核心策略来自 官方示例可直接保存为policy.yml使用policies: - name: gcp-loadbalancer-backend-buckets-delete resource: gcp.loadbalancer-backend-bucket filters: - type: value key: bucketName op: eq value: custodian-bucket-0 actions: - type: delete策略语义非常直白枚举当前 GCP 项目中所有 backend bucket筛选出bucketName等于custodian-bucket-0的条目该桶已被删除因而这些 backend bucket 属于悬空引用最后对命中的资源逐个执行删除。逐段拆解配置段取值含义namegcp-loadbalancer-backend-buckets-delete策略名用于日志、报告与去重resourcegcp.loadbalancer-backend-bucket目标资源类型对应 GCP ComputebackendBucketsAPIfilters.typevalue通用值过滤器按资源字段做条件匹配filters.keybucketName被匹配的字段名即 backend bucket 指向的 GCS 桶名filters.opeq相等比较运算符filters.valuecustodian-bucket-0期望的桶名这里是被删除的桶actions.typedelete对命中的每个 backend bucket 调用backendBuckets.delete资源字段backend bucket 里有什么要写出可靠的过滤条件先要了解资源的字段结构。从仓库录制的真实 API 响应 get-compute-v1-projects-cloud-custodian-global-backendBuckets-custodian-backend-bucket-0_1.json 可以看到一个典型对象{ kind: compute#backendBucket, description: , enableCdn: false, bucketName: custodian-bucket-0, creationTimestamp: 2019-04-30T06:10:49.495-07:00, id: 8240481941722625974, selfLink: https://www.googleapis.com/compute/v1/projects/cloud-custodian/global/backendBuckets/custodian-backend-bucket-0, name: custodian-backend-bucket-0 }其中与策略直接相关的字段是字段说明namebackend bucket 自身的名称全局唯一删除动作依赖它定位资源bucketName后端引用的 GCS 存储桶名本文过滤条件即针对此字段enableCdn是否启用 Cloud CDN可作为附加过滤维度creationTimestamp创建时间可用于残留超过 N 天再清理等场景description描述信息selfLink/id资源的 API 链接与数字标识这些字段同时也被定义为资源默认的报表字段。在 loadbalancer.py 中可以看到default_report_fields [name, description, creationTimestamp, bucketName, enableCdn]也就是说即使不加任何配置custodian run --output生成的资源报告也会包含这些列。底层实现资源类型与删除动作的源码依据资源注册与 API 映射gcp.loadbalancer-backend-bucket在资源映射表 resource_map.py 中注册gcp.loadbalancer-backend-bucket: c7n_gcp.resources.loadbalancer.LoadBalancingBackendBucket,对应的类定义位于 loadbalancer.pyresources.register(loadbalancer-backend-bucket) class LoadBalancingBackendBucket(QueryResourceManager): class resource_type(TypeInfo): service compute version v1 component backendBuckets enum_spec (list, items[], None) scope project name id name default_report_fields [ name, description, creationTimestamp, bucketName, enableCdn ] asset_type compute.googleapis.com/BackendBucket urn_component backend-bucket它继承自 QueryResourceManager通过TypeInfo声明 API 调用信息servicecompute、versionv1、componentbackendBuckets枚举方式为list并取响应中的items[]作用域为项目级scopeproject。也就是说策略运行时 Cloud Custodian 会调用 Compute Engine v1 的backendBuckets.list获取全量 backend bucket再交给过滤器处理。同时asset_type compute.googleapis.com/BackendBucket表明该资源可用于 Cloud Asset Inventory 集成urn_component backend-bucket则用于生成统一资源名URN。delete 动作MethodAction 的封装删除动作定义在 loadbalancer.pyLoadBalancingBackendBucket.action_registry.register(delete) class LoadBalancingBackendBucketDelete(MethodAction): method_spec {op: delete} def get_resource_params(self, model, resource): project local_session(self.manager.source.query.session_factory).get_default_project() return { project: project, backendBucket: resource[name]}这里的关键是它复用了 MethodAction 这一通用动作基类——对一组过滤后的资源逐个调用某个 API 方法的 80% 样板逻辑都被封装在内method_spec {op: delete}声明要调用的 API 操作process()将资源按chunk_size 20分批逐批调用process_resource_set每个资源经invoke_api→client.execute_command(op_name, params)执行实际 HTTP 请求get_resource_params负责构建请求参数项目取当前默认项目backendBucket取资源的name字段。因此策略中的actions: [{type: delete}]最终会翻译为对每个命中资源执行一次 Compute v1backendBuckets.delete请求DELETE /projects/{project}/global/backendBuckets/{name}。录制的真实响应 delete-compute-v1-projects-cloud-custodian-global-backendBuckets-custodian-backend-bucket-1_1.json 显示返回compute#operationoperationType: deletestatus: RUNNING即删除以异步操作形式提交。权限推导依据MethodAction.get_permissions()的逻辑actions/core.py权限名由{service}.{component}.{method}拼接而成。对本文动作即compute.backendBuckets.delete。运行策略的服务账号需要具备该权限连同查询所需的compute.backendBuckets.list/compute.backendBuckets.get这也在录制的事件审计日志 lb-backend-bucket-get.json 中有所印证permission: compute.backendBuckets.get。实战提示一个桶名可能命中多个 backend bucket值得特别注意的是bucketName与 backend bucket 并非一一对应。在测试回放数据 get-compute-v1-projects-cloud-custodian-global-backendBuckets_1.json 中可以看到custodian-bucket-0同时被两个 backend bucket 引用backend bucket 名称bucketNameenableCdncustodian-backend-bucket-1custodian-bucket-0truecustodian-backend-bucket-2custodian-bucket-name-1falsecustodian-backend-bucket-3custodian-bucket-0true也就是说一个 GCS 桶可能被多个 backend bucket 引用例如配置了 CDN 与未配置 CDN 的不同实例。当这个桶被删除后所有引用它的 backend bucket 都会变成悬空引用。上面的策略会一次性匹配并删除全部相关条目——这正是按桶名清理比按 backend bucket 名清理更彻底的原因。如果希望清理更稳健例如桶名以特定前缀开头可以将op: eq换成op: regex或op: infilters: - type: value key: bucketName op: regex value: ^deleted-.*测试验证策略行为有据可查仓库为本文场景提供了完整的自动化测试test_loadbalancer_backend_bucket_deletetest_loadbalancer.py。测试使用回放数据lb-backend-buckets-delete核心断言如下策略以bucketName custodian-bucket-0为过滤条件运行时命中2个资源custodian-backend-bucket-1与custodian-backend-bucket-3两者的bucketName均为custodian-bucket-0删除动作执行后再次调用backendBuckets.list列表中只剩custodian-backend-bucket-2其 bucketName 为custodian-bucket-name-1确认两个悬空 backend bucket 已被删除。该测试验证了从枚举 → 过滤 → 删除 → 复核的完整闭环也印证了一个被删桶名可以对应多个 backend bucket 并被一次性清理的行为。回放数据位于 lb-backend-buckets-delete可用于进一步核对每一步的 API 请求与响应。运行策略从 dryrun 到真正执行1. 先 dryrun 观察匹配结果在 GCP 插件安装配置 就绪已配置GOOGLE_APPLICATION_CREDENTIALS等服务账号凭据的前提下先以 dryrun 模式运行只枚举与过滤、不执行删除custodian run --dryrun -c policy.yml -s output此时output目录下会生成对应策略的资源报告确认命中的 backend bucket 是否如预期。2. 正式执行删除确认无误后移除--dryruncustodian run -c policy.yml -s output执行过程中Cloud Custodian 会按 20 个一批调用backendBuckets.delete并将每个资源的处理结果写入报告与日志。3. 从事件触发可选LoadBalancingBackendBucket也实现了get方法loadbalancer.py可通过compute.backendBuckets.get审计事件lb-backend-bucket-get.json即此类事件的样本驱动将上述策略部署为事件驱动模式在 backend bucket 被查询/变更时即时响应。小结清理已删除 GCS 桶的残留 backend bucket是 GCP 负载均衡配置治理中一个小而实用的场景。借助 Cloud Custodian 的gcp.loadbalancer-backend-bucket资源与delete动作一条十余行的 YAML 策略即可完成枚举、过滤与删除的完整闭环过滤维度bucketName字段精确匹配被删除的桶名可扩展到regex、in等更灵活的条件清理粒度自动覆盖所有引用同一桶名的 backend bucket避免逐条手工排查可验证性仓库内置的 test_loadbalancer.py 测试与回放数据为策略行为提供了可复现的实证参考。更多 GCP 场景策略可参考 gcp/examples 目录下的其他示例如 loadbalancer-ssl-policy-delete-old-versions.rst、loadbalancer-network-tiers.rst或阅读 GCP 使用指南 了解完整的入门流程。赞分享云原生运维安全【免费下载链接】cloud-custodianRules engine for cloud security, cost optimization, and governance, DSL in yaml for policies to query, filter, and take actions on resources项目地址https://gitcode.com/gh_mirrors/cl/cloud-custodian点击查看免费下载相关推荐Cloud Custodian GCP 实践用 loadbalancer-address 策略按网络层级Network Tier筛选负载均衡地址并推送 Pub/Sub 通知Cloud Custodian GCP 实践用 loadbalancer address 策略按网络层级Network Tier筛选负载均衡地址并推送 P云原生运维安全Cloud Custodian GCP 实战按 TLS 版本删除负载均衡 SSL Policyloadbalancer-ssl-policy 资源与 delete 动作全解析Cloud Custodian GCP 实战按 TLS 版本删除负载均衡 SSL Policyloadbalancer ssl policy 资源与 del云原生运维安全ObjectDetection-OneStageDet性能揭秘为什么YOLOv3能达到79.6% mAPObjectDetection OneStageDet性能揭秘为什么YOLOv3能达到79.6% mAP ObjectDetection OneStageD计算机视觉深度学习创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考