Prowler Provider 扩展完全指南新增云厂商 Provider 与 Service 的架构模式与实现模板【免费下载链接】prowlerProwler is the world’s most widely used open-source cloud security platform that automates security and compliance across any cloud environment.项目地址: https://gitcode.com/GitHub_Trending/pr/prowler本篇技术指南以 Prowler 官方技能文档 skills/prowler-provider/SKILL.md 为骨架系统讲解如何在 Prowler 中新增云 Provider如 AWS、Azure、GCP 之外的任意云平台以及为已有 Provider 添加新的 Service。读完本文你将掌握 Provider 的标准目录结构、SDK/API/Tool/Hybrid 四种类型判定方法、敏感 CLI 参数的安全规范、Provider 主类与 Service 类/Client 单例的代码模板以及用于验证扩展成果的 CLI 命令并能在 docs/developer-guide/provider.mdx 与 docs/developer-guide/services.mdx 中继续深入。何时使用该扩展技能根据技能文档的定位这个扩展路径面向以下三类场景新增一个云 Provider 到 Prowler目标平台尚未被 Prowler 支持需要从零搭建认证、身份、区域与服务发现能力为已有 Provider 添加新的 ServiceProvider 已存在如 GitHub但某个资源域如仓库、组织、审计日志尚未被采集需要新增服务类与检查项理解 Provider 架构模式作为开发者学习 Prowler 多 Provider 抽象层的统一设计为后续贡献或二次开发打基础。技能的触发场景明确限定为扩展 Prowler SDK Provider 架构因此不涉及修改已有检查逻辑或合规框架聚焦于 Provider/Service 两个层次。Provider 目录架构模式所有 Provider 必须遵循统一的目录结构。该结构是 docs/developer-guide/provider.mdx 中 SDK/API/Tool 三种实现路线的公共骨架确保 CLI、API 与 UI 能按约定自动发现 Providerprowler/providers/{provider}/ ├── __init__.py ├── {provider}_provider.py # Main provider class ├── models.py # Provider-specific models ├── config.py # Provider configuration ├── exceptions/ # Provider-specific exceptions ├── lib/ │ ├── service/ # Base service class │ ├── arguments/ # CLI arguments parser │ └── mutelist/ # Mutelist functionality └── services/ └── {service}/ ├── {service}_service.py # Resource fetcher ├── {service}_client.py # Python singleton instance └── {check_name}/ # Individual checks ├── {check_name}.py └── {check_name}.metadata.json各组成部分的职责如下组件职责{provider}_provider.py主 Provider 类继承公共基类负责认证、会话、身份与区域管理models.pyProvider 专属的数据结构身份信息、会话对象、输出选项等config.pyProvider 配置AWS 的prowler/providers/aws/config.py即属此类exceptions/结构化异常体系携带错误码、消息与补救建议lib/arguments/CLI 参数解析与校验含SENSITIVE_ARGUMENTS敏感参数集合lib/mutelist/资源/检查的静默mute与排除功能lib/service/该 Provider 所有 Service 继承的基类services/{service}/具体服务资源拉取、Client 单例与检查项开发者指南进一步指出lib/regions/目录仅在 Provider具有区域概念时才需要创建例如 AWS 有prowler/providers/aws/lib/regions/而 GitHub 没有区域不创建该目录。Tool/Wrapper 型 Provider 的目录则更精简通常只包含__init__.py、{provider}_provider.py、models.py与lib/arguments/。Provider 类型判定SDK / API / Tool / Hybrid在动手写代码前必须先研究目标平台的数据获取方式据此判定 Provider 类型。开发者指南给出了完整的决策标准选择 SDK 型目标平台有官方且维护良好的 Python SDK需要支持多种认证方式profile、service principal、IAM role 等SDK 自带会话管理、重试与错误处理典型如 AWSboto3、Azureazure-identity、GCPgoogle-auth、Kubernetes。选择 API 型平台只有 REST API 而没有官方 Python SDK需要自行实现 OAuth/Token 等自定义认证流用requests直接发起 HTTP 调用并手工处理分页、限流与错误典型如 NHN Cloud、MongoDB Atlas。选择 Tool/Wrapper 型集成的是第三方安全工具或库如 IaC Provider 封装 Trivy工具自身处理认证与扫描无需会话管理核心工作是参数映射与输出格式转换。Hybrid 混合型组合多种模式实现复杂度最高。文档明确给出两个实例M365 使用 msgraph SDK 做认证、用 PowerShell wrapper 执行部分检查GitHub 使用非官方 PyGithub SDK已更新维护叠加官方 GraphQL API 请求——这与 skills/prowler-provider/assets/provider.py 中 GitHub 模板的定位一致。决策流程可归纳为四问有官方 Python SDK 吗有非官方但维护良好的 SDK 吗是第三方安全工具吗暴露 REST API 吗依次回答即可落入对应类型。实现复杂度上SDK 型最低有 AWS/Azure/GCP 等成熟范例可参照API 型中等Tool/Wrapper 与 Hybrid 最高。区域型 vs 非区域型架构类型判定之后还需决定 Provider 是区域型还是非区域型全局这直接影响服务与检查的执行模型维度区域型AWS/Azure/GCP非区域型GitHub/M365/KubernetesClient 初始化每个区域一个 client单个全局 client资源发现遍历区域迭代发现单次发现调用资源 ARN/ID必须包含区域信息全局标识或 None审计执行多区域循环单次执行服务架构区域感知服务全局服务区域型 Provider 通过lib/regions/{provider}_regions.py提供区域列表与校验AWS 还会在运行时调用describe_regions动态获取账号已启用区域。区域服务建议使用__threading_call__按区域并行化资源发现保证单区域故障不影响其他区域这也是 docs/developer-guide/services.mdx 中强调的最佳实践。敏感 CLI 参数安全规范Provider 的 CLI 参数中凡是接受密钥的 flagToken、密码、API Key必须遵守四条强制规则这是技能文档的核心安全约束也在真实源码中得到了完整落实使用nargs?配合defaultNoneflag 可带可不带值用于向后兼容推荐路径是改用环境变量metavar设置为环境变量名直接告知用户应使用的环境变量如metavarGITHUB_PERSONAL_ACCESS_TOKEN将 flag 加入arguments.py顶部的SENSITIVE_ARGUMENTSfrozensetProwler 会自动发现该集合用于在 HTML 输出中脱敏并对在命令行直接传密钥的用户给出警告不新增要求以 CLI 值传递密钥的参数密钥应来自环境变量flag 保留取值能力仅为向后兼容。标准实现模式来自技能文档# prowler/providers/{provider}/lib/arguments/arguments.py SENSITIVE_ARGUMENTS frozenset({--my-api-key, --my-password}) def init_parser(self): auth_subparser parser.add_argument_group(Authentication Modes) auth_subparser.add_argument( --my-api-key, nargs?, defaultNone, metavarMY_API_KEY, helpAPI key for authentication. Use MY_API_KEY env var instead of passing directly., )真实仓库中的 prowler/providers/github/lib/arguments/arguments.py 就是这一规范的落地实例SENSITIVE_ARGUMENTS frozenset({--personal-access-token, --oauth-app-token}) # ... github_auth_subparser.add_argument( --personal-access-token, nargs?, helpPersonal Access Token to log in against GitHub, defaultNone, metavarGITHUB_PERSONAL_ACCESS_TOKEN, )开发者指南还补充了警告不允许新增没有环境变量兜底的、直接以 CLI 值传密钥的参数——Prowler CLI 会对敏感 flag 收到显式值的情况发出提示引导用户改用环境变量。Provider 主类模板Provider 主类继承自prowler.providers.common.provider.Provider负责认证会话、身份信息、审计配置与 mutelist 的初始化。技能文档给出骨架模板from prowler.providers.common.provider import Provider class {Provider}Provider(Provider): Provider class for {Provider} cloud platform. def __init__(self, arguments): super().__init__(arguments) self.session self._setup_session(arguments) self.regions self._get_regions() def _setup_session(self, arguments): Provider-specific authentication. # Implement credential handling pass def _get_regions(self): Get available regions for provider. # Return list of regions pass在此基础上skills/prowler-provider/assets/provider.py 给出了基于 GitHub Provider 的完整模板揭示了抽象基类要求实现的关键属性和初始化流程必需属性_typeProvider 标识、_session认证凭据、_identity已认证用户信息、_audit_config检查配置、_mutelist发现过滤初始化五步setup_session()建立认证会话 →setup_identity()获取身份 → 加载审计配置优先config_content否则读取配置文件→ 加载 fixer 配置 → 加载 mutelist同样支持内容或路径两种方式关键动作Provider.set_global_provider(self)将实例注册为全局 Provider这是后续所有 Service 单例能够访问到它的前提公开方法type/session/identity/audit_config/mutelist属性、print_credentials()打印凭据摘要、静态方法test_connection()验证凭据连通性并返回Connection对象。开发者指南进一步给出 SDK 型 Provider 的完整写法包括load_and_validate_config_file加载审计配置、get_default_mute_file_path获取默认 mutelist 路径以及在setup_session中按参数组合选择认证方式client credentials / profile / 默认凭据链等实现细节。Service 类与 Client 单例模式Service 类模板每个 Service 封装某类资源的全部数据采集逻辑。技能文档的模板如下from prowler.providers.{provider}.lib.service.service import {Provider}Service class {Service}({Provider}Service): Service class for {service} resources. def __init__(self, provider): super().__init__(provider) self.{resources} [] self._fetch_{resources}() def _fetch_{resources}(self): Fetch {resource} data from API. try: response self.client.list_{resources}() for item in response: self.{resources}.append( {Resource}( iditem[id], nameitem[name], regionitem.get(region), ) ) except Exception as e: logger.error(fError fetching {resources}: {e})skills/prowler-provider/assets/service.py 展示了更贴近生产的实现模式核心要点包括基类职责接收 provider 实例、在__set_clients__()中创建 API client、保存audit_config与fixer_config供检查访问急切加载eager loadingService 在__init__阶段就完成全部数据拉取并存入属性之后检查执行期间不再发起 API 调用Pydantic 模型每个资源定义BaseModel数据类如Repo可加Optional字段并设置frozen True使其可哈希、可作字典键。Client 单例模板from prowler.providers.{provider}.services.{service}.{service}_service import {Service} {service}_client {Service}真实实现prowler/providers/github/services/repository/repository_client.py展示的是完整形态from prowler.providers.common.provider import Provider from prowler.providers.github.services.repository.repository_service import Repository # SINGLETON: Instantiated once when module is first imported # Provider.get_global_provider() returns the provider set in __init__ repository_client Repository(Provider.get_global_provider())这个单例模式是 Prowler 检查访问服务数据的关键机制模块首次被导入时服务即被实例化一次并完成数据预取所有检查通过from ...repository_client import repository_client导入该单例直接访问预取数据无需在检查执行阶段做额外 API 调用。检查中的典型用法如下for repo in repository_client.repositories.values(): report CheckReportGithub(metadataself.metadata(), resourcerepo) report.status PASS if repo.secret_scanning_enabled else FAIL服务间通信约束docs/developer-guide/services.mdx 强调了一条架构铁律每个 Service 只能包含自身独有的信息跨服务通信必须通过对方的 Client 对象禁止直接访问其他服务的数据结构。例如 CloudTrail 检查需要校验 S3 桶配置时应导入s3_client而非s3_service遇到跨账号或超出审计范围的资源时优雅地置为MANUAL状态并提示人工核查。服务创建完成后可用--list-services命令验证注册是否成功。当前支持的 Provider 与常用命令技能文档列出的当前 Provider 包括AWS、Azure、GCP、Kubernetes、GitHub、M365、OracleCloud、AlibabaCloud、Cloudflare、MongoDB Atlas、NHN社区维护的非官方 Provider、LLM语言模型 Provider、IaC基础设施即代码。这些目录均可在 prowler/providers/ 下找到真实实现作为参考范例。新增或调试 Provider 时常用的验证命令如下# 运行指定 Provider uv run python prowler-cli.py {provider} # 列出 Provider 支持的服务 uv run python prowler-cli.py {provider} --list-services # 列出 Provider 的检查项 uv run python prowler-cli.py {provider} --list-checks # 只运行指定服务 uv run python prowler-cli.py {provider} --services {service} # 调试模式输出 DEBUG 日志 uv run python prowler-cli.py {provider} --log-level DEBUG服务创建后可用uv run python prowler-cli.py provider --list-services | grep new_service_name快速确认新服务已被识别详见 docs/developer-guide/services.mdx。深入阅读与实现全流程本技能的资源清单指向了仓库内完整的开发者指南docs/developer-guide/provider.mdxProvider 架构与从零创建完整流程覆盖 SDK/API/Tool/Wrapper 三种路线的分步实现结构创建、Provider 类、Models、Arguments、Mutelist、Regions、Exceptions、Service 基类以及 CLI/Main/Config/Compliance/Output/HTML/CheckReport/依赖/测试/文档等注册环节还有 AWS 区域发现的真实代码示例docs/developer-guide/services.mdx为已有 Provider 新增 Service 的详细指南包括 Service 类结构、Pydantic 资源模型、字典化存储以唯一 ID 为键、O(1) 查找、跨服务通信模式与区域服务的并行化最佳实践。配合 skills/prowler-provider/assets/ 下的 Provider/Service/Client 三份完整模板以及 skills/prowler-provider/references/provider-docs.md 中各 Provider 的实现细节文档AWS、Azure、GCP、Kubernetes、GitHub、M365、AlibabaCloud、LLM 等即可按模板逐步落地一个新 Provider 的完整闭环目录结构 → 主类 → 模型 → 参数 → 异常 → 服务 → 注册 → 检查 → 输出 → 测试。【免费下载链接】prowlerProwler is the world’s most widely used open-source cloud security platform that automates security and compliance across any cloud environment.项目地址: https://gitcode.com/GitHub_Trending/pr/prowler创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
