[Bug]: ate-api-server rejects every token when the cluster's service account issuer is not kubernetes.default.svc

Đang mở
  • Có gì không ổn?
#3,326 0 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

@ericcurtin đang làm issue này rồi.

Từ ngày 7/11/2026.

  • #3725 của @ericcurtin — đang mở

Đá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
55/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ệ
go, kubernetes
Lĩnh vực
authentication, backend

Hướng nghiên cứu

Start in cmd/ate-setup/internal/steps/create.go at buildAuthenticationConfig and trace how the service account issuer determines the authentication configuration. Check how the cluster's discovery document, service account CA, and token are available, then verify token authentication for a non-default issuer and that discovery failures are logged with their cause.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

area/api-machinery area/dev-infra area/identity kind/bug
What happened?

On Talos the service account issuer is https://<control-plane-ip>:6443. buildAuthenticationConfig (cmd/ate-setup/internal/steps/create.go) adds certificateAuthorityFile and discoveryTokenFile only when the issuer equals https://kubernetes.default.svc (or .cluster.local). For any other issuer, ate-api-server tries unauthenticated discovery against the API server with the system roots, and every client call fails with Unauthenticated: invalid bearer token. Nothing in the server log names the cause.

Expected Behavior

ate-api-server verifies tokens for any issuer that the cluster's own discovery document returns, or logs why discovery failed.

Steps to Reproduce

on a cluster whose service account issuer is the API server address (Talos default)
run ate-setup deploy ate-system
then any kubectl-ate call
it fails with invalid bearer token.

Sandbox Runtime

Both / Runtime Agnostic

Agent Substrate Version / Commit SHA

v0.6.0 (d3f2363); the same code is on main as of 2026-10-27

Kubernetes Version & Environment

Kubernetes 1.37.1, Talos 1.14.4, Cilium

Host OS & Architecture

Talos Linux, amd64

Relevant Logs and Diagnostic Output
Additional Context

Suggested fix: add the pod's service account CA and token whenever the issuer is the cluster's own (or offer a setting for them), and log the discovery error. We worked around it by patching the generated authentication config. Related: #3271. Found while evaluating Substrate v0.6.0 on Talos 1.14 / Kubernetes 1.37 / Cilium; background: https://groups.google.com/g/ate-dev/c/WeQaFvHYZb4

Confirmation
  • I have searched existing issues and verified that this is not a duplicate.
  • I have verified that this issue occurs on the latest commit on main.
Ngôn ngữ chính
Go
Star
6.1k
Fork
676
Merge trung bình
2 ngày 1 giờ
Pull request đã merge (30 ngày)
481

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. 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.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của agent-substrate/substrate

Tất cả issue của agent-substrate/substrate

Issue tương tự

Thêm issue về Go

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.