云原生运维安全【免费下载链接】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点击查看免费下载IAM Access Key 是 AWS 账户中长期有效的静态凭据也是最常见的云安全治理对象之一。本文基于 cloud-custodian 官方示例文档 docs/source/aws/examples/iamaccesskey.rst讲解如何用 Cloud Custodian 的 YAML 策略对 IAM 访问密钥进行全量枚举、按状态/用户名/创建时间筛选并结合源码剖析iam-access-key资源类型的底层实现与测试验证帮助你快速落地密钥盘点、密钥轮换、密钥清理一类的治理策略。iam-access-key 资源类型源码层面的基本认识在开始写策略之前先理解 Cloud Custodian 是如何把 IAM 访问密钥建模为可查询资源的。在 c7n/resources/iam.py 中AccessKey类通过resources.register(iam-access-key)注册并继承自ChildResourceManager子资源管理器resources.register(iam-access-key) class AccessKey(ChildResourceManager): class resource_type(TypeInfo): service iam # Access keys dont have ARNs - they use AccessKeyId as identifier # Using access-key as arn_type for consistency but ARN construction will not be used arn_type access-key id name AccessKeyId date CreateDate # Denotes this resource type exists across regions global_resource True enum_spec (list_access_keys, AccessKeyMetadata, None) parent_spec (iam-user, UserName, None) # No detail spec needed as list_access_keys returns full metadata cfn_type AWS::IAM::AccessKey这段源码揭示了几个关键实现事实枚举方式enum_spec (list_access_keys, AccessKeyMetadata, None)即直接调用 IAM 的list_access_keysAPI返回体中的AccessKeyMetadata作为资源集合无需额外的 detail 调用。资源标识访问密钥没有 ARN使用AccessKeyId作为主键与名称字段id name AccessKeyId。父子关系parent_spec (iam-user, UserName, None)访问密钥以 IAM 用户为父资源按UserName关联这意味着密钥枚举依赖账户内用户清单。全局资源global_resource TrueIAM 是全局服务密钥不分区策略在任意区域执行结果一致。时间字段date CreateDate为后面按密钥年龄过滤提供了标准字段。在 c7n/resources/resource_map.py 中资源类型aws.iam-access-key被映射到c7n.resources.iam.AccessKey因此策略中的resource: iam-access-key会被正确解析并加载。每条访问密钥资源默认包含的字段与 AWS API 返回一致AccessKeyId、UserName、StatusActive / Inactive、CreateDate这些字段正是下面各筛选策略的操作对象。策略一列出账户内全部 IAM 访问密钥官方文档给出的第一个示例是最基础的全量盘点策略——不做任何筛选列出所有访问密钥policies: - name: all-iam-access-keys resource: iam-access-key执行后Cloud Custodian 会遍历账户内全部 IAM 用户汇总所有AccessKeyMetadata记录。这在以下场景中非常实用作为密钥盘点的基线输出配合-s指定输出目录如custodian run -c policy.yml -s .生成资源清单作为后续治理流程的上游输入例如先全量枚举、再在报告中人工核对。该策略对应的测试用例见 tests/test_iam.py 中的test_access_key_list测试通过 placebo 回放list_access_keys的飞行数据断言返回两条资源并逐一校验每条资源都包含AccessKeyId、UserName、Status、CreateDate四个关键字段def test_access_key_list(self): Test basic enumeration of access keys. factory self.replay_flight_data(test_iam_access_key_list) p self.load_policy( {name: iam-access-key-list, resource: iam-access-key}, session_factoryfactory, ) resources p.run() self.assertTrue(len(resources) 2) for resource in resources: # Verify required fields are present self.assertIn(AccessKeyId, resource) self.assertIn(UserName, resource) self.assertIn(Status, resource) self.assertIn(CreateDate, resource)这从测试侧印证了一条策略即可拿到密钥的完整元数据也是后续所有筛选逻辑的数据基础。策略二按密钥状态筛选只保留 Active 密钥AWS 的访问密钥状态只有两种Active启用与Inactive禁用。官方文档的第二个示例用value过滤器精确匹配状态字段policies: - name: active-iam-access-keys resource: iam-access-key filters: - type: value key: Status value: Activetype: value是 Cloud Custodian 最核心的通用值过滤器语法由ValueFilter实现位于 c7n/filters/core.py。它按key从资源字典中取值与value做比较默认比较操作符为相等op: eq因此本例等价于只保留Status Active的密钥。治理上的典型用法安全审计找出仍处于 Active 状态的长期密钥评估其轮换必要性反向排查把value: Inactive与最近使用时间类数据结合确认是否有大量僵尸密钥占用了 IAM 配额每个用户最多 2 个访问密钥。策略三按用户名筛选定位特定用户的密钥第三个示例将筛选对象落到具体用户适合按人治理的场景——例如只关注某个离职员工、特权账号或特定服务账号的密钥policies: - name: iam-access-keys-for-user resource: iam-access-key filters: - type: value key: UserName value: insert-username-here使用时将insert-username-here替换为真实用户名。注意这里的匹配是精确相等若希望做前缀/模糊匹配可以把op换成contains、starts-with等操作符由ValueFilter支持的操作符集提供。例如只查svc-前缀的服务账号密钥policies: - name: service-account-access-keys resource: iam-access-key filters: - type: value key: UserName op: starts-with value: svc-由于密钥枚举本身依赖父资源iam-user用户名过滤也可以视为在用户清单 × 密钥元数据结果集上的投影适合做分账号、分角色的密钥报表。策略四按创建时间过滤找出超过 90 天的旧密钥长期不轮换的密钥是凭据泄露与合规风险的高发点。官方文档的第四个示例利用value_type: age把CreateDate转换为已存在天数再与阈值比较policies: - name: old-iam-access-keys resource: iam-access-key filters: - type: value key: CreateDate value_type: age value: 90 op: greater-than语义解读仅保留创建时间距今超过 90 天的密钥。value_type: age会自动把日期字段折算为以天为单位的年龄op: greater-than表示大于。这套组合是 Cloud Custodian 中按资源年龄治理的标准写法同样适用于 AMI、快照、日志组等带时间戳的资源。对应的官方测试用例位于 tests/test_iam.py 的test_access_key_filter_by_age使用freezegun.freeze_time(2020-02-02)冻结当前时间再执行策略验证年龄过滤在固定时间基准下的筛选结果def test_access_key_filter_by_age(self): Test filtering access keys by age. factory self.replay_flight_data(test_iam_access_key_filter_age) p self.load_policy( { name: iam-access-key-old, resource: iam-access-key, filters: [ { type: value, key: CreateDate, value_type: age, value: 90, op: greater-than, } ], }, session_factoryfactory, ) with freezegun.freeze_time(2020-02-02): resources p.run() # Just check that we can run this without error # The actual age filter logic is handled by C7N core self.assertTrue(len(resources) 1)测试注释明确指出age 过滤逻辑由 C7N 核心实现即ValueFilter的value_type: age解析逻辑策略层只需声明字段与阈值即可。调整value的数值就能得到30 天未轮换180 天未轮换等不同强度的治理口径。进阶密钥治理的完整闭环思路iam-access-key资源在官方文档定位为枚举 筛选即先看清账户内密钥的全貌。若要形成发现即处置的闭环可以结合同一源码仓库中与密钥相关的实现用户级密钥过滤器在 c7n/resources/iam.py 中UserAccessKey注册名为access-key允许直接在iam-user资源上按密钥属性筛选用户并支持match-operator: and|or组合多个密钥条件。典型场景找出拥有 Active 密钥且密钥创建超过 90 天的用户再对该用户执行处置动作。相比iam-access-key的逐条筛选这种写法以用户为治理单元更贴近账号级整改的操作习惯policies: - name: iam-users-with-active-keys resource: iam-user filters: - type: access-key key: Status value: Active - type: access-key match-operator: and key: CreateDate value_type: age value: 90删除用户时的级联清理在 c7n/resources/iam.py 的delete_access_keys辅助函数中删除 IAM 用户前会先调用list_access_keys列出其全部密钥并逐个delete_access_key。这保证用户资源的delete动作不会因残留密钥而失败也从侧面说明了密钥治理与用户生命周期管理的关联性。密钥禁用/轮换的底层能力在 c7n/resources/iam.py 附近可以看到对update_access_key与delete_access_key的调用逻辑用于标记、禁用、删除密钥这些是构建旧密钥自动禁用或删除动作时可复用的底层 API 调用模式。需要说明的是从当前仓库源码看iam-access-key资源类型本身主要承载枚举与筛选自动处置禁用/删除/轮换建议通过iam-user资源上的access-key过滤器配合对应动作或基于c7n:matched-keys注解见UserAccessKey中的matched_annotation_key自定义动作实现确保策略行为与 IAM 权限模型一致。运行与验证策略文件编写完成后按 Cloud Custodian 的标准方式运行详细命令与参数见 docs/source/aws/usage.rstcustodian run -c iam-access-key.yml -s output-c指定策略文件路径-s指定输出目录运行结束后会生成包含匹配资源明细的resources.json执行策略所需的 IAM 权限至少包括iam:ListUsers枚举父资源与iam:ListAccessKeys枚举密钥该权限也明确声明在UserAccessKey过滤器的permissions中见 c7n/resources/iam.py。若希望做本地验证而不触碰真实账户可参照 tests/test_iam.py 的测试写法使用 placebo 回放录制的 AWS 响应对应tests/data/placebo下的飞行数据目录通过replay_flight_data构造 session 后直接调用p.run()断言结果实现策略逻辑的可重复回归测试。小结围绕官方示例文档本文完整覆盖了iam-access-key资源的四种基础策略全量枚举、按状态Active/Inactive筛选、按用户名筛选、按创建年龄90 天以上筛选并从 c7n/resources/iam.py 的注册源码与 tests/test_iam.py 的测试用例两个维度确认了资源字段、API 调用与过滤语义。把这四类策略组合进日常巡检即可形成一套可落地的密钥盘点 → 风险定位 → 整改处置治理链路为云账户凭据安全提供持续保障。赞分享云原生运维安全【免费下载链接】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 DNS 托管区治理用 YAML 策略检查并启用 DNSSECCloud Custodian 的 GCP DNS 托管区治理用 YAML 策略检查并启用 DNSSEC 本文围绕 Cloud Custodianc7n在云原生运维安全Cloud Custodian GCP 指南用 YAML 策略清点、过滤与治理 Vertex AI EndpointCloud Custodian GCP 指南用 YAML 策略清点、过滤与治理 Vertex AI Endpoint 本文以 Cloud Custodian云原生运维安全Cloud Custodian IAM 策略管理实战用 set-policy 自动化附加/分离角色托管策略Cloud Custodian IAM 策略管理实战用 set policy 自动化附加/分离角色托管策略 本文基于 Cloud Custodian 官方示例云原生运维安全上一篇DynamicCow 实战如何在 iOS 16 的老机型上解锁灵动岛下一篇ai-memory 扩展事件词汇表extension 命名空间完全使用指南创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考