fix(connectivity): 改接 kimi(LLM_API_KEY1)+ allowlist 折叠假绿修复(ADR-0048,#258 关联) - #93
Conversation
…list 折叠假绿(补块标量,降 audit)
|
Warning Review limit reachedNext included review available in 4 minutes. View limit detailsLimit details: You’ve used all 10 included reviews currently available. Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. Review configuration: ⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (1)
Comment |
PR Summary by QodoFix LLM connectivity workflow for Kimi secrets/vars and harden-runner allowlist parsing
AI Description
Diagram
High-Level Assessment
Files changed (1)
|
Code Review by Qodo
1. Allowlist not enforced
|
| egress-policy: audit | ||
| allowed-endpoints: | |
There was a problem hiding this comment.
1. Allowlist not enforced 🐞 Bug ⛨ Security
The workflow sets egress-policy: audit, which does not block outbound traffic; allowed-endpoints is only applied when the policy is block, so the job still has unrestricted egress despite the allowlist block-scalar fix. This can reintroduce a “looks configured but not actually enforcing” outcome for INV-06, just in a different form (audit-only).
Agent Prompt
### Issue description
`step-security/harden-runner` is configured with `egress-policy: audit`, which does not enforce the endpoint allowlist. The action’s `allowed-endpoints` input only takes effect when `egress-policy` is `block`, so the workflow currently does not actually restrict outbound egress.
### Issue Context
This PR explicitly aims to fix an allowlist “假绿” (policy not effective). However, changing to audit mode means the allowlist still won’t be enforced; it will only be observed/logged.
### Fix Focus Areas
- .github/workflows/llm-connectivity.yml[36-48]
### Suggested fix
Pick one approach:
1) **Restore enforcement:** set `egress-policy: block` and expand `allowed-endpoints` to include all domains needed by `actions/checkout` and subsequent steps (or use a baseline policy), OR
2) **Preserve enforcement without breaking checkout:** move the `harden-runner` step *after* `actions/checkout` so the initial git fetch isn’t subject to the block policy, then run the rest of the job under `block` with a complete allowlist.
If audit mode is truly required by org constraints, add an explicit guardrail (e.g., parse harden-runner’s audit output and fail if any endpoint outside the allowlist is contacted), so the job can still detect drift rather than silently allowing it.
ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools
| LLM_API_KEY: ${{ secrets.LLM_API_KEY1 }} | ||
| LLM_BASE_URL: ${{ vars.LLM_ENDPOINT1 }} | ||
| LLM_PROBE_MODEL: ${{ inputs.model || vars.MODEL1 }} |
There was a problem hiding this comment.
2. Missing vars fallback/validation 🐞 Bug ☼ Reliability
LLM_BASE_URL and the model default now come solely from org vars (vars.LLM_ENDPOINT1, vars.MODEL1), so if either is unset/empty (common on forks or misconfigured repos), scheduled runs can fail early (empty model) or probe the wrong provider because the wrapper silently falls back to BigModel’s default base URL. This produces misleading “connectivity red” signals that are actually configuration errors, not provider reachability/key validity.
Agent Prompt
### Issue description
The workflow now depends on `vars.LLM_ENDPOINT1` and `vars.MODEL1` without any fallback or explicit validation. If these vars are missing/empty:
- `LLM_PROBE_MODEL` may become empty (especially on `schedule` runs where `inputs.model` is absent), causing `metering-wrapper.sh` to exit with a parameter error.
- `LLM_BASE_URL` may be empty, and `metering-wrapper.sh` will silently default to `https://open.bigmodel.cn/api/paas/v4`, which conflicts with the intended Kimi setup and can create misleading failures.
### Issue Context
This workflow is a monitoring signal; it should fail for true connectivity/key issues, but should fail *explicitly* and *diagnostically* for missing configuration.
### Fix Focus Areas
- .github/workflows/llm-connectivity.yml[12-18]
- .github/workflows/llm-connectivity.yml[51-62]
- pipeline/metering/metering-wrapper.sh[59-96]
### Suggested fix
Add a short guard step before calling the wrapper to validate required inputs and produce clear errors:
- Fail if `vars.LLM_ENDPOINT1` is empty (so you don’t accidentally hit the wrapper’s BigModel default).
- Provide a safe default for the model, e.g. `LLM_PROBE_MODEL: ${{ inputs.model || vars.MODEL1 || 'kimi-for-coding' }}` (or whatever constant is correct for your org).
Optionally also validate that `LLM_BASE_URL`’s hostname matches the expected provider domain (and/or matches the allowlist) to prevent configuration drift.
ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools
动机
org secret LLM_API_KEY 已随供应商切换被删除(只剩 LLM_API_KEY1=kimi),本 workflow 连续红;且 allowlist 缺块标量被折叠为单行,harden-runner 策略从未实际生效(假绿——adversary.yml 2026-08-24 八轮实测证实 block 模式拦 git fetch 后的连带发现)。
变更
|块标量 + egress 降 audit(block 模式在 org 内不可用,偏离记录见 adversary.yml)测试
合并后 workflow_dispatch 实跑一次(连通性 probe 经计量 wrapper)。
Card: Cloudbird-Software/.github#279
Ref: ADR-0048(LLM 接入)