Default Setup: GCP OIDC private registry (Artifact Registry, Maven) registered but requests sent unauthenticated (401)
Maintainer thường phản hồi trong vòng 1 ngày
Chưa có ai nhận issue này.
Đánh giá
- Độ khó
- 4/5
- Thời gian dự kiến
- 3-5 ngày
- Mức phù hợp với người mới
- 18/100
- Loại issue
- Lỗi
- Độ rõ ràng
- Khá rõ ràng
- Mức độ hoạt động
- Sôi nổi
- Công nghệ
- gcp, github-actions, java, typescript
- Lĩnh vực
- authentication, build-system
Hướng nghiên cứu
Start from the proxy log lines this report quotes: the 'registered gcp OIDC credentials for maven repository' message and the 401s. Compare the registered URL (no port) with the requested URL (':443'), since the report suspects that mismatch. The payload does not name source files, so locate the credential-matching code by searching for 'oidc_gcp' and the registry URL. Done means proxy requests to the registry carry the federated token and no fallback to Maven Central occurs when replaces_base is true, which needs a GCP setup to verify.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
Summary
Default Setup (Code Quality and code scanning, Java, build-mode: none) with an organization-level maven_repository private registry on Google Artifact Registry using GCP OIDC (auth_type: oidc_gcp, direct Workload Identity Federation, no service account). The proxy registers the credentials and the token exchange succeeds, but requests to the registry are sent without credentials, so every artifact returns 401. This looks like the GCP equivalent of #3838, after GCP OIDC configurations started being accepted in #3850.
Environment
| Item | Value |
|---|---|
| Workflow | Default Setup, dynamic/github-code-quality/codeql and code scanning default setup |
| CodeQL bundle / proxy | codeql-bundle-v2.27.2, update-job-proxy 2.27.2 (commit: dev) |
| Runners | GitHub-hosted ubuntu-latest and self-hosted (ARC); same behaviour |
| Registry | maven_repository, https://<region>-maven.pkg.dev/<project>/<repo>, replaces_base: true |
| Auth | oidc_gcp, workload_identity_provider set, no service_account, no audience |
What happens
- "Setup proxy for registries" lists the registry with the GCP Workload Identity Provider, and
proxy.logshows:
registered gcp OIDC credentials for maven repository: https://<region>-maven.pkg.dev/<project>/<repo> - Google STS logs show a successful token exchange for the job's OIDC subject (
repo:<org>/<repo>:ref:refs/pull/<n>/head) right after the proxy starts. - Every artifact request through the proxy then gets 401:
[014] 401 https://<region>-maven.pkg.dev:443/<project>/<repo>/com/fasterxml/.../x.jar
Remote response: {"error":"Unauthenticated request. Unauthenticated requests do not have permission \"artifactregistry.repositories.downloadArtifacts\" ..."}
Artifact Registry audit logs show these requests with emptyauthenticationInfo(anonymous). - The proxy then falls back to
repo.maven.apache.orgfor each artifact despitereplaces_base: true.
Why we think the token is fine
- The same Workload Identity provider and IAM binding (
principalSet://.../attribute.repository_owner/<org>,roles/artifactregistry.reader) authenticate normal workflows to the same Maven repository (federated token asoauth2accesstokenpassword): requests appear with the federated principal and succeed. - If we write our own Maven
settings.xmlwith that federated token, Maven's requests go through the CodeQL proxy and succeed (200). Only requests that rely on the proxy to add credentials fail: the dependency fetches made by the Java extractor inbuild-mode: none. - Possibly relevant: the proxy logs request URLs with an explicit port (
https://<host>:443/...) while the credentials are registered forhttps://<host>/....
Expected
The proxy attaches the federated access token (e.g. Basic oauth2accesstoken:<token>) to requests matching the registry URL, as it does for the OIDC providers fixed in #3838, and does not fall back to Maven Central when replaces_base is true.
Happy to share full proxy logs privately.
- Ngôn ngữ chính
- TypeScript
- Star
- 1.7k
- Fork
- 498
- Merge trung bình
- 1 ngày 17 giờ
- Pull request đã merge (30 ngày)
- 56
Chuẩn bị môi trường
- Không có Dockerfile hay tệp Docker Compose
- Có mẫu pull request
- Đọc hướng dẫn đóng góp
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của github/codeql-action
-
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 90/100
github/codeql-action#4202 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 68/100
github/codeql-action#4052 · 4 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 3/5 1-2 ngày Mức phù hợp với người mới 55/100
github/codeql-action#4252 · 2 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 5/5 Hơn một tuần Mức phù hợp với người mới 35/100
github/codeql-action#4228 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 5/5 Hơn một tuần Mức phù hợp với người mới 28/100
github/codeql-action#4199 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
Tất cả issue của github/codeql-action
Issue tương tự
-
agent/scanner help wanted hive/claimed-by-scanner kind/bug stage/020-claimed
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 90/100
hivecommons/rationguard#315 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
agent-ready area: ui-sdk priority: p3 type: chore
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 76/100
schlessera/brain-kit#2534 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
bug lane:gh-5
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 72/100
LLM-4-People/bridlewise-testing#122 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
bug priority: P2
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 78/100
Maintainer thường phản hồi trong vòng 1 ngày
-
enhancement priority:low ready-for-dev
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 67/100
Maintainer thường phản hồi trong vòng 1 ngày