AWS Private CAのKubernetes連携に認可不備｜1.10.1更新前にIssuer指定を点検

AWS Private CA Connector for Kubernetesに、許可されていない発行者から証明書を取得できる認可不備CVE-2026-119115が公表されました。利用者はaws-privateca-issuerを1.10.1以降、EKSアドオンを1.10.1-eksbuild.1以降へ更新してください。ただし、先にCertificateRequest、Certificate、Ingressの発行者指定を点検する必要があります。従来の曖昧な指定は、更新後に証明書の更新停止を招くためです。

本稿は2026年10月31日にAWS：CVE-2026-119115に関するセキュリティ勧告、開発元アドバイザリ、公式CVEレコード、修正コードを確認したニュース解説です。対象はcert-managerとAWS Private CAを組み合わせ、Webサービスやサービス間通信のTLS証明書を管理する担当者です。以下の棚卸し・試験計画は本サイトの提案を含み、読者環境で攻撃や動作を再現した報告ではありません。

名前空間の承認とクラスターの発行権限が食い違う

このコネクターは、cert-managerの証明書要求をAWS Private CAへ渡して署名する外部Issuerです。AWSPCAIssuerは名前空間に属し、AWSPCAClusterIssuerはクラスター全体から参照できます。同じ名前でも種類と有効範囲が異なるため、承認した発行者と実際に使う発行者を一致させなければなりません。

公式発表によると、影響版では一定条件下で、名前空間内のIssuerだけを承認された認証済み利用者が、承認ポリシーで許可されていないクラスターIssuerから証明書を得られます。対象には下位CA証明書も含まれます。インターネット上の誰もが認証なしで発行できるという説明ではなく、証明書要求を扱える主体と承認範囲の組み合わせが問題です。開発元：Issuer解決の認可不備に関するアドバイザリが影響と暫定策を説明しています。

原因の理解には開発元：issuerRef.kindに従って検索する修正コミットが参考になります。修正前は名前空間内のIssuer取得に失敗した際、同名のクラスターIssuerを探す処理がありました。修正後はissuerRef.kindを受け取り、指定された種類だけを検索します。これは単なる表記の厳格化ではなく、承認した種類と実際の署名先を一致させる修正です。

本サイトとしては、複数チームへ名前空間を委任している環境、クラスターIssuerを共有する環境、用途の異なるCAを併用する環境を優先点検の対象と考えます。下位CA証明書を得られた場合の影響はCAの権限・テンプレート・信頼関係にも依存します。秘密鍵が盗まれた、既存の全TLS通信が解読された、と広げて断定できる公表ではありません。

修正版の公開日と脆弱性の公表日を分ける

開発元：aws-privateca-issuer v1.10.1リリースは2026年10月13日付で、Issuer検索時にkindを尊重する修正を含みます。AWS勧告の初回公表は10月29日9時30分PDT、日本時間では10月30日1時30分です。CVE Program：CVE-2026-119115公式レコードも10月29日の公表を記録しています。10月31日に新しい修正版が出た案件と読み替えず、導入済みの版を実際に照合してください。

影響範囲はaws-privateca-issuerの1.10.1未満、EKSアドオンの1.10.1-eksbuild.1未満です。GitHubのパッケージ表示では1.10.0以下が対象になっています。Helm管理とEKSアドオン管理では版の形式が異なるため、数字の一部だけを見て判定せず、インストール方式と版を組にして記録します。

公式CVEのCVSS v3.1は8.5（High）、v4.0は8.4（High）です。本記事の構造化メタにはv3.1の8.5を採用します。確認したAWS勧告と開発元資料には、実環境での悪用を確認したとの記載はありません。悪用なしを保証する意味ではなく、現時点で確認できた根拠の範囲として扱います。

更新前に三つのリソースと発行元を対応させる

最初に、どのクラスターでコネクターが動いているか、HelmかEKSアドオンか、実行中のイメージと配備済み版を一覧にします。マニフェストの希望値だけでなく、現在のDeploymentとPodも確認します。独自ビルドやフォークを使っている場合は、版名の見た目ではなく修正コミットの取り込みを確認してください。

次にCertificateRequestと、その作成元となるCertificate、さらにIngressから自動生成される経路をたどります。発行者のname、kind、group、名前空間、実際のIssuer、対応するCA、証明書の期限を同じ台帳へまとめます。古い要求だけを見つけて終えず、次回の更新でも正しい要求を作れるかを確認するための棚卸しです。

例えば、次のコマンドは参照先を確認するための読み取り例です。対象クラスターとkubectlのcontextを確認し、必要な範囲を一覧できる資格情報で実行します。全名前空間を閲覧できない場合は担当範囲ごとに集約してください。一覧が空でも、権限外のリソースが存在しない証拠にはなりません。

kubectl get certificates.cert-manager.io,certificaterequests.cert-manager.io -A \
  -o custom-columns='KIND:.kind,NS:.metadata.namespace,NAME:.metadata.name,ISSUER:.spec.issuerRef.name,ISSUER_KIND:.spec.issuerRef.kind,GROUP:.spec.issuerRef.group'
kubectl get ingress -A

CertificateRequestだけを書き換える前提にはしません。要求は証明書発行の履歴でもあり、再作成時にはCertificateやIngress側の指定が使われます。GitOps、Helm値、テンプレートなど生成元も修正対象へ含め、作業後の同期で古い指定へ戻らないようにします。既存要求の扱いは利用中のcert-managerの手順に沿って判断してください。

issuerRef.kindの省略と種類の不一致を解消する

AWSが更新前に求めているのは、issuerRef.kindをAWSPCAIssuerまたはAWSPCAClusterIssuerへ明示し、参照先の種類と一致させることです。kindがない、Issuerなど別の値になっている要求は修正後にFailedとなります。AWSPCAIssuerでクラスターIssuerを参照する要求は、Pendingのままになります。

FailedとPendingは同じ原因とは限りません。前者では未対応のkind、後者では指定した種類の発行者を見つけられるかが切り分けの出発点です。現在の証明書が有効な間は通信できても、次回の更新に失敗し、期限切れで依存サービスへ影響が出ることがあります。更新直後のHTTP疎通だけで完了としないでください。

参照部分だけを示す例は次のとおりです。example-pcaは自環境の実在する発行者名へ置き換えます。クラスター発行者へ切り替える場合は、kindを変えるだけでなく、その利用が承認ポリシーで許可されているかも確認します。この断片だけでは完全なCertificateマニフェストにはなりません。

issuerRef:
  name: example-pca
  kind: AWSPCAIssuer
  group: awspca.cert-manager.io

Ingressのcluster-issuerへ機械的に置き換えない

cert-manager：Ingressの証明書発行アノテーションでは、外部Issuerの種類をcert-manager.io/issuer-kind、APIグループをcert-manager.io/issuer-groupで指定します。クラスター全体の発行者だからといって、cert-manager.io/cluster-issuerへ機械的に置き換えないでください。この省略形はcert-manager標準のClusterIssuer向けで、外部のAWSPCAClusterIssuerを指定する用途ではありません。

開発元：AWS Private CA Issuerの構成と利用方法も、AWSのクラスターIssuerにはcert-manager.io/issuerを使うよう説明しています。以下は名前空間内の発行者を指定するアノテーションの例です。AWSPCAClusterIssuerを使う構成ではissuer-kindをその種類へ合わせ、issuer名と承認範囲も再照合します。

metadata:
  annotations:
    cert-manager.io/issuer: example-pca
    cert-manager.io/issuer-kind: AWSPCAIssuer
    cert-manager.io/issuer-group: awspca.cert-manager.io

Ingressの設定を直した後は、生成されたCertificateのissuerRefも読み戻します。テンプレートへ正しい値を書いたことと、実行中のリソースへ反映されたことは別です。複数のIngressで証明書を管理する環境では、正常な一件だけを確認せず、異なる生成経路や名前空間を含めて確認します。

更新と暫定策は承認ポリシーまで含めて適用する

設定の棚卸しを終えたら、導入方式に合う修正版へ更新します。AWSはフォークや派生コードにも修正を取り込むよう求めています。更新後は古いPodが残っていないこと、想定したIssuerを参照できること、正規の要求が承認・発行へ進むことを確認します。修正版の指定だけでなく稼働状態も対応票へ残します。

すぐに更新できない場合、公式の回避策は証明書承認ポリシーとRBACを発行者名と種類の両方へ絞ることです。名前だけで同名リソースを同一視するルールがないか確認します。修正後に発行が止まったからといって承認チェックを無効化したり、種類の制約を外したりすると、今回守るべき境界を弱めるため避けてください。

本サイトが提案する確認は、管理下の検証環境で正規の発行を通す試験と、承認範囲外の種類へ解決されない試験を分けることです。本番のCAを使って越権発行を試す必要はありません。開発元の修正テストも、指定した種類が存在しない場合に別の種類へ代替しないケースを含みます。自社の期待値と実際の結果を残してください。

最後に、CertificateRequestの条件、イベント、コネクターの記録、Certificateの更新予定と期限を見ます。既存SecretがあることやHTTPSが現在通ることだけでは、次の証明書発行が成功する証拠になりません。kindの不一致、発行者の不存在、承認拒否、AWS側の権限不足を区別し、エラーを消すための権限拡大で済ませないことが重要です。

不審な発行が疑われる場合は、利用可能な要求履歴、承認の記録、CA側の発行履歴を保全して照合することを提案します。コネクターを更新しても、過去に発行された証明書の効力まで自動で取り消す対策とは説明されていません。対象証明書と信頼先が判明した段階で、CA管理者と失効・再発行の要否を判断してください。

完了条件は、修正版の稼働、発行者のname・kind・groupの一致、承認ポリシーとの対応、正規の新規発行と更新の確認です。特に名前空間を複数チームへ委任している運用では、クラスター共通の発行権限を誰に渡しているかまで確認します。セキュリティ修正と証明書期限の監視を同じ変更計画に入れ、後日の期限切れを取り残さないようにします。

関連記事

名前空間を使った委任の別の点検例として、consul-k8sの認可不備と名前空間の制限も解説しています。今回とは製品・認証経路が異なるため、修正版や設定値を流用せず、それぞれの境界を確認してください。