> ## Documentation Index
> Fetch the complete documentation index at: https://docs.flashduty.com/llms.txt
> Use this file to discover all available pages before exploring further.

# StackRox 告警集成

> 通过 Generic Webhook 将 StackRox（Red Hat Advanced Cluster Security for Kubernetes）的策略违规告警同步到 Flashduty On-call。

通过 StackRox（Red Hat Advanced Cluster Security for Kubernetes，简称 RHACS）Central 的 Generic Webhook 通知集成，将策略违规告警同步到 Flashduty On-call。每条 StackRox 告警（`alert.id`）对应一条 Flashduty 告警。StackRox 不会为通用 Webhook 发送“已解决”通知，因此这些告警不会自动恢复，需要在协作空间中开启超时自动关闭。

<div className="hide">
  ## 在 Flashduty On-call

  ***

  您可通过以下两种方式获取集成推送地址，任选其一即可。

  ### 使用专属集成

  1. 进入 Flashduty 控制台，选择 **协作空间**，打开一个协作空间
  2. 选择 **配置** → **集成数据** → **专属集成**，点击 **新增一个集成**
  3. 选择 **StackRox**，点击 **保存**
  4. 打开生成的集成卡片，复制 **推送地址**

  ### 使用共享集成

  1. 进入 Flashduty 控制台，选择 **集成中心 → 告警事件**
  2. 选择 **StackRox**，填写集成名称
  3. 配置默认路由并选择协作空间；创建后可在 **路由** 中增加更多规则
  4. 点击 **保存**，复制生成的 **推送地址**
</div>

## 在 StackRox 中配置

***

需要在 RHACS 中拥有创建通知集成和修改策略的权限。Central 必须能通过 HTTPS 访问 Flashduty 推送地址。

<Steps>
  <Step title="创建 Generic Webhook 集成">
    1. 在 RHACS 门户中进入 **Platform Configuration → Integrations**
    2. 在 **Notifier Integrations** 中选择 **Generic Webhook**，点击 **New integration**
    3. 填写 **Integration name**
    4. 将 Flashduty 集成的完整推送地址粘贴到 **Endpoint**，地址中需包含 `integration_key`
    5. **CA certificate** 和 **Skip TLS verification** 保持默认；Flashduty 使用公共证书，不需要设置
    6. 不要勾选 **Enable audit logging**：审计日志通知使用另一种请求体，Flashduty 收到后只返回成功，不会创建告警
    7. 需要区分来源时，在 **Extra fields** 中添加键值对（例如 `source` = `rhacs`），Flashduty 会忽略这些字段
    8. 点击 **Test**，再点击 **Create**
  </Step>

  <Step title="在策略上启用通知">
    1. 进入 **Platform Configuration → Policy Management**
    2. 选择需要通知的策略，通过批量操作将该 Generic Webhook 设为策略的通知渠道

    只有启用了通知渠道的策略产生的告警才会推送到 Flashduty。
  </Step>

  <Step title="开启超时自动关闭">
    StackRox 的 Generic Webhook 只在告警产生时推送一次，不会在违规被解决时再推送，所以 Flashduty 中的告警不会自动恢复。请在接收这些告警的协作空间中开启 [超时自动关闭](/zh/on-call/channel/create-edit)，计时起点选择 **故障触发**，超时时长建议设置为 **24 小时**。同一个部署上的违规被解决后再次出现时，StackRox 会生成新的告警并再次推送，Flashduty 会重新打开一条告警。
  </Step>

  <Step title="验证">
    Generic Webhook 集成页面上的 **Test** 按钮会发送一条 ID 为 `testalert` 的测试告警。Flashduty 会返回成功，但不会创建告警。要验证完整流程，请在已启用通知的策略上制造一次真实违规（例如部署一个使用 `latest` 标签镜像的工作负载并启用 **Latest tag** 策略），确认 Flashduty 收到告警。
  </Step>
</Steps>

## Alert Key

***

Flashduty 使用 StackRox 告警的 ID（请求体中的 `alert.id`）作为 Alert Key。StackRox 官方文档说明每条告警只推送一次：违规首次出现在某个部署上，或者该部署上此前的运行时告警被解决后再次出现时，才会产生新的推送。因此每次推送对应一条独立的告警，不同告警的 Alert Key 不同；如果 StackRox 对同一条告警重复推送，这些推送会合并到同一条 Flashduty 告警。

策略名称、严重程度、违规内容和时间的变化都不会改变 Alert Key。缺少 `alert.id` 的请求会被拒绝。

## 状态和告警等级

***

Flashduty 按策略的严重程度（`alert.policy.severity`）映射告警等级：

| StackRox 严重程度 | Flashduty 等级 |
| :- | :- |
| `CRITICAL_SEVERITY` | Critical |
| `HIGH_SEVERITY` | Warning |
| `MEDIUM_SEVERITY` | Warning |
| `LOW_SEVERITY` | Info |
| 未设置或其他值 | Warning |

如需让高危策略也以 Critical 通知，可以在 Flashduty 中通过路由或告警处理规则按 `policy_severity` 标签调整。

## 标签

***

| 标签 | 来源 |
| :- | :- |
| `alert_id` | StackRox 告警 ID，即 Alert Key |
| `policy` | 策略名称，同时作为告警标题 |
| `policy_severity` | 策略严重程度 |
| `lifecycle_stage` | 策略生命周期阶段（`BUILD`、`DEPLOY`、`RUNTIME`） |
| `cluster` | 集群名称 |
| `namespace` | 命名空间 |
| `resource` | 触发告警的部署、镜像、资源或节点名称 |
| `state` | 告警状态（如 `ATTEMPTED`），处于默认的活动状态时该字段为空 |
| `source` | 固定为 `stackrox` |

违规详情（`alert.violations[].message`）写入告警描述。

## 排查问题

***

* **Central 显示推送失败**：确认 Endpoint 完整且包含 `integration_key`，Central 所在网络能访问 Flashduty
* **Test 成功但没有告警**：Test 发送的是 `testalert`，不会创建告警；请确认策略已启用通知渠道，并制造一次真实违规
* **告警没有恢复**：这是预期行为，请开启协作空间的超时自动关闭，或在 Flashduty 中手动关闭
* **收到多条相似的告警**：每条 StackRox 告警对应一条 Flashduty 告警；同一策略在不同部署上的违规是不同的告警

更多字段含义请参阅 [Red Hat：使用 Generic Webhook 集成](https://docs.redhat.com/en/documentation/red_hat_advanced_cluster_security_for_kubernetes/4.6/html/integrating/integrate-using-generic-webhooks)。