equinor/radix-vulnerability-scanner

 # radix-vulnerability-scanner ## 简介 `radix-vulnerability-scanner` 会扫描 `RadixDeployment` CRD 中定义的 Docker 镜像以查找漏洞，并将结果存储在数据库中。扫描会在创建或更新新的 RadixDeployment 资源时，以及根据 cron spec 定义的计划触发。仅扫描处于活跃状态的 RadixDeployment 中的镜像。一旦某个镜像被扫描过，在上次扫描时长超过一定阈值（默认为 24 小时）之前，它不会被重新扫描。 ## 安装说明 `radix-vulnerability-scanner` 的安装由 Flux 通过 [Radix Flux](https://github.com/equinor/radix-flux) 处理。Flux 的前置条件由 Terraform 的 [Vulnerability Scanner module](https://github.com/equinor/radix-platform/tree/master/terraform/subscriptions/s941/dev/vulnerability-scanner)（在每个环境中）进行引导。 ### Azure 资源 `radix-vulnerability-scanner` 将扫描结果存储在 SQL Server 数据库中。数据库和 schema 使用 Github actions 进行部署。 ### 数据库权限 配置用于连接 SQL Server 的用户必须是 `radixwriter` 数据库角色的成员，并使用 Azure `ActiveDirectoryDefault` 配置文件通过 managed identity 进行身份验证。 - 在每个环境中运行 Vulnerability Scanner Terraform module 以设置 Managed Identities。 - 记下所有更改过的 CLIENT-ID： - `radix-id-vulnerability-scan-admin-` 必须添加到本项目的 `./.github/workflows/build-push.yml` 中 - `radix-id-vulnerability-scan-github-` 必须添加到本项目的 `./.github/workflows/deploy-database.yml` 中 - `radix-id-vulnerability-scan-reader-` 必须添加到 https://github.com/equinor/radix-vulnerability-scanner-api 中每个环境的 Radixconfig.yaml 文件中 - `radix-id-vulnerability-scan-writer-` 必须添加到 `https://github.com/equinor/radix-flux/blob/master/clusters/development/postBuild.yaml` 的 `VULNERABILITY_SCANNER_SQL_CLIENT_ID` 中 - 查看 https://github.com/equinor/radix-vulnerability-scanner/issues/54 了解有关部署角色和外部用户的特殊注意事项。 ## 配置 **命令行参数** | 名称 | 类型 | 必填 | 描述 | 默认值 | | ---- | ---- | -------- | ----------- | ------- | | full-sync-cron-spec | string | 否 | 定义所有镜像应多久安排一次扫描的 Cron spec | "0 0 * * *" | | app-name-exclude-list | string \| list | 否 | 要从扫描中排除的 Radix 应用程序名称列表，以逗号分隔 | "" | | workers | number | 否 | 扫描镜像的并发 worker 数量 | 1 | | db-server | string | 是 | 存储扫描结果的 SQL Server 的名称/URL | "" | | db-database | string | 是 | 存储扫描结果的 SQL Server 数据库名称 | "" | | vulnerability-scan-timeout | string | 否 | 每个镜像扫描的 context 超时时间 | "5m" | | vulnerability-rescan-age | string | 否 | 定义在执行新扫描前镜像扫描的最小间隔时间。如果上次扫描的时间小于此值，则不会扫描该镜像 | "24h" | | docker-config-file | string | 否 | docker 文件的路径，包含用于访问私有镜像仓库的认证信息 | "" | | kube-config-file | string | 否 | 用于访问 K8s API 服务器的 Kubernetes 配置文件路径。如果省略此文件，将使用 InClusterConfig | "" | 每个命令行参数都可以通过添加 `RVS_` 前缀、大写并将连字符 (`-`) 替换为下划线 (`_`) 的方式指定为环境变量，例如，`full-sync-cron-spec` 会变为 `RVS_FULL_SYNC_CRON_SPEC`。 ## 开发流程 `radix-vulnerability-scanner` 项目遵循 **主干开发（trunk-based development）** 方法。 ### 🔁 工作流 - **外部贡献者**应该： - Fork 该仓库 - 在他们的 fork 中创建一个 feature 分支 - **维护者**可以直接在主仓库中创建 feature 分支。 ### ✅ 合并更改 所有更改必须通过带有 **squash commits** 的 **pull requests** 合并到 `main` 分支中。 Squash commit 消息必须遵循 [Conventional Commits](https://www.conventionalcommits.org/en/about/) 规范。 ## 发布流程 将 pull request 合并到 `main` 会触发 **Prepare release pull request** 工作流。 此工作流会分析 commit 消息，以确定是否应该提升版本号 —— 如果需要，还要确定是 major、minor 还是 patch 更改。 然后它会创建两个 pull request： - 一个用于新的稳定版本（例如 `1.2.3`），以及 - 一个用于追加了 `-rc.[number]` 的预发布版本（例如 `1.2.3-rc.1`）。 合并其中任何一个 pull request 都会触发 **Create releases and tags** 工作流。 此工作流会读取存储在 `version.txt` 中的版本号，创建 GitHub release，并相应地打上 tag。 新的 tag 会触发 **Build and deploy Docker and Helm** 工作流，该工作流会： - 构建并向 `ghcr.io` 推送新的容器镜像和 Helm chart，并 - 将 Helm chart 作为 artifact 上传到相应的 GitHub release 中。 ### 生成 Mock 我们使用 gomock 生成单元测试中使用的 mock。 如果您对应用程序使用的任何 interface 类型进行了更改，则需要重新生成 mock。 ``` make mocks ``` ### 本地调试 复制 .env.template 并将其命名为 .env。设置变量以允许本地调试。此文件会被 git 忽略。 ## 安全性 这是我们处理 [安全问题](./SECURITY.md) 的方式

标签：DevSecOps, EVTX分析, Web截图, 上游代理, 子域名突变, 容器安全, 日志审计, 请求拦截