ACS事業部の谷合です。
CELを用いた新しいValidation方式の紹介のセッションに参加しましたので、その方式とBest Practiceについて解説します。
CELを使ったValidationとは
まずCELとは、Common Expression Languageから頭文字をとった略語です。
CELでもValidationが登場するまでは、ValidatingAdmissionWebhookを実装してValidationを行っていました。
CELでのValidartionが登場してからというものの、CRDにポリシーを記載できるようになり、ValidatingAdmissionWebhookの
不要論さえでてきています。
Common Expression Language
CELはGoogleが作った言語です。
詳細に勉強する場合は以下のリポジトリをご確認ください。
github.com
CELには以下の理念があるそうです。
1. Keep it small & fast.
構文の評価は素早くされるべき
2. Make it extensible.
CELはアプリケーションに組み込む前提で設計されており、組み込む際は拡張が容易なこと
3. Developer-friendly.
ライブラリや付属のツールも容易に扱える
KubernetesでCELを使う場合は以下のReferenceをご確認ください。 kubernetes.io
validate方式
x-kubernetes-validations
CRDの定義に直接Validation Ruleを記載する方式です。
openAPIV3Schema.spec.x-kubernetes-validationにRuleを記載します。
self.minReplicasと記載されていたりしますが、selfというのは現在のスキーマの値へのアクセスすることを指します。
: openAPIV3Schema: type: object properties: spec: type: object x-kubernetes-validations: - rule: "self.minReplicas <= self.replicas" message: "replicas should be greater than or equal to minReplicas." - rule: "self.replicas <= self.maxReplicas" message: "replicas should be smaller than or equal to maxReplicas." properties: :
ValidatingAdmissionPolicy
OPAなど元々存在していたPolicy Engineなどと同様に、CRDでなく専用のリソースにCELでRuleを記載して、Validationを行う方式です。Kubernetes v1.26から登場し、1.27現在でもAlphaの状態です。
以下のようにValidatingAdmissionPolicyを作成し、それをValidatingAdmissionPolicyBindingにひもづけることで、Validationが機能するようになります。
kubernetes.io
apiVersion: admissionregistration.k8s.io/v1alpha1 kind: ValidatingAdmissionPolicy metadata: name: "demo-policy.example.com" spec: failurePolicy: Fail matchConstraints: resourceRules: - apiGroups: ["apps"] apiVersions: ["v1"] operations: ["CREATE", "UPDATE"] resources: ["deployments"] validations: - expression: "object.spec.replicas <= 5" --- apiVersion: admissionregistration.k8s.io/v1alpha1 kind: ValidatingAdmissionPolicyBinding metadata: name: "demo-binding-test.example.com" spec: policyName: "demo-policy.example.com" validationActions: [Deny] matchResources: namespaceSelector: matchLabels: environment: test
Best Practice
matchConditions
きめ細かいリクエストフィルタリングが必要な場合に備えて、新しい matchConditions フィールドが追加されました。
以下のように記載することで、すべてtrueになった場合にリソース作成などといった使い方ができます。
matchConditions: - name: 'exclude-leases' # Each match condition must have a unique name expression: '!(request.resource.group == "coordination.k8s.io" && request.resource.resource == "leases")' # Match non-lease resources. - name: 'exclude-kubelet-requests' expression: '!("system:nodes" in request.userInfo.groups)' # Match requests made by non-node users. - name: 'rbac' # Skip RBAC requests. expression: 'request.resource.group != "rbac.authorization.k8s.io"'
policy.failurePolicy
CELの設定ミスやRuntimeエラーなどでPolicyの評価ができない場合にどうするかを定義します。
設定値ごとに以下の挙動となります。
- Fail: APIリクエストが拒否される
- Ignore: エラーが無視される
https://kubernetes.io/docs/reference/access-authn-authz/validating-admission-policy/#failure-policy
policy.validationActions
ポリシーのバリデーションがどのように実施されるかを宣言するため使用します。
- Deny: バリデーションに失敗すると、リクエストは拒否される
- Warn: バリデーションに失敗すると、警告を上げる
- Audit: API リクエストの監査イベントにバリデーション失敗が含まれる
https://kubernetes.io/docs/reference/access-authn-authz/validating-admission-policy/#validation-actions
作りこもうとしたら、なかなか複雑になりそうですが、うまくCELと付き合っていけば外部のPolicy Engineなしで値の評価ができそうですね。まだalphaでGAはまだまだ先になりそうですが、楽しみに待ちたいと思います。
ACS事業部のご紹介
私達ACS事業部はAzure・AKSなどのクラウドネイティブ技術を活用した内製化のご支援をしております。
www.ap-com.co.jp
また、一緒に働いていただける仲間も募集中です！
今年もまだまだ組織規模拡大中なので、ご興味持っていただけましたらぜひお声がけください。
www.ap-com.co.jp
