[{"data":1,"prerenderedAt":479},["ShallowReactive",2],{"blog-ja-kyverno-validatingadmissionpolicy-cel-migration-silent-bypass":3,"blog-related-ja-kyverno-validatingadmissionpolicy-cel-migration-silent-bypass":421,"blog-ja-kyverno-validatingadmissionpolicy-cel-migration-silent-bypass-alt":409},{"id":4,"title":5,"author":6,"body":7,"date":403,"description":404,"extension":405,"image":406,"locale":407,"meta":408,"navigation":409,"path":410,"seo":411,"stem":412,"tags":413,"__hash__":420},"blog\u002Fblog\u002Fja\u002Fkyverno-validatingadmissionpolicy-cel-migration-silent-bypass.md","CELに書き換えたポリシーは、本当に同じ意味なのか。KyvernoからValidatingAdmissionPolicyへの移行で\"黙って素通り\"したリソースの正体","Kubo Team",{"type":8,"value":9,"toc":388},"minimark",[10,19,26,31,63,89,95,98,102,120,127,136,142,146,165,194,207,213,222,231,244,248,251,256,266,270,283,287,314,317,324,330,338,347,351,363,375],[11,12,13,14,18],"p",{},"K3s\u002FKubernetesでワイルドカードのポリシーを運用していたチームが、ValidatingAdmissionPolicy（CEL）への移行作業で遭遇した問題がある。移行後しばらく経ってから、特定のリソース種別だけがポリシーの検証をすり抜けていたことに気づいたのだ。原因はCELのランタイムエラーと",[15,16,17],"code",{},"failurePolicy","設定の組み合わせだった。KyvernoのClusterPolicyからValidatingAdmissionPolicyへ書き換えたポリシーは、本当に「同じ意味」を持っていると言えるのか。この記事では、その具体的な落とし穴と安全な移行手順を整理する。",[11,20,21],{},[22,23],"img",{"alt":24,"src":25},"section01","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fja\u002Fkyverno-validatingadmissionpolicy-cel-migration-silent-bypass\u002Fsection01.webp",[27,28,30],"h2",{"id":29},"_1-clusterpolicyが消える今移行先を決めなければならない理由","1. ClusterPolicyが消える。今、移行先を決めなければならない理由",[11,32,33,34,37,38,52,53,56,57,62],{},"Kyvernoは長らく",[15,35,36],{},"ClusterPolicy","というYAMLベースのパターンマッチ方式でKubernetesのポリシー管理を担ってきた。しかし",[39,40,44,45,47,48,51],"a",{"href":41,"rel":42},"https:\u002F\u002Fnirmata.com\u002F2026\u002F07\u002F26\u002Fkyverno-policy-migration-to-cel-based-policies\u002F",[43],"nofollow","Kyverno 1.17で",[15,46,36],{},"と",[15,49,50],{},"CleanupPolicy","は非推奨(Deprecated)と位置づけられ","、以降のマイナーバージョンでは重大な不具合修正のみが提供される段階に入っている。移行先として用意されているのが、CEL（Common Expression Language）ベースの新しい",[15,54,55],{},"ValidatingPolicy","であり、これはKubernetes本体が1.30でGAした",[39,58,61],{"href":59,"rel":60},"https:\u002F\u002Fkubernetes.io\u002Fdocs\u002Freference\u002Faccess-authn-authz\u002Fvalidating-admission-policy\u002F",[43],"ValidatingAdmissionPolicy","のスーパーセットとして実装されている。",[11,64,65,66,70,71,76,77,82,83,88],{},"ValidatingAdmissionPolicyの最大の強みは、CEL式を",[67,68,69],"strong",{},"kube-apiserverのプロセス内で直接評価する","設計にある。Kyverno\u002FOPA Gatekeeperのような外部Webhookコントローラーをデプロイ・運用する必要がなく、ネットワークホップも発生しない。実際のベンチマークでは、同じ内容のポリシーをCELとWebhookでそれぞれ実行した場合、追加レイテンシの中央値は",[39,72,75],{"href":73,"rel":74},"https:\u002F\u002Fwww.techplained.com\u002Fkubernetes-mutating-admission-policy",[43],"CELが約0.3msに対しWebhookは約1.65ms","という結果が報告されている。",[39,78,81],{"href":79,"rel":80},"https:\u002F\u002Fkubernetes.io\u002Fblog\u002F2022\u002F12\u002F20\u002Fvalidating-admission-policies-alpha\u002F",[43],"Kubernetesが2022年にアルファ版として導入","して以来、",[39,84,87],{"href":85,"rel":86},"https:\u002F\u002Fnirmata.com\u002F2023\u002F09\u002F08\u002Fwhat-is-kubernetes-validating-admission-policy\u002F",[43],"1.30でのGAに至る設計思想","は一貫して「単純な検証はWebhookサーバーの運用コストなしで実現する」という点にある。",[11,90,91],{},[22,92],{"alt":93,"src":94},"section02","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fja\u002Fkyverno-validatingadmissionpolicy-cel-migration-silent-bypass\u002Fsection02.webp",[11,96,97],{},"パフォーマンスと運用負荷の両面でメリットがあるからこそ、多くのチームがKyvernoのワイルドカードポリシー（複数のリソース種別をまとめて検証する設定）をCELベースへ移行しようとしている。だが、この移行には単なる構文変換では済まない落とし穴がある。",[27,99,101],{"id":100},"_2-ワイルドカードポリシーをそのまま移植したら何が起きたか","2. ワイルドカードポリシーをそのまま移植したら何が起きたか",[11,103,104,105,110,111,114,115,119],{},"Kyvernoには",[39,106,109],{"href":107,"rel":108},"https:\u002F\u002Fkyverno.io\u002Fblog\u002F2024\u002F02\u002F26\u002Fgenerate-vaps",[43],"既存のClusterPolicyからValidatingAdmissionPolicyを自動生成する機能","が用意されている。Kyverno管理者コントローラーに生成フラグを立てるだけで、",[15,112,113],{},"match.any.resources.kinds","のようなリソース指定がCEL式に変換され、Kubernetesの",[39,116,118],{"href":59,"rel":117},[43],"ValidatingAdmissionPolicy定義","として自動更新され続ける。",[11,121,122,123,126],{},"しかし、この自動変換には明確な制約がある。ValidatingAdmissionPolicyはKubernetes自身の仕様として",[67,124,125],{},"検証(validate)専用","の仕組みであり、Kyvernoのmutate（書き換え）・generate（自動生成）・image検証といった機能はそもそも対象にできない。複数のルールタイプを1つのClusterPolicyに束ねていた構成ほど、移行時に機能の取りこぼしが発生しやすい。",[11,128,129,130,135],{},"さらに厄介なのが、ワイルドカードで複数リソース種別（Deployment、DaemonSet、StatefulSetなど）をまとめて1本のCEL式で検証するよう移植した場合の挙動だ。Kyverno自身も",[39,131,134],{"href":132,"rel":133},"https:\u002F\u002Fmain.kyverno.io\u002Fdocs\u002Ftroubleshooting\u002Fcel-expressions",[43],"CEL式のトラブルシューティングガイド","で、オプショナルなフィールドへの未チェックアクセスが典型的な事故原因になると明記している。",[11,137,138],{},[22,139],{"alt":140,"src":141},"section03","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fja\u002Fkyverno-validatingadmissionpolicy-cel-migration-silent-bypass\u002Fsection03.webp",[27,143,145],{"id":144},"_3-原因はcelのフィールド欠落エラーとfailurepolicy-ignoreの組み合わせ","3. 原因はCELのフィールド欠落エラーと、failurePolicy: Ignoreの組み合わせ",[11,147,148,149,152,153,156,157,160,161,164],{},"ここが本記事の核心だ。CEL式の中で参照する",[15,150,151],{},"object","変数は、リソース種別によって存在するフィールドが異なる。たとえば",[15,154,155],{},"object.spec.replicas","はDeploymentには存在するが、DaemonSetには存在しない。ワイルドカードでこれらを一括検証するCEL式に",[15,158,159],{},"has()","によるガードが欠けていた場合、DaemonSetへのリクエストが来た瞬間に",[67,162,163],{},"ランタイムエラー","が発生する。",[11,166,167,170,171,174,175,178,179,181,182,185,186,189,190,193],{},[15,168,169],{},"matchConditions","の評価ロジックは次の通りだ。いずれかの条件が",[15,172,173],{},"FALSE","ならポリシーはスキップされる。一方、いずれかの条件が",[67,176,177],{},"エラー","を返した場合は",[15,180,17],{},"の設定に従う。",[15,183,184],{},"failurePolicy: Fail","（デフォルト）であればリクエストは安全側に倒れて拒否されるが、移行作業中に「既存の挙動を壊したくない」という理由で",[15,187,188],{},"failurePolicy: Ignore","に設定しているケースが少なくない。この場合、",[67,191,192],{},"ポリシーの評価自体が黙ってスキップされ、本来ブロックすべきリクエストがそのまま通過する","。",[11,195,196,201,202,206],{},[39,197,200],{"href":198,"rel":199},"https:\u002F\u002Fwww.chainguard.dev\u002Funchained\u002Fare-kubernetes-validating-admission-policies-the-end-of-admission-controllers",[43],"Chainguardの分析","も、ValidatingAdmissionPolicyが単純な検証には有効である一方、イメージ署名の検証や外部データ参照のような複雑な要件では従来のアドミッションコントローラーが依然として必要だと指摘しており、「移行すれば全て解決する」わけではないことがうかがえる。",[39,203,205],{"href":73,"rel":204},[43],"実際のベンチマーク記事でも","、ラベルに整数値を設定したポリシーがポリシー作成時の型チェックをすり抜け、実行時に全リクエストが拒否される事例が報告されている。型チェックの不完全さとランタイムエラーの扱いは、CELベースの検証設計で最も見落とされやすいポイントだ。",[11,208,209],{},[22,210],{"alt":211,"src":212},"section04","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fja\u002Fkyverno-validatingadmissionpolicy-cel-migration-silent-bypass\u002Fsection04.webp",[11,214,215,216,221],{},"この問題は、以前",[39,217,220],{"href":218,"rel":219},"https:\u002F\u002Fkubo.hexabase.io\u002Fblog\u002Fja\u002Fkyverno-opa-gatekeeper-k3s-wildcard-policy-overhead",[43],"Kyverno\u002FOPA Gatekeeperのワイルドカードポリシーのオーバーヘッドを比較した記事","でも触れた「複数リソース種別の一括検証」というテーマの延長線上にある。ツールを選ぶ段階では見えなかったリスクが、CELへの移行段階で初めて表面化した形だ。",[11,223,224,225,230],{},"こうした「検証されるはずのものが静かに通過する」という事故は、",[39,226,229],{"href":227,"rel":228},"https:\u002F\u002Fkubo.hexabase.io\u002Fblog\u002Fja\u002Fk3s-pod-security-admission-restricted-servicelb-outage",[43],"K3sのPod Security Admissionで起きた設定差分の問題","とも構造が似ている。アドミッション制御の仕組みは、正しく機能している限りは目立たないが、設定の境界条件を誤ると沈黙のまま実害を生む。",[11,232,233,234,237,238,243],{},"K8s運用の現場でこうした「見えないリスク」をゼロにするのは難しいが、少なくとも",[67,235,236],{},"ポリシーの適用状況とDeny\u002FAuditの実績を可視化","できていれば、異常の検知は大きく早まる。",[39,239,242],{"href":240,"rel":241},"https:\u002F\u002Fkubo.hexabase.io\u002F",[43],"Kubo","のCaptain UIは、こうした運用の透明性を標準で提供することを目指して設計されている。",[27,245,247],{"id":246},"_4-安全な移行手順-hasガードaudit先行段階的ロールアウト","4. 安全な移行手順 — has()ガード、Audit先行、段階的ロールアウト",[11,249,250],{},"実運用でCELベースのポリシーへ移行する際は、以下の手順を踏むことでリスクを抑えられる。",[252,253,255],"h3",{"id":254},"cel式にガード句を必ず入れる","CEL式にガード句を必ず入れる",[11,257,258,259,261,262,265],{},"オプショナルなフィールドを参照する箇所には、必ず",[15,260,159],{},"や",[15,263,264],{},"?","によるオプショナルチェイニング構文でガードを入れる。「このリソース種別にこのフィールドが存在するか」を前提にせず、明示的に確認する設計にすることが、ランタイムエラーそのものを防ぐ最も基本的な対策だ。",[252,267,269],{"id":268},"failurepolicyはfailを基本にする","failurePolicyはFailを基本にする",[11,271,272,273,275,276,279,280,282],{},"移行初期は「挙動を壊したくない」という理由で",[15,274,188],{},"にしたくなるが、これは",[67,277,278],{},"検証漏れを許容する","ことと同義になる。重要なポリシーほど",[15,281,184],{},"を基本にし、意図的にIgnoreを選ぶ場合はその理由とリスクをドキュメント化すべきだ。",[252,284,286],{"id":285},"いきなりdenyにせずauditで先行検証する","いきなりDenyにせず、Auditで先行検証する",[11,288,289,307,308,310,311,313],{},[39,290,292,295,296,299,300,299,303,306],{"href":59,"rel":291},[43],[15,293,294],{},"validationActions","には",[15,297,298],{},"Deny","\u002F",[15,301,302],{},"Warn",[15,304,305],{},"Audit","の3種類が用意されており","、",[15,309,305],{},"を使えば実際にリクエストをブロックすることなく、ポリシーがどう評価されるかをログで確認できる。本番環境で予期しない挙動がないかを数日〜数週間観察してから",[15,312,298],{},"へ切り替える、段階的なロールアウトが安全だ。",[252,315,316],{"id":316},"リソース種別ごとにポリシーを分割する",[11,318,319,320,323],{},"ワイルドカードで複数リソース種別をまとめる設計は一見効率的に見えるが、CEL式が複雑になるほどガード漏れのリスクが上がる。",[15,321,322],{},"matchConstraints.resourceRules","をリソース種別ごとに分割し、それぞれに適したCEL式を書く方が、結果的に保守性も検証網羅性も高くなる。",[11,325,326],{},[22,327],{"alt":328,"src":329},"section05","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fja\u002Fkyverno-validatingadmissionpolicy-cel-migration-silent-bypass\u002Fsection05.webp",[11,331,332,333,337],{},"こうした段階的な移行は、インフラチームだけで完結させるのが理想だが、実際には「何をAuditで確認すべきか」「いつDenyに切り替えて良いか」の判断に経験が必要になる。",[39,334,336],{"href":240,"rel":335},[43],"Kubo Cloud","のCaptain UIなら、ポリシーのAudit結果とDeny実績を同じ画面で確認できるため、移行判断のための材料をチームで共有しやすくなる。",[11,339,340,341,346],{},"金融・医療など、ポリシー違反が即座にコンプライアンス問題へつながる業種では、ポリシー移行そのものを外部に相談しながら段階的に進めたいというニーズも強い。そうした要件には、自社管理の環境でポリシー運用を完結できる",[39,342,345],{"href":343,"rel":344},"https:\u002F\u002Fwww.hexabase.com\u002Fproduct\u002Fkubo\u002Fon-premise",[43],"Kubo On-Premise","が選択肢になる。",[27,348,350],{"id":349},"まとめ-cel移行は速いだけでなく静かに失敗するリスクも持つ","まとめ — CEL移行は「速い」だけでなく「静かに失敗する」リスクも持つ",[11,352,353,354,356,357,362],{},"ValidatingAdmissionPolicyは、外部コントローラー不要・低レイテンシという明確なメリットを持つ一方で、CEL式のランタイムエラーと",[15,355,17],{},"の設定次第では「検証されないリソースが静かに生まれる」というリスクを内包している。",[39,358,361],{"href":359,"rel":360},"https:\u002F\u002Fkubernetes.io\u002Fdocs\u002Fconcepts\u002Fcluster-administration\u002Fadmission-webhooks-good-practices\u002F",[43],"Kubernetesのアドミッションウェブフック運用ガイド","が繰り返し強調しているのも、結局のところ「失敗時にどちらへ倒すか」を設計段階で明示することの重要性だ。KyvernoのClusterPolicyが廃止に向かう今、多くのチームがこの移行に直面するはずだ。",[11,364,365,366,368,369,371,372,374],{},"移行時のチェックリストとしては、①",[15,367,159],{},"ガードの徹底、②",[15,370,184],{},"を基本方針にする、③",[15,373,305],{},"での先行検証、④リソース種別ごとのポリシー分割、の4点を押さえておきたい。CELに書き換えたポリシーが「本当に同じ意味」を持っているかどうかは、構文を見るだけでは分からない。実際のリクエストを通して検証する仕組みを、移行プロセスそのものに組み込む必要がある。",[11,376,377,378,381,382,387],{},"こうした地味だが重大な運用上の判断を、属人化させずにチームで共有できる基盤として、",[39,379,242],{"href":240,"rel":380},[43],"はAI-Driven DeploymentとCaptain UIによる可視化を標準搭載している。ポリシー移行のような「成功しても目立たず、失敗すると静かに実害が出る」作業こそ、基盤側の透明性が効いてくる。興味があれば、",[39,383,386],{"href":384,"rel":385},"https:\u002F\u002Fwww.hexabase.com\u002Fcontact-us\u002F",[43],"お問い合わせ","から相談してみてほしい。",{"title":389,"searchDepth":390,"depth":390,"links":391},"",2,[392,393,394,395,402],{"id":29,"depth":390,"text":30},{"id":100,"depth":390,"text":101},{"id":144,"depth":390,"text":145},{"id":246,"depth":390,"text":247,"children":396},[397,399,400,401],{"id":254,"depth":398,"text":255},3,{"id":268,"depth":398,"text":269},{"id":285,"depth":398,"text":286},{"id":316,"depth":398,"text":316},{"id":349,"depth":390,"text":350},"2026-10-18","KyvernoのClusterPolicyが廃止へ向かう中、ValidatingAdmissionPolicy（CEL）に移行したら一部リソースだけ検証が素通りしていた。原因のCELランタイムエラーとfailurePolicyの罠、安全な移行手順を解説する。","md","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fja\u002Fkyverno-validatingadmissionpolicy-cel-migration-silent-bypass\u002Ftitle.webp","ja",{},true,"\u002Fblog\u002Fja\u002Fkyverno-validatingadmissionpolicy-cel-migration-silent-bypass",{"title":5,"description":404},"blog\u002Fja\u002Fkyverno-validatingadmissionpolicy-cel-migration-silent-bypass",[414,415,416,417,418,419],"k3s","kubernetes","validatingadmissionpolicy","kyverno","cel","admission-control","qEi3fwSaiREssDh8t4vd4MHGHp38rwIlo3wmq0ZJOBk",[422,430,438,447,457,469],{"path":423,"title":424,"description":425,"date":426,"tags":427},"\u002Fblog\u002Fja\u002Fkyverno-opa-gatekeeper-k3s-wildcard-policy-overhead","KyvernoとOPA Gatekeeper、K3sの本番で本当に差が出たのはワイルドカードポリシーだった","KyvernoとOPA GatekeeperはK3sの本番運用でどちらを選ぶべきか。ワイルドカードポリシーが招く負荷急増とレプリカ構成別のp99レイテンシ実測データから、K3s特有の判断基準を整理する。","2026-10-11",[414,415,417,428,419,429],"opa-gatekeeper","policy-as-code",{"path":431,"title":432,"description":433,"date":434,"tags":435},"\u002Fblog\u002Fja\u002Fshadow-ai-kubernetes-admission-control-governance","野良デプロイが会社を壊す。KubernetesクラスターのシャドーAI問題とAdmission Controlという処方箋","SaaSの無断導入だけがシャドーAIではない。Kubernetesクラスター内で誰が何をデプロイしているか分からない状態が生むリスクと、Admission Controlによるガバナンス実装を解説する。","2026-07-17",[415,414,436,419,417,437],"shadow-ai","security",{"path":439,"title":440,"description":441,"date":442,"tags":443},"\u002Fblog\u002Fja\u002Fcicd-pipeline-devsecops-gate-design-four-layers","そのCI\u002FCDパイプライン、セキュリティチェックをどこに置くか決めずに継ぎ足していないか。DevSecOpsゲート設計の4層モデル","SASTもDASTもコンテナスキャンも導入した。それでも本番で事故は起きる。CI\u002FCDパイプラインのセキュリティを『4つの層』で設計し直すDevSecOpsゲート設計の考え方を、K3s\u002FKubernetes運用の観点から解説する。","2026-08-28",[414,415,444,445,419,446],"ci-cd","devsecops","gitops",{"path":448,"title":449,"description":450,"date":451,"tags":452},"\u002Fblog\u002Fja\u002Fk3s-hpa-containerresource-sidecar-utilization-dilution","HPAがサイドカーの分まで合算してスケールしていた。KubernetesのContainerResourceという盲点","KubernetesのHPAはPod内の全コンテナの使用量を合算して利用率を計算するため、Istioサイドカーやログエージェントの負荷が判定を薄める。ContainerResourceメトリクスで解決する方法をK3s\u002FKubo文脈で解説する。","2026-10-21",[414,415,453,454,455,456],"hpa","containerresource","autoscaling","service-mesh",{"path":458,"title":459,"description":460,"date":461,"tags":462},"\u002Fblog\u002Fja\u002Fk3s-vs-kubernetes-cni-flannel-default-comparison","K3s vs 標準Kubernetes、CNIの出発点はここまで違う。Flannel標準搭載とCNI選択制が生む差","K3sはFlannelをデフォルト同梱し、標準KubernetesはCNI未選定の状態から始まる。この出発点の違いがNetworkPolicyの可否や通信性能にどう影響するかを、K3s\u002FKubernetes\u002FCalico\u002FCiliumの公式ドキュメントをもとに比較・解説する。","2026-10-20",[414,415,463,464,465,466,467,468],"cni","flannel","calico","cilium","networkpolicy","networking",{"path":470,"title":471,"description":472,"date":473,"tags":474},"\u002Fblog\u002Fja\u002Fk3s-topology-spread-constraints-poddisruptionbudget-node-drain-pending","ノードをdrainしたらPodがPendingのまま戻らなかった。K3sでTopology Spread ConstraintsとPodDisruptionBudgetが衝突する理由","K3s本番でノードをdrainしたら一部PodがPendingのまま戻らなかった。原因はTopology Spread ConstraintsのmaxSkewとPodDisruptionBudgetの衝突。drainがノード数不足を自ら作り出す仕組みを公式ドキュメントベースで検証する。","2026-10-19",[414,415,475,476,477,478],"topology-spread-constraints","poddisruptionbudget","scheduling","node-drain",1792592621315]