KyvernoとRed Hat ACMを用いたマルチクラスターの一元的なポリシー制御

KyvernoとRed Hat ACM for Kubernetesを用いたマルチクラスターの一元的なポリシー制御 2023/01/27 OpenShift.Run 2023 Ryotaro
Uwatsu

Copyright © Dell Inc. All Rights Reserved. 2 of Y
自己紹介 Name: Ryotaro Uwatsu (@URyo_0213) Title: Solutions Architect Community: - Kubernetes Meetup Novice 運営 - Kubenews - Cloud Native Days Tokyo

Table of contents • Kyverno • Kyvernoにおけるポリシー制御 • Red Hat Advanced Cluster Management for Kubernetes

Kyvernoとは

Kyverno KyvernoはKubernetesクラスター内で、Dynamic Admission Controllerとして実行されるポリシーエンジン。 kube-apiserverからAdmission Webhookを受け取り、定義したポリシーに基づいて制御を実行します。 Custom Resourceを用いて、Kubernetesのマニフェストベースでポリシーを適用できるため、学習コストがとても低い。バージョン: 1.8.0 https://github.com/kyverno/kyverno

Dynamic Admission Control Authentication Authorization Mutating Admission Object Schema Admission Validating Admission Persist data to etcd Webhook Webhook Webhook Webhook Kyverno

Kyvernoの利点 1. 学習コストが低い他のOPAやjsPolicyなどでは、固有の言語を覚える必要がります。一方で、Kyvernoでは、Kubernetesのマニフェストをベースに記載することができます。 OPA Gatekeeper (Rego) jsPolicy (JavaScript or TypeScript) Kyverno

Kyvernoの利点 2. 豊富な機能他のツールでは実装されていない機能が、Kyvernoでは使うことができます。 Name Validation Mutation Generation Image Verification Metric Exposed Policy Engine OPA Gatekeeper Yes Yes No Yes (via extensions) Yes jsPolicy Yes Yes No No No Kyverno Yes Yes Yes Yes Yes

Kyvernoの利点 3. 開発が活発他ツールと比べ開発が活発であり、新機能の追加や改善のサイクルが早い。 Name Star Fork Release Contributor Commit Policy Engine OPA Gatekeeper 2.9k 21 9 174 1,174 jsPolicy 249 637 73 9 124 Kyverno 3.4k 489 158 197 5,312

Kyvernoにおけるポリシー制御

Kyvernoによるポリシーの適用 Kyvernoを用いてポリシーを適用する際に用いるリソースは2つあります。 1. Cluster Policy: クラスター全体にポリシーを適用する際に用いる。 2. Policy: Namespace内に閉じたポリシーを適用する際に用いる。注意点としては、ポリシー間での順序性が存在しないため、複数のポリシーを組み合わせたルールの拡張しかできません。すなわちPolicy間での上書きができないので、Cluster Policyで厳しめのPolicyを設定しておいて、あるNamespaceにおいてはPolicyを用いて制限を緩めるということができません。

ポリシー構造 Policy Rule Preconditions Match Exclude Validate Resources Mutate Resources Generate Resources Verify Images 対象の決定アクション

ポリシー構造

詳しい記述方法について Cloud Native Days Tokyo 2022 にて、ポリシーの詳細な記述方法等について紹介しています。登壇資料は、Twitter(@Uryo_0213) の固定ツイートにもあります。 https://event.cloudnativedays.jp/cndt2022/talks/1568

対象の決定 Match (必須) ルールを適用するリソースを指定する。 Exclude Preconditions 以下の3つの表現を用いて、ポリシーを適用する対象を決めていきます。 (オプショナル) Matchで指定したリソースに対し例外を指定する。 (オプショナル) Match等による対象決定のフェーズに進むどうかかを判断する。

Validate Resources ユーザーまたはプロセスによって新しいリソースが作成される場合に、そのリソースを作成してよいか否かを判断するために用います。 spec.rules[*].validateを用いて記述していくことになります。ルールに違反するリソースに対する挙動はspec.validationFailureActionによって制御することが可能です。 • enforce – ルールに違反した場合、作成をブロックする。 • audit – ルールに違反した場合に作成は許可する – ポリシーレポートに違反するリソースとして記録する。

Validate Resourcesのユースケース① 特定のラベルが設定されていないリソースの作成を拒否する。 Pod Pod Namespace: app1

Validate Resources ユースケース① Code Repository Manifest Repository Push CI Tool Manifest with label CD Tool Kubernetes Namespace: app1 Pod Pod

Validate Resources ユースケース① spec.rules[0].matchにおいてPodを指定し、 spec.rules[0].validateにおいて、作成されるPodの metadata.labelsに「managed-by: cicd-pipeline」があるのかを検証しています。 validationFailureActionを「enforce」にすることで、作成を拒否します。

Validate Resources ユースケース② 必要なパラメータが設定されているのかを確認する。

Validate Resources ユースケース② spec.rules[0].matchにおいてPodを指定し、 spec.rules[0].validateにおいて、作成されるPodの spec.containers[*].resourcesにおいて、CPUとMemory に対するlimitsとrequestsが設定されているのかを検証しています。 validationFailureActionを「audit」にすることで、作成は拒否せず、Policy Reportに違反を記録します。 (PolicyReport)

Mutate Resources ルールに一致したリソースに対して、パラメータに変更を加える際に用います。 spec.rules[*].mutateを用いて記述していくことになります。以下の項目を用いてルールを適用することができます。 • RFC 6902 JSONPatch • Strategic Merge Patch • Foreach

Manifest Repository Mutate Resources ユースケース GitOps等を実施していくうえで、シークレット情報の管理は複雑です。 Secretは手動で適用するようにすると、運用上のミスに気づけません。 Deployment Service PVC CD Tool Kubernetes Secret

Manifest Repository Mutate Resources ユースケース変更をトレースできるように、Manifest Repository上で管理するようにすると、セキュリティの観点においてリスクになってしまいます。 Deployment Service PVC CD Tool Kubernetes Secret

Manifest Repository Mutate Resources ユースケース対策としてExternal Secretなどがありますが、これも結果的にSecretに関する情報をレポジトリに置いてしまっていたり、環境的な制約があったりします。 Deployment Service PVC CD Tool Kubernetes External Secret Secret Store External Secret Secret

Mutate Resources ユースケース Hashicorp Vaultを用いることで、シークレット情報の一元管理ができ、Podにシークレット情報を容易に引き渡すことができます。以下のようにアノテーションを設定することで、Init Containerが挿入され、特定のディレクトリにシークレット情報を格納してくれます。この機能を利用して、Podにラベルを仕込んでおくだけで、シークレット情報に関係するものをレポジトリに載せることなく、Podに引き渡すことができます。

Mutate Resources ユースケース ① 指定のラベル(例: osrun-vault-injection=“true“)を付与したマニフェストをプッシュする。 Manifest Repository Pod Kubernetes label

Mutate Resources ユースケース ② このレポジトリの更新をトリガーに、CDがPodの作成を開始する。 Manifest Repository Pod Kubernetes CD Tool label Pod label

Mutate Resources ユースケース ③ 付与したラベルを事前に設定しておいたPolicyが認識し、アノテーションを付与する。 Manifest Repository Pod Kubernetes CD Tool label Pod label Pod label Kyverno Policy annotation

Mutate Resources ユースケース ④ このアノテーションをトリガーに、VaultがPodにInit Containerを挿入する。 Manifest Repository Pod Kubernetes CD Tool label Pod label Pod label Kyverno Policy annotation Vault Pod label annotation Init Container

Namespace app1 Mutate Resources ユースケース ⑤ Init Containerが、アノテーションを基に、シークレット情報を格納する。 Manifest Repository Pod Kubernetes CD Tool label Pod label Pod label Kyverno Policy annotation Vault Pod label annotation Init Container Pod Secret file

Mutate Resources ユースケースこのルールでは、osrun-vault-injection: “true”というラベルを持つPodが作成された際に、Vaultに登録をした特定のシークレットデータを、Pod内に指定のフォーマットで配置するためのアノテーションとサービスアカウントを付与しています。

Mutate Resources ユースケース $ vault secrets enable -path=secret kv-v2 $ vault kv put secret/osrun/config username="static-user" password="static-password" $ vault policy write osrun - <<EOF path "secret/data/osrun/config" { capabilities = ["read"] } EOF $ vault write auth/kubernetes/role/osrun \ bound_service_account_names=osrun \ bound_service_account_namespaces=default \ policies=osrun \ ttl=24h

Mutate Resources ユースケース GUIからもシークレット情報を作成可能です。

Mutate Resources ユースケース $ kubectl apply –f strategicMerge.yaml $ kubectl create sa osrun -n default $ kubectl run osrun-app --image nginx:alpine -l osrun-vault-injection="true“ $ kubectl exec -it osrun-app -- cat /vault/secrets/osrun-credentials Defaulted container "osrun-app" out of: osrun-app, vault-agent, vault-agent-init (init) USERNAME=static-user PASSWORD=static-password

Generate Resources 新しいリソースが作成された際、追加のリソースを作成する場合に用います。 spec.rules[*].generateを用いて記述していくことになります。作成するリソースの情報を、以下の2つを用いて記述することができる。 • data: 作成するリソースの情報を記述する • clone: 既に存在するリソースをクローンする

Generate Resources ユースケース (clone) Namespace app3 Namespace app2 Namespace app1 imagePullSecret imagePullSecret imagePullSecret Kubernetes

Generate Resources ユースケース (clone) Namespace app3 Namespace app2 Namespace app1 imagePullSecret imagePullSecret imagePullSecret Policy Kubernetes Namespace credential Label private-reg: “true” Label private-reg: “true” Label private-reg: “true” imagePullSecret

Generate Resources ユースケース (clone) spec.rules[*].generate下では、以下を記述します。 • synchronize: ソースリソースとの同期 – true:同期をし、更新や削除ができない – false: 同期はせず、生成されたリソースを直接更新または削除できる • apiVersion: 生成するリソースのapiVersion • kind: 生成するリソース • name: 生成するリソース名 • namespace: リソースを生成するNamespace • clone: Namespace及びリソース名を記述

Verify Images Cosignを使用して、OCIレジストリに格納されているイメージの署名および証明を検証します。現状、ベータ機能であり、プロダクション環境での使用は推奨されていません。 spec.rules[*].verifyImagesを用いて記述していくことになります。

Verify Images Example imageReferencesにおいて、指定されているイメージがattestors下で指定されているキーを用いて署名がされているということを検証します。署名をされていないイメージ及び、指定したキーと対ではないキーによって署名されたイメージがこの検証によって拒否されることになります。

Red Hat Advanced Cluster Management for Kubernetes

Redhat Advanced Cluster Management for Kubernetes Redhat Advanced Cluster Management for Kubernetes (以下、ACMという)では、単一のコンソールで、クラスター管理や管理対象へのアプリケーションのデプロイ、ポリシー制御などをすることができます。

Cloud Redhat Advanced Cluster Management for Kubernetes ACMは、OpenShift上に構築されます。 ACMを構築したクラスターをHub Cluster、管理されるクラスターをManaged Clusterと呼びます。 Support Matrix for ver.2.6 (https://access.redhat.com/articles/6968787) OpenShift Container Platform Redhat ACM for k8s OpenShift on vSphere OpenShift on AWS (ROSA) OpenShift on Azure (ARO) On Premise Managed Cluster Hub Cluster

マルチクラスターに対するポリシー制御各ステージごとにクラスターを作り、アプリケーションのネームスペースに、組織として定めたポリシーを設定していくような場合に、初期においてはあまり問題がありません。 Dev Cluster Stg Cluster Prd Cluster Policy A Policy A app1 app1 Policy A app1

マルチクラスターに対するポリシー制御アプリケーションやクラスターがスケールしていった場合、だんだんとこれらを管理していくことが難しくなっていきます。これに対し、CDツール等を使う場合、様々な考慮点が発生します。 Dev Cluster Stg Cluster Prd Cluster Policy A Policy A app1 app1 app2 app2 Policy A Policy A Policy A Dev Cluster (HA) Stg Cluster (HA) Prd Cluster (HA) Policy A Policy A app1 app1 app2 app2 Policy A Policy A Policy A app1 app1

Redhat ACM for k8s Policy A マルチクラスターに対するポリシー制御 ACMを用いると、ACM内でPolicyを管理することで、管理対象のクラスターにそのポリシーを伝播させることができます。 Dev Cluster Stg Cluster Prd Cluster Policy A Policy A app1 app1 app2 app2 Policy A Policy A Policy A Dev Cluster (HA) Stg Cluster (HA) Prd Cluster (HA) Policy A Policy A app1 app1 app2 app2 Policy A Policy A Policy A app1 app1

Governance on ACM ACMでは、以下のようなリソースを用いてポリシーの制御を行います。 Redhat ACM for k8s PlacementBinding PlacementRule Policy / PolicySet Dev Cluster Policy app1 Policy app1 Hub Cluster Stg Cluster Prd Cluster

Governance on ACM PolicyとKyvernoを連携させることが可能です。 Redhat ACM for k8s PlacementBinding PlacementRule Policy / PolicySet Dev Cluster Policy app1 Policy app1 Kyverno Kyverno Kyverno ※ Hub ClusterとManaged Clusterの双方に Kyvernoをインストールする必要があります。 Hub Cluster Stg Cluster Prd Cluster

ACMで用いるカスタムリソース・Policy ポリシーの定義を書くためのリソースです。オレンジ色で囲った箇所にKyvernoのポリシーを記載することで、KyvernoのポリシーをACMから管理することができます。 Kyverno Policy

ACMで用いるカスタムリソース・PolicySet ポリシーをグルーピングするためのリソースです。この例では、2つのポリシーをグルーピングしています。

ACMで用いるカスタムリソース・PlacementRule ポリシーの適用対象を決めるためのリソースです。この例では、managed-by-kyverno=“yes”というラベルを持つManaged Clusterが対象になります。

ACMで用いるカスタムリソース・PlacementBinding PolicyもしくはPolicySetとPlacementRuleを紐づけるためのリソース。この例では、指定したPlacementRuleとPolicyを紐づけています。 Policy PolicySet

Governance on ACM (再掲) PolicyとKyvernoを連携させることが可能です。 Redhat ACM for k8s PlacementBinding PlacementRule Policy / PolicySet Dev Cluster Policy app1 Policy app1 Kyverno Kyverno Kyverno ※ Hub ClusterとManaged Clusterの双方に Kyvernoをインストールする必要があります。 Hub Cluster Stg Cluster Prd Cluster

Governance on ACM ACMの機能を用いて、配下のクラスターにアプリケーションをデプロイ可能です。 Redhat ACM for k8s PlacementBinding PlacementRule Policy / PolicySet Dev Cluster Stg Cluster Prd Cluster Policy app1 Policy app1 Kyverno Kyverno Kyverno Hub Cluster Subscription Channel Git Helm

Governance on ACM ACM管理下のCluster間で同一のツールを持たせたい場合、OpenShift GitOpsとの連携が便利です。 Redhat ACM for k8s PlacementBinding PlacementRule Policy / PolicySet Dev Cluster Policy app1 Policy app1 Stg Cluster Prd Cluster Hub Cluster Kyverno Kyverno Kyverno OpenShift GitOps ClusterSet

OpenShift GitOpsによるKyvernoのデプロイ ArgoCDのApplicationSetリソースを用いることで、 Cluster Decision Resource Generator という機能によって、どのClusterにデプロイするかを選定したうえで、 template以下に記述したApplicationリソースをクラスター毎に払い出すということをしています。途中に出てくる {{name}} や {{server}} には、今回対象となるClusterの名前や、API URLが入ってきます。

ACM上でのリソースの確認

ACMにおけるマルチクラスターへのKyvernoポリシー適用手順 (前提条件) Hub Cluster及びManaged ClusterにKyvernoをインストール (ステップ) 1. 各クラスターにラベルを付与 2. Policy作成 (及びPolicySet作成) 3. PlacementRule作成 4. PlacementBinding作成

ACM上でのポリシーの確認適用したポリシーは、ACM上から確認することができます。

セッションのまとめ • Kyvernoでは、Kubernetesのマニフェストベースでポリシーを記述することができます。 • Kyvernoでは、ほかのポリシーエンジンにはない機能が実装されています。 • ポリシーには、以下の4種類の”アクション”が用意されています。 – Validate Resources – Mutate Resources – Generate Resources – Verify Images • マルチクラスターに対してポリシーを適用及び管理する際は、 Red Hat ACM for Kubernetesを用いることで、運用コストを下げることができます。 • Red Hat ACM for KubernetesとKyvernoを活用することで、マルチクラスターに対し、柔軟にポリシーを定義し適用することが可能です。

KyvernoとRed Hat ACMを用いたマルチクラスターの一元的なポリシー制御

KyvernoとRed Hat ACMを用いたマルチクラスターの一元的なポリシー制御

More Decks by ry

Other Decks in Technology

Featured

Transcript