Policy Engine on KubernetesVMware DevOps Meetup #8 (2021/03/24)
View Slide
自己紹介Name: ry (@URyo_0213)Skillset:- Storage- Ansible (Ansible Tower, AWX)- Python, django- KubernetesAdvertisement- Kubernetes Meetup Novice (月1回ペース)- Kubenews (毎週金曜日 22:00 ~ )- Kubernetes Internal
まず初めに
PSP(Pod Security Policy)適用されたPodの仕様を確認し、事前に適用されたPSPに記載されているポリシーによって、Podの作成を制御するためのものです。Deprecated in Kuberenets version 1.21Remove the API completely in Kuberentes version 1.25Kubernetes上でPolicyによる制御を何でやっていけばいいのだろうか。。。
Kubernetes上で『Policyによる制御』といえば?
OPA (Open Policy Agent)Admission Webhook機能を用いて、・Validating・Mutating等を行うことができるツール。独自のRegoという言語を用いることで、柔軟なPolicyの作成が可能。
Admission ControlAuthenticationAuthorizationMutatingAdmissionObjectSchemaAdmissionValidatingAdmissionPersisted toetcdwebhookwebhook webhookwebhook
Validating / Mutating1Validating作成するリソースが、 Policyと比較して許可していいものなのか、それとも拒否すべきものなのかを判断する。2Mutating作成するリソースに対して、 Parameterの追加や変更をかける。
Rego前回のVMware DevOps Meetup #7 において、とても分かりやすい構文の解説などがありましたので参照いただけると良いかと思います。Open Policy Agent (OPA) 入門
RegoThe Rego Playground を使って練習できます。
ここまで来たところで.....Regoかぁ...なんで新しい言語作るの?
OPAを少しでも簡単に使うためにStyra DAS というOPAのPolicyをGUIから適用していくことができるツールがあります。簡単な使い方や、実際にPolicyをによる判断を行う際に参照されるAdmissoin Reviewというリソースについて下のBlogでご紹介しています。Styra DASを使ってOPAをより簡単に
今日の本題
KyvernoOPA同様にAdmission Webhookを用いてValidating / Mutating 等のPolicyを適用することができるツール。KubernetesのManifestの様にPolicyを適用できるので、学習コストが低い。
Policy Structurehttps://kyverno.io/docs/writing-policies/structure/
MatchPolicyを適用する対象を記載するものです。dict型はAND, list型はOR今回のケースでは、kindが「Deployment」もしくは「Statefulset」かつlabelに「app: critical」とあるもの
ExcludeMatchに記載したものの中で、例外を作る場合に使用します。今回のケースでは、対象はPodただし、kube-system内のPodは除く
Policy (Validating)spec.rulesの下で設定match: Policyを適用するリソースを指定- Podを指定validate: 検証内容、及び違反した際のmessageを記述- Resource limit及びrequestが設定されてない場合、作成が許可されない
Policy (Validating)Pod用 manifest(Resource unit なし)Policy CheckPod用 manifest(Resource unit あり)Pod作成
Policy (Validating)
Policy (Validating)Policyを追加したことで、作成が承認されました。
Policy (Mutating)● RFC 6902 JSONPatch● Strategic Merge Patch● Mutate Overlay● Mutate Rule Ordering (Cascading)
Policy (Mutating - overlay -)spec.rulesの下で設定match: Policyを適用するリソースを指定- Podを指定mutate: 変更する項目を記載- 特定のlabelをトリガーに、VaultからSecretを取得するためのannotation、及びService Accountを追加
Policy (Mutating - overlay -)Policy CheckPod用 manifest(指定labelあり)Pod作成(Secret Injected)Pod用 manifestAnnotationService Account追加VaultPod用 manifestVault InitContainerVault Sidecar追加Annotation確認
Policy (Mutating - overlay -)Vault上に、情報を格納する# vault secrets enable -path=vmware kv-v2# vault kv put vmware/devops/8 username="vmware-devops" password="waiwai"作成したリソースに対するPolicyを設定する# vault policy write vmware - <path "vmware/data/devops/8" {capabilities = ["read"]}EOF
Policy (Mutating - overlay -)kubernetes上のリソースとの紐づけをする。# vault write auth/kubernetes/role/vmware \bound_service_account_names=vmware \bound_service_account_namespaces=default \policies=vmware \ttl=24h上記のコマンドで指定したService Accountを作成する。# kubectl create sa vmware
Policy (Mutating - overlay -)
Policy (Generating)match: Policyを適用するリソースを指定- Namespaceを指定- 4つのNamespaceを例外とする。generate: 作成するリソースを指定- NetworkPolicyを作成する。
Policy (Generating)
最後に
SummaryKeyvernoでは、ManifestライクにPolicyの宣言を行うことのできる。Kyvernoは、Regoのような特殊な言語がないため、学習コストが低区始めやすい。OPAにはないGeneratingという機能はとても有用。
OPA vs Kyverno以下のBlogにて、さまざまな項目の比較を表形式で載せてくれているので参考にしていただければと思います。Kubernetes Policy Comparison: OPA/Gatekeeper vs Kyverno
今回使用したPolicyGithubの方にあげていますので、ご参照ください。kyverno-sample
Thank you