Make api_key and identity auth modes disjoint by deprecating the implicit Entra fallback
维护者通常 2 天内回复
还没有人认领这个 Issue。
评估
- 难度
- 4/5
- 预计耗时
- 3-5 天
- 新手友好度
- 35/100
- Issue 类型
- 功能
- 描述清晰度
- 基本清楚
- 活跃度
- 活跃
- 技术栈
- python
调研方向
Start with pyrit/auth/openai_auth.py::resolve_openai_auth, then compare the inlined authentication chains in AzureMLChatTarget and PromptShieldTarget. This work is ordered after #2846, which adds explicit auth-mode support to AzureBlobStorageTarget; review that dependency and #3010 before changing behavior. Done means the implicit identity fallback warns for one release, strict modes and cleanup are addressed, and the setup and per-target notebooks plus release and migration guidance are updated.
由索引模型根据 Issue 内容生成。
描述
Is your feature request related to a problem? Please describe.
Follow-up to review feedback on #3010 (thread).
api_key authentication mode can currently resolve to identity. The chain in pyrit/auth/openai_auth.py::resolve_openai_auth is:
- token-provider callable passed as
api_key - explicit
api_keystring - the target's API key environment variable
- fallback: an Entra token, for recognized Azure endpoints only
Step 4 is why "no api_key passed" was ambiguous in the first place — it can mean "the user chose identity" or "no key is available, mint a token." #3010 fixed the user-facing symptom by adding an explicit auth_mode, but left the underlying fallback in place for backward compatibility, so the two modes still overlap rather than being disjoint.
The same inlined chain exists in AzureMLChatTarget and PromptShieldTarget.
Describe the solution you'd like
Make the two modes disjoint:
auth_mode="api_key"requires a key or an explicitly supplied token provider, and fails clearly when neither is present. No implicit identity fallback.auth_mode="identity"uses identity and ignores keys (already true as of #3010).
This is a breaking change: OpenAIChatTarget(endpoint=<azure endpoint>) with no key plus az login works silently today and is documented that way, so it should go through a deprecation cycle rather than being removed outright:
- One release emitting a
DeprecationWarningwhen the implicit fallback is taken, namingauth_mode="identity"as the replacement. - Removal in the following release, called out in the release notes and migration guidance.
Two cleanups land with this:
TargetService._accepts_auth_modecan be deleted. It exists solely becauseAzureBlobStorageTargethas noauth_modeparameter; once every identity-advertising target accepts the explicit mode, a target that cannot meet that contract should fail loudly instead of being quietly skipped. This is blocked on #2846, which adds explicit auth-mode support toAzureBlobStorageTarget.doc/code/setup/1_configuration.py/.ipynband the per-target notebooks that describe keyless Azure auth need updating.
Describe alternatives you've considered, if relevant
- Keep the fallback indefinitely. Lowest churn, but leaves
api_keymode able to silently produce identity auth, which is the ambiguity #3010 set out to remove. - Remove it immediately in #3010. Rejected: an unannounced break buried in a bugfix, with no warning period for users relying on the documented keyless Azure path.
- Add an explicit
automode that keeps today's chain, leavingapi_keyandidentitystrict. Preserves the behavior under an honest name, but adds a third mode to document and reason about; only worth it if the keyless path turns out to be widely depended upon.
Additional context
Ordering: this should land after #2846, which supplies the AzureBlobStorageTarget half and unblocks removing _accepts_auth_mode. #2846 and #3010 also introduce two overlapping mechanisms for the same concern (a per-class get_auth_mode_parameters hook vs. an explicit auth_mode constructor argument); reconciling those into one belongs in the same pass.
Related: #3010, #2846, #2235 (which introduced the fallback — correctly, for its original purpose as a last resort when no key exists).
- 主要语言
- Python
- 星标
- 4.6k
- 派生
- 944
- 平均合并
- 2 天 16 小时
- 30 天内合并 PR
- 350
环境准备
在浏览器里用你自己的 GitHub 账号启动这个项目的开发容器。
- 没有 Dockerfile 或 Docker Compose 文件
- 有 Pull Request 模板
- 没有贡献指南
从这里开始
- 先读完整个 Issue,再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库,在一个分支上完成修改。
- 提交 Pull Request,并在描述里引用这个 Issue 编号。
microsoft/PyRIT 的其他 Issue
-
BUG: label queries only return the final conversation of an attack可能已有人在做 @u7k4rs6 于 1 天前认领。 未关闭
难度 2/5 1-3 小时 新手友好度 85/100
microsoft/PyRIT#3095 · 4 条评论 · 已指派 1 人 ·
维护者通常 2 天内回复
-
BUG Configuration keeps runtime-status errors after polling recovers可能已有人在做 @joeyvictorino 于 5 天前认领。 未关闭Bug: triage GUI help wanted
难度 2/5 1-3 小时 新手友好度 86/100
microsoft/PyRIT#2868 · 6 条评论 ·
维护者通常 2 天内回复
-
Crescendo backtracking keeps the refused prompt when the objective target made a tool call可能已有人在做 @RachelWanggg 今天认领。 未关闭
难度 3/5 1-2 天 新手友好度 30/100
维护者通常 2 天内回复
-
BUG BinAsciiConverter UUencode output cannot be decoded when all words are converted可能已有人在做 @barkha1research-ai 今天认领。 未关闭Bug: triage
难度 2/5 1-3 小时 新手友好度 25/100
维护者通常 2 天内回复
-
FEAT Proposal: red-team decision models as targets (decision flip-rate testing)可能已有人在做 @shashank03-dev 今天认领。 未关闭
难度 5/5 一周以上 新手友好度 15/100
microsoft/PyRIT#3246 · 2 条评论 ·
维护者通常 2 天内回复
相似的 Issue
-
bug
难度 2/5 1-3 小时 新手友好度 68/100
jbacalso24/mimry#291 ·
维护者通常 1 天内回复
-
good first issue
难度 2/5 1 小时以内 新手友好度 82/100
eli-alvarado/us-watchlist-alerts#14 ·
维护者通常 1 天内回复
-
from-review-extraction python severity:nit
难度 2/5 1-3 小时 新手友好度 80/100
LearningCircuit/local-deep-research#7462 ·
维护者通常 2 天内回复
-
难度 2/5 1-3 小时 新手友好度 82/100
cathrynlavery/diagram-design#441 ·
维护者通常 2 天内回复
-
[Cleanup] Include the public header in work_split.cpp可能已有人在做 @blozano-tt 今天认领。 未关闭
难度 2/5 1-3 小时 新手友好度 82/100
tenstorrent/tt-metal#60850 ·
维护者通常 1 天内回复