Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

[Low] ate-api-server accepts client certificates chained to system roots when --pod-identity-ca-certs is unset

オープン 初心者向け
  • 何か問題がありますか？
#2,918 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

@abhisheksharma2411 がすでに取り組んでいます。

2026年10月20日 から。

  • #3023 @abhisheksharma2411 による — オープン

評価

難易度
2/5
見積もり時間
1〜3時間
初心者へのやさしさ
75/100
issue の種類
バグ
明瞭さ
明確に書かれている
活発さ
活発
技術スタック
go
領域
backend, security

調査の方向性

cmd/ateapi/main.go の buildServerTLSConfig（631–643行）から始め、caCertsPath が空の場合の分岐でクライアント証明書がどのように設定されるかを確認してください。issue に記載された Go の TLS クライアント認証の動作を読み、関連する ate-api-server のテストを実行してください。空のパスを指定した設定で、システムルートを使ったクライアント証明書の認証が行われず、テストでその動作が確認できれば完了です。

索引モデルが issue の本文から書いたものです。

説明

area/security kind/bug

Summary

When --pod-identity-ca-certs is omitted (empty caCertsPath), cmd/ateapi/main.go:buildServerTLSConfig returns a tls.Config with ClientAuth: tls.VerifyClientCertIfGiven and ClientCAs: nil. Under Go's crypto/tls implementation, a nil ClientCAs causes client certificate verification to fall back to the host system root CAs, allowing any client certificate trusted by a system root containing a SPIFFE URI SAN to authenticate as an mTLS principal.

Details

In cmd/ateapi/main.go:631-643:

func buildServerTLSConfig(ctx context.Context, credBundlePath, caCertsPath string) (*tls.Config, error) {
	serverCert := credbundle.Loader(credBundlePath)
	const clientAuth = tls.VerifyClientCertIfGiven

	if caCertsPath == "" {
		return &tls.Config{
			GetCertificate: serverCert,
			ClientAuth:     clientAuth,
		}, nil
	}

When caCertsPath == "", ClientCAs is left nil. In Go's crypto/tls/handshake_server.go:

opts := x509.VerifyOptions{
    Roots: c.config.ClientCAs,
    CurrentTime: c.config.time(),
    Intermediates: x509.NewCertPool(),
    KeyUsages: []x509.ExtKeyUsage{x509.ExtKeyUsageClientAuth},
}

When opts.Roots is nil, x509.Certificate.Verify defaults to the host's system root CAs. If a client certificate verified by any system CA includes a URI SAN, apiauthn.UnaryServerInterceptor extracts the URI SAN via mtlsPeerIdentity and treats the caller as an authenticated mTLS principal without inspecting or requiring bearer token authentication.

Impact

Low: in standard deployments (manifests/ate-install/ate-api-server.yaml:180), --pod-identity-ca-certs is always provided. The fallback occurs only when --pod-identity-ca-certs is omitted. In standard deployments (manifests/ate-install/ate-api-server.yaml:180), --pod-identity-ca-certs is always provided, pointing to /run/podidentity.podcert.ate.dev/trust-bundle.pem. The fallback occurs only in non-standard or standalone deployments where --pod-identity-ca-certs is deliberately omitted. Furthermore, obtaining a publicly-trusted certificate containing a URI SAN (e.g., spiffe://...) with the clientAuth EKU is non-trivial under standard Web PKI CA baseline requirements. NetworkPolicies on ate-api-server also restrict ingress on port 443 to control plane pods or namespaces labeled ate.dev/api-access=true.

Suggested fix

When caCertsPath == "", explicitly disable client certificate verification by setting ClientAuth: tls.NoClientCert in the returned tls.Config:

	if caCertsPath == "" {
		return &tls.Config{
			GetCertificate: serverCert,
			ClientAuth:     tls.NoClientCert,
		}, nil
	}

Related

No existing duplicate issues or PRs found.

主要言語
Go
スター
5.7k
フォーク
612
平均マージ
2日 14時間
マージ済み PR（30日）
571

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

agent-substrate/substrate のほかの issue

agent-substrate/substrate の issue をすべて見る

似ている issue

Go の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。