[{"data":1,"prerenderedAt":318},["ShallowReactive",2],{"blog-ja-gitlab-auto-devops-k3s-admission-controller-gate":3,"blog-related-ja-gitlab-auto-devops-k3s-admission-controller-gate":268,"blog-ja-gitlab-auto-devops-k3s-admission-controller-gate-alt":256},{"id":4,"title":5,"author":6,"body":7,"date":250,"description":251,"extension":252,"image":253,"locale":254,"meta":255,"navigation":256,"path":257,"seo":258,"stem":259,"tags":260,"__hash__":267},"blog\u002Fblog\u002Fja\u002Fgitlab-auto-devops-k3s-admission-controller-gate.md","GitLab Auto DevOpsの『とりあえず動くCI』が、本番K3sクラスタへの一番近い脅威になる理由","Kubo Team",{"type":8,"value":9,"toc":236},"minimark",[10,15,23,30,33,51,60,64,70,77,86,95,104,108,114,131,140,147,151,157,163,168,188,192,201,205,208,211,214,217],[11,12,14],"h2",{"id":13},"gitlab-auto-devopsの何もしなくても動くという罠","GitLab Auto DevOpsの「何もしなくても動く」という罠",[16,17,18],"p",{},[19,20],"img",{"alt":21,"src":22},"section01","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fgitlab-auto-devops-k3s-admission-controller-gate\u002Fsection01.webp",[16,24,25,29],{},[26,27,28],"strong",{},"GitLab Auto DevOps"," を有効化した瞬間から、SAST（静的解析）やDASTといったセキュリティスキャンは自動的に動き出す。マージリクエストの画面には脆弱性のバッジが並び、チームは「うちはもうDevSecOpsができている」と安心する。だが、ここに典型的な落とし穴がある。",[16,31,32],{},"たとえば、あるチームがAuto DevOpsを有効化し、SASTスキャンでCritical判定の脆弱性が検出されたとする。ジョブ自体は正常終了し、パイプラインはグリーンのまま進み続ける。担当者はマージリクエストの警告バッジに気づかないまま、あるいはリリース期限を優先してそのままマージする。結果として、脆弱性を含んだコンテナイメージがビルドされ、レジストリにpushされ、何の障害もなく本番のK3sクラスタにデプロイされる。",[16,34,35,42,43,46,47,50],{},[36,37,41],"a",{"href":38,"rel":39},"https:\u002F\u002Fdocs.gitlab.com\u002Fuser\u002Fapplication_security\u002Fsast\u002F",[40],"nofollow","GitLab公式のSASTドキュメント","でも、SASTは「開発の早い段階、修正コストが最も低いタイミングで脆弱性を検出する」ことを目的としたツールだと説明されている。つまりSASTの役割はあくまで",[26,44,45],{},"検知","であり、検知した結果をパイプラインの合否条件に組み込んで",[26,48,49],{},"強制","するかどうかは、利用者側の設計に委ねられている。",[16,52,53,54,59],{},"さらに厄介なのは、Auto DevOpsが2026年時点で以前ほど「全部お任せ」の製品ではなくなっている点だ。GitLabはAuto DevOpsが提供していたin-cluster PrometheusやWAFといったマネージドアプリケーションの一部を廃止し、",[36,55,58],{"href":56,"rel":57},"https:\u002F\u002Fgitlab.com\u002Fgroups\u002Fgitlab-org\u002F-\u002Fwork_items\u002F4280",[40],"運用者が自身でingressやPrometheus、Cilium等を持ち込む方向","にシフトしている。「有効化するだけで安全なパイプラインが完成する」という前提そのものが、もはや成立しない。",[11,61,63],{"id":62},"ci通過とデプロイしていいはイコールではない","「CI通過」と「デプロイしていい」はイコールではない",[16,65,66],{},[19,67],{"alt":68,"src":69},"section02","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fgitlab-auto-devops-k3s-admission-controller-gate\u002Fsection02.webp",[16,71,72,73,76],{},"なぜこの落とし穴が起きるのか。根本原因は、",[26,74,75],{},"CI\u002FCDパイプラインのセキュリティ境界とKubernetesクラスタのセキュリティ境界がまったく別物である","という事実が見落とされているからだ。",[16,78,79,80,85],{},"コンテナイメージの脆弱性リスクは、決して一部の有名イメージだけの問題ではない。Chainguardの調査「",[36,81,84],{"href":82,"rel":83},"https:\u002F\u002Fthehackernews.com\u002F2026\u002F04\u002Fthe-state-of-trusted-open-source-report.html",[40],"The State of Trusted Open Source Report","」によれば、検出されたCVEインスタンスの96.2%は、利用頻度の高い上位20イメージ以外から発生している。つまり、自社が組み合わせて使っている依存パッケージのどこかに、常に未知のリスクが潜んでいると考えるべきだ。",[16,87,88,89,94],{},"Wizのセキュリティ解説記事でも指摘されている通り、",[36,90,93],{"href":91,"rel":92},"https:\u002F\u002Fwww.wiz.io\u002Facademy\u002Fapplication-security\u002Fci-cd-security-scanning",[40],"CI\u002FCDのスキャン結果は量が多すぎて、優先順位付けなしにはそのまま実質的なリスク低減につながらない","。フィーチャーブランチでは高速な非ブロッキングチェックにとどめ、本番デプロイに向かうパイプラインではCritical・High判定の検出結果を厳格にゲートするという段階的な設計が推奨されている。だが、Auto DevOpsのデフォルト構成だけでは、この「本番向けの厳格なゲート」は自動的には作られない。CI側の検知と、Kubernetesクラスタ側の実行制御は、意識的に接続しない限り繋がらないのだ。",[16,96,97,98,103],{},"この「CI\u002FCDとクラスタの間の断絶」をどう埋めるかは、マネージドKubernetesを選ぶ際の隠れた判断基準でもある。クラスタ側が独自拡張だらけのブラックボックスだと、標準的なゲート機構を後から組み込むこと自体が難しくなる。",[36,99,102],{"href":100,"rel":101},"https:\u002F\u002Fkubo.hexabase.io\u002F",[40],"Kubo","のようにPure Kubernetesを維持したマネージドK3s環境であれば、この後説明するCNCFエコシステムのポリシーエンジンをそのまま利用できる。",[11,105,107],{"id":106},"パイプラインとクラスタの間に関所を作る-admission-controllerによるゲート設計","パイプラインとクラスタの間に「関所」を作る — Admission Controllerによるゲート設計",[16,109,110],{},[19,111],{"alt":112,"src":113},"section03","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fgitlab-auto-devops-k3s-admission-controller-gate\u002Fsection03.webp",[16,115,116,117,120,121,126,127,130],{},"この断絶を埋める仕組みが、Kubernetes標準の",[26,118,119],{},"Admission Controller","だ。",[36,122,125],{"href":123,"rel":124},"https:\u002F\u002Fkubernetes.io\u002Fdocs\u002Freference\u002Faccess-authn-authz\u002Fadmission-controllers\u002F",[40],"Kubernetes公式ドキュメント","によると、Admission Controllerは「APIサーバーがリソースをデータベースに永続化する前に、認証・認可後のリクエストをインターセプトして検証・変更するコンポーネント」と定義されている。つまり、CIパイプラインがどれだけ緩くても、",[26,128,129],{},"クラスタのAPIサーバーに届いた時点で最後のチェックをかけられる","という点が重要だ。",[16,132,133,134,139],{},"具体的にAdmission Controllerで何ができるのか。",[36,135,138],{"href":136,"rel":137},"https:\u002F\u002Fwww.wiz.io\u002Facademy\u002Fcontainer-security\u002Fkubernetes-admission-controllers",[40],"Wizの解説","によれば、承認済みのレジストリ以外からのイメージpullを制限したり、root権限で動作するPodを拒否したり、ホストポートを公開するPodを拒否するといったポリシーを、クラスタ全体に一貫して強制できる。CIのスキャンが「検知」担当、Admission Controllerが「強制」担当という役割分担を持たせることで、初めて「検知したのに実害を防げなかった」というギャップが埋まる。",[16,141,142,146],{},[36,143,145],{"href":100,"rel":144},[40],"Kubo Cloud","はベンダー独自の管理レイヤーでAPIサーバーを覆い隠さないPure Kubernetes構成のため、この後紹介するKyvernoやOPA Gatekeeperのような標準的なポリシーエンジンを、追加のライセンス制約なくそのままインストールして運用できる。GitOps対応も標準搭載しているため、ポリシー定義自体もArgoCD\u002FFluxの管理下に置きやすい。",[11,148,150],{"id":149},"検知から強制へ-3つの実装パターン","検知から強制へ — 3つの実装パターン",[16,152,153],{},[19,154],{"alt":155,"src":156},"section04","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fgitlab-auto-devops-k3s-admission-controller-gate\u002Fsection04.webp",[16,158,159,160,120],{},"Admission Controllerの選択肢はいくつかあるが、いずれを選ぶにしても押さえるべき実装パターンは3つある。まず着手すべきは、",[26,161,162],{},"優先度が最も高いブロッキングゲート",[164,165,167],"h3",{"id":166},"_1-イメージ検証をブロッキングゲート化する最優先","1. イメージ検証をブロッキングゲート化する（最優先）",[16,169,170,175,176,181,182,187],{},[36,171,174],{"href":172,"rel":173},"https:\u002F\u002Fwww.cncf.io\u002Fprojects\u002Fkyverno\u002F",[40],"CNCFのGraduatedプロジェクトであるKyverno","は、",[36,177,180],{"href":178,"rel":179},"https:\u002F\u002Fkyverno.io\u002Fdocs\u002Fpolicy-types\u002Fcluster-policy\u002Fverify-images\u002Foverview\u002F",[40],"署名済み・アテステーション付きのイメージだけをクラスタが受け入れるよう検証する機能","を持つ。同様に",[36,183,186],{"href":184,"rel":185},"https:\u002F\u002Fopen-policy-agent.github.io\u002Fgatekeeper\u002Fwebsite\u002Fdocs\u002Fconstrainttemplates\u002F",[40],"OPA GatekeeperのConstraintTemplate","を使えば、Rego\u002FCELで書いたポリシーロジックをクラスタ全体のConstraintとして再利用可能な形で強制できる。まずはこのレイヤーで「未署名・未スキャンのイメージは拒否」というルールを1本通すことが、投資対効果の最も高い一手になる。",[164,189,191],{"id":190},"_2-ciサービスアカウントのrbacを最小化する","2. CIサービスアカウントのRBACを最小化する",[16,193,194,195,200],{},"CIパイプライン自体がクラスタに直接デプロイする構成では、そのサービスアカウントの権限が広すぎるケースが多い。",[36,196,199],{"href":197,"rel":198},"https:\u002F\u002Fkubernetes.io\u002Fdocs\u002Fconcepts\u002Fsecurity\u002Frbac-good-practices",[40],"Kubernetes公式のRBACグッドプラクティス","では、ClusterRoleBindingではなく名前空間スコープのRoleBindingを優先し、ワイルドカード権限を避けることが推奨されている。CIのサービスアカウントが乗っ取られた場合の被害範囲を、あらかじめ名前空間単位に限定しておく設計が欠かせない。",[164,202,204],{"id":203},"_3-secretsを平文のconfigmapに置かない","3. Secretsを平文のConfigMapに置かない",[16,206,207],{},"CI\u002FCD変数として渡すAPIキーやDB接続情報は、ConfigMapではなくKubernetes SecretsまたはVaultなどの外部シークレットマネージャで管理する。これは地味だが、Admission Controllerのポリシーで「Secrets以外への機密情報の書き込みを拒否する」ルールと組み合わせることで、検知と強制の両輪が揃う。",[11,209,210],{"id":210},"まとめ",[16,212,213],{},"GitLab Auto DevOpsの「有効化するだけで動く」という手軽さ自体は否定すべきものではない。問題は、その手軽さを「クラスタまで安全である」という誤った安心感にすり替えてしまうことだ。CI側の検知（SAST\u002FDAST）と、クラスタ側の強制（Admission Controller）を明確に役割分担させ、両者の間に「関所」を設計することで、初めてDevSecOpsパイプラインは実効性を持つ。",[16,215,216],{},"まずはKyvernoかOPA Gatekeeperのどちらかで、未署名イメージを拒否するポリシーを1本本番クラスタに適用するところから始めてほしい。そのうえでRBACの最小化、Secrets管理の見直しへと段階的に広げていけば、CI\u002FCDとクラスタの間の断絶は着実に埋まっていく。",[16,218,219,220,223,224,229,230,235],{},"こうした標準的なポリシーエンジンをロックインなく運用できる基盤を探しているなら、",[36,221,102],{"href":100,"rel":222},[40],"はK3sベースのPure Kubernetesとして、EKS\u002FAKS比で4割以上安いコストで同じ設計をそのまま実践できる。GitOpsやHelmも標準対応しているため、ポリシー適用の自動化もスムーズに始められる。まずは",[36,225,228],{"href":226,"rel":227},"https:\u002F\u002Fwww.hexabase.com\u002Fpricing\u002F",[40],"料金プラン","でコスト構造を確認するか、",[36,231,234],{"href":232,"rel":233},"https:\u002F\u002Fwww.hexabase.com\u002Fcontact-us\u002F",[40],"お問い合わせ","から相談してみてほしい。",{"title":237,"searchDepth":238,"depth":238,"links":239},"",2,[240,241,242,243,249],{"id":13,"depth":238,"text":14},{"id":62,"depth":238,"text":63},{"id":106,"depth":238,"text":107},{"id":149,"depth":238,"text":150,"children":244},[245,247,248],{"id":166,"depth":246,"text":167},3,{"id":190,"depth":246,"text":191},{"id":203,"depth":246,"text":204},{"id":210,"depth":238,"text":210},"2026-08-17","GitLab Auto DevOpsは有効化するだけでSAST\u002FDASTが自動的に動く。しかしスキャンが『動いている』ことと、脆弱性を含んだイメージが本番K3sクラスタに届かないことはまったく別の話だ。CI\u002FCDとクラスタの間に監査ゲートを作る設計を解説する。","md","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fgitlab-auto-devops-k3s-admission-controller-gate\u002Feyecatch.webp","ja",{},true,"\u002Fblog\u002Fja\u002Fgitlab-auto-devops-k3s-admission-controller-gate",{"title":5,"description":251},"blog\u002Fja\u002Fgitlab-auto-devops-k3s-admission-controller-gate",[261,262,263,264,265,266],"k3s","kubernetes","gitlab","ci-cd","devsecops","admission-controller","wz-HuyfBHIKUTc7ZBmQSSWGOxsdm9oOmmOk5oTtXExI",[269,277,285,293,301,310],{"path":270,"title":271,"description":272,"date":273,"tags":274},"\u002Fblog\u002Fja\u002Fkubernetes-image-signing-sigstore-supply-chain","イメージタグは誰でも書き換えられる。Kubernetesのイメージ署名にSigstoreで『来歴』を刻むという発想","コンテナイメージ署名の仕組みを解説。イメージタグは誰でも書き換え可能で、CI\u002FCDのテストを通過した保証にはならない。SigstoreとKyvernoを組み合わせ、Kubernetes\u002FK3s上で未署名イメージの起動を拒否する防御層を構築する方法を、GitOps運用との統合も含めて紹介する。","2026-08-06",[261,262,264,275,276],"gitops","security",{"path":278,"title":279,"description":280,"date":281,"tags":282},"\u002Fblog\u002Fja\u002Fqa-to-devops-kubernetes-career-transition","QAエンジニアの『バグを壊す視点』はKubernetes運用に転用できる。テスト自動化スキルからDevOpsキャリアへの最短ルート","QAエンジニアが持つ品質ゲート思考とテスト自動化スキルは、実はKubernetes運用に直結するDevOps適性だ。半年で転身するための現実的なロードマップと、学習の最大の壁を越える方法を解説する。","2026-07-19",[262,261,283,264,284],"devops","career",{"path":286,"title":287,"description":288,"date":289,"tags":290},"\u002Fblog\u002Fja\u002Fcanary-release-kubernetes-auto-rollback-gitops","全員が同じCI\u002FCDにたどり着けない理由。カナリアリリース×自動ロールバックで作る『壊れても安全』なKubernetesデプロイ設計","本番障害の多くは「一気にデプロイする」ことが原因で起きる。カナリアリリース・自動ロールバック・監視をKubernetes上でどう設計するか、Argo RolloutsとGitOpsを軸に、中小チームでも運用し続けられる実践手順を具体的に解説する。","2026-07-15",[262,261,264,291,275,292],"canary-release","argo-rollouts",{"path":294,"title":295,"description":296,"date":297,"tags":298},"\u002Fblog\u002Fja\u002Fmlops-kubernetes-devops-ai-skills-2026","「DevOpsエンジニアは不要になる」は嘘だった。AI時代のKubernetes運用者が今すぐ身につけるべきMLOpsスキル5選","AIがインフラ構築を自動化する時代、DevOpsエンジニアは本当に不要なのか？実態は逆で、MLOps Kubernetesを扱える人材の需要が急増。2026年に求められる5つのスキルと具体的な習得法を解説。","2026-07-11",[262,299,283,261,264,300],"mlops","ai-infrastructure",{"path":302,"title":303,"description":304,"date":305,"tags":306},"\u002Fblog\u002Fja\u002Fcicd-pipeline-security-devsecops","ci-cd パイプラインのセキュリティ: DevSecOps 実践ガイド","ci-cd パイプラインのセキュリティを DevSecOps の観点で実践的に解説。SAST\u002FDAST、サプライチェーン保護、SLSA フレームワーク、Policy as Code まで。","2026-05-27",[265,264,307,308,309,262],"セキュリティ","サプライチェーン","slsa",{"path":311,"title":312,"description":313,"date":305,"tags":314},"\u002Fblog\u002Fja\u002Fgitlab-ci-container-deployment","GitLab ci-cd でコンテナデプロイを自動化する方法","GitLab ci-cd と Kubernetes Agent を使ったコンテナデプロイの自動化を実践解説。パイプライン構成、Auto DevOps、セキュリティ設定まで詳しく紹介。",[263,264,262,315,316,317],"コンテナ","auto-devops","デプロイ自動化",1787649511612]