Krane规则模板详解如何编写高效的RBAC风险检测规则【免费下载链接】kraneKubernetes RBAC static analysis visualisation tool项目地址: https://gitcode.com/gh_mirrors/kra/kraneKrane是一个强大的Kubernetes RBAC静态分析工具它通过灵活的规则模板系统帮助您识别Kubernetes集群中的潜在安全风险。 本文将深入讲解Krane规则模板的核心概念、编写方法和最佳实践让您能够创建高效的RBAC风险检测规则。什么是Krane规则模板Krane规则模板是定义RBAC安全检查的核心机制。每个规则模板都包含三个关键部分查询逻辑、严重性级别和修复建议。Krane内置了超过50个预定义规则涵盖了从敏感资源访问到权限升级等常见安全风险场景。规则模板存储在 config/rules.yaml 文件中您可以通过 config/custom-rules.yaml 进行自定义扩展。这种设计让您既能使用开箱即用的安全检测又能根据具体需求定制规则。Krane规则模板的核心结构 每个Krane规则模板都遵循统一的结构包含以下必需和可选字段必需字段id: 规则的唯一标识符group_title: 风险检查的分组标题severity: 严重性级别:danger、:warning、:infoinfo: 风险描述和修复建议可选字段template: 内置查询模板名称query: 自定义RedisGraph查询语句writer: Ruby表达式用于格式化查询结果match_rules: 匹配规则定义threshold: 数值阈值disabled: 是否禁用该规则内置模板详解 ️Krane提供了多种内置模板其中最常用的是risky-role模板。这个模板会根据match_rules配置自动生成复杂的图查询检测具有特定权限的角色。risky-role模板示例- id: risky-get-secrets group_title: 高风险角色允许查看敏感信息 severity: :danger info: 允许查看特定secret的角色可能存在安全风险请审查列出的角色 template: risky-role match_rules: - resources: [secrets] verbs: [get]这个规则会自动检测所有拥有get secrets权限的角色无论这些权限是通过Role还是ClusterRole授予的。其他内置模板privileged-psp-subjects: 检测拥有特权PSP访问权限的主体unrestricted-cluster-wide-subjects: 检测拥有集群范围无限制访问权限的主体rbac-managing-subjects: 检测能够管理RBAC的主体multiple-role-subjects: 检测关联多个角色的主体如何编写自定义规则 ✍️方法一使用内置模板推荐对于大多数场景使用内置模板是最简单的方式。您只需要定义match_rules来指定要检测的权限组合- id: custom-rule-example group_title: 自定义高风险权限检测 severity: :warning info: 检测具有特定危险权限组合的角色 template: risky-role match_rules: - apiGroups: [apps] resources: [deployments, statefulsets] verbs: [delete, patch] threshold: 1方法二编写自定义查询对于更复杂的检测逻辑您可以编写自定义的RedisGraph查询- id: advanced-risk-detection group_title: 高级风险检测 severity: :danger info: 检测具有特定权限模式的复杂风险场景 query: | MATCH (s:Subject)-[:ACCESS]-(ns:Namespace), (s)-[:ASSIGN]-(r:Role)-[:GRANT]-(rule:Rule) WHERE rule.resource pods AND rule.verb exec AND ns.name kube-system RETURN s.kind as subject_kind, s.name as subject_name, ns.name as namespace_name, r.name as role_name writer: | #{result.subject_kind} #{result.subject_name} 可以在 #{result.namespace_name} 命名空间中执行 pod exec 命令 (角色: #{result.role_name})方法三使用宏定义复用逻辑如果您有多个规则共享相同的查询逻辑可以使用宏来避免重复macros: sensitive-resource-check: query: | MATCH (r:Rule {resource: $RESOURCE})-[:GRANT]-(ro:Role)-[:ASSIGN]-(s:Subject) WHERE NOT s.name IN {{whitelist_subject_names}} RETURN s.kind as subject_kind, s.name as subject_name, ro.name as role_name rules: - id: check-sensitive-resource-a group_title: 敏感资源A访问检测 severity: :warning info: 检测对敏感资源A的访问权限 macro: sensitive-resource-check custom_params: - RESOURCE: sensitive-data-a规则编写的最佳实践 1. 合理设置严重性级别:danger: 可能导致直接安全漏洞的权限如*权限、特权提升:warning: 可能存在风险的权限如敏感资源访问:info: 需要关注的权限模式如角色聚合过多2. 使用阈值优化性能对于可能返回大量结果的查询使用threshold字段进行过滤- id: subjects-with-many-roles group_title: 关联多个角色的主体 severity: :info info: 主体关联过多角色可能表明RBAC设计不佳建议进行角色聚合 template: multiple-role-subjects threshold: 4 # 只显示关联4个以上角色的主体3. 利用白名单减少误报通过 config/whitelist.yaml 配置白名单排除已知的安全主体common: risky-get-secrets: whitelist_subject_names: - system:serviceaccount:kube-system:metrics-server - system:serviceaccount:monitoring:prometheus-operator4. 遵循最小权限原则在定义match_rules时尽量具体地指定资源和操作避免过度泛化# 推荐具体指定 match_rules: - resources: [secrets] verbs: [get, list] # 不推荐过度泛化 match_rules: - resources: [*] verbs: [*]实战检测常见RBAC风险 场景1检测特权容器执行权限- id: risky-pod-exec group_title: 危险的Pod执行权限 severity: :danger info: 允许在容器中执行命令的角色可能导致权限提升攻击 template: risky-role match_rules: - resources: [pods/exec] verbs: [create] - resources: [pods] verbs: [get]场景2检测RBAC自提升权限- id: self-rbac-escalation group_title: RBAC自提升权限风险 severity: :danger info: 允许创建角色绑定并绑定特权角色的权限组合 template: risky-role match_rules: - apiGroups: [rbac.authorization.k8s.io] resources: [rolebindings] verbs: [create] - apiGroups: [rbac.authorization.k8s.io] resources: [clusterroles] verbs: [bind]场景3检测敏感资源配置访问- id: sensitive-config-access group_title: 敏感配置访问权限 severity: :warning info: 允许访问敏感配置的角色需要特别审查 template: risky-role match_rules: - resources: [configmaps] resourceNames: [kube-proxy, coredns, kube-controller-manager] verbs: [get, list, watch]调试和测试规则 1. 使用Krane控制台测试查询# 进入Krane容器 docker-compose exec krane bash # 启动控制台 console # 测试自定义查询 graph Krane::Clients::RedisGraph.client cluster: default result graph.query(您的自定义查询语句) puts result2. 验证规则语法在部署规则前使用Krane的验证功能检查规则配置krane report --dry-run --rules config/custom-rules.yaml3. 监控规则执行效果通过Krane仪表板实时查看规则检测结果调整阈值和白名单配置以减少误报。高级技巧组合检测复杂风险模式 检测横向移动风险- id: lateral-movement-risk group_title: 横向移动风险检测 severity: :danger info: 检测可能用于横向移动的权限组合 query: | MATCH (s:Subject)-[:ASSIGN]-(r:Role)-[:GRANT]-(rule1:Rule), (s)-[:ASSIGN]-(r)-[:GRANT]-(rule2:Rule) WHERE (rule1.resource pods AND rule1.verb exec) AND (rule2.resource secrets AND rule2.verb get) RETURN s.kind as subject_kind, s.name as subject_name, r.name as role_name writer: | #{result.subject_kind} #{result.subject_name} 同时拥有执行pod命令和查看secret的权限 (角色: #{result.role_name})检测权限升级链- id: privilege-escalation-chain group_title: 权限升级链检测 severity: :danger info: 检测可能形成权限升级链的权限组合 query: | MATCH (s:Subject)-[:ASSIGN]-(r1:Role)-[:GRANT]-(rule1:Rule), (s)-[:ASSIGN]-(r2:Role)-[:GRANT]-(rule2:Rule) WHERE rule1.resource roles AND rule1.verb create AND rule2.resource * AND rule2.verb * RETURN s.kind as subject_kind, s.name as subject_name, COLLECT(DISTINCT r1.name - r2.name) as escalation_paths writer: | #{result.subject_kind} #{result.subject_name} 可能通过以下路径提升权限: #{result.escalation_paths.join(; )}总结与建议 Krane的规则模板系统提供了强大的RBAC安全检测能力。通过合理利用内置模板、自定义查询和宏定义您可以构建覆盖各种安全场景的检测规则。记住以下关键点从内置模板开始大多数常见场景都可以通过内置模板满足渐进式定制先使用简单规则再根据需要逐步复杂化持续优化根据实际运行结果调整阈值和白名单团队协作将规则配置纳入版本控制便于团队共享和维护通过精心设计的规则模板Krane能够帮助您在Kubernetes环境中建立强大的RBAC安全防线及时发现并修复潜在的安全风险。【免费下载链接】kraneKubernetes RBAC static analysis visualisation tool项目地址: https://gitcode.com/gh_mirrors/kra/krane创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考