Presented by @makocchi 1 Open Policy Agent を使って ベスト・プラクティスをコード化しよう Kubernetes Fest Tokyo 2020

Presented by @makocchi Kubernetes Fest Tokyo 2020 2 Makoto Hasegawa Working at // AI Division, CyberAgent, Inc Currently // Develop and maintain private OpenStack cloud. Develop and maintain Kubernetes as a Service platform. CKA (Certified Kubernetes Administrator) CKA-1700-0150-0100 CKAD (Certified Kubernetes Application Developper) CKAD-1800-0005-0100 Job Title // Technical Lead Infrastructure Engineer WHO am I Twitter // @makocchi Facebook // makocchi0923 Hobby // Playing bass

Presented by @makocchi Kubernetes Fest Tokyo 2020 やった！ いっぱい撮るぞ 3 今日の発表資料は後ほど公開します 写真は撮る必要ありませんが、 撮りたい人は好きなだけ撮って下さい だってオンラインだもの

Presented by @makocchi Kubernetes Fest Tokyo 2020 4 AGENDA コード化は重要だ Knowledge as Code Kubernetes のマニフェストに関する ベスト・プラクティスをコード化しよう Open Policy Agent を Kubernetes に組み込む Rego を読んでみよう！ 今後の取り組みについて 本日のまとめ

Presented by @makocchi Kubernetes Fest Tokyo 2020 5 みなさん コード化していますか？

Presented by @makocchi Kubernetes Fest Tokyo 2020 6 コード化と言えばやっぱりこれですよね Infrastructure as Code IaC

Kubernetes Fest Tokyo 2020 Presented by @makocchi 7 コード化は重要だ IaCのメリットはいろいろありますよね　例えば・・・ コストの削減 自動化による作業工数の削減 スピードの向上 自動化・効率化による作業の高速化 リスクの低減 誰が作業しても同じ品質になる (冪等性の担保、人為的ミスの削減、属人化の解消) 人類はこうして IaC を活用することで進化してきたのです！(インフラについては)

Kubernetes Fest Tokyo 2020 Presented by @makocchi 8 コード化は重要だ IaC が普及することによって、当たり前のように IaC を使えるようになった今 IaC によるメリットをいろいろと享受してきた我々ですが・・・ そろそろ我々は次のステップへと進むことを検討しては良いのではないでしょうか そう、インフラをコード化することは出来たのだから・・・ これからの時代は・・・

Presented by @makocchi Kubernetes Fest Tokyo 2020 9 知識

Presented by @makocchi Kubernetes Fest Tokyo 2020 10 知識 ベスト・プラクティス 先人の知恵 秘伝のタレ 〇〇さんの頭の中にしかないもの チーム内の暗黙のルール

Presented by @makocchi Kubernetes Fest Tokyo 2020 11 知識 ベスト・プラクティス 先人の知恵 秘伝のタレ 〇〇さんの頭の中にしかないもの チーム内の暗黙のルール コード化したい！よね？

Presented by @makocchi Kubernetes Fest Tokyo 2020 12 Knowledge as Code KaC

Presented by @makocchi Kubernetes Fest Tokyo 2020 13 またの名を

Presented by @makocchi Kubernetes Fest Tokyo 2020 14 Best Practice as Code BPaC

Kubernetes Fest Tokyo 2020 Presented by @makocchi 15 Knowledge as Code (a.k.a Best Practice as Code) いわゆる「ベスト・プラクティス」をコード化することでみんなが様々なメリットを受けれる ようにしようという考え方 クラウドネイティブなチーム作りを目指すには欠かせない要素ではないでしょうか クラウドネイティブなチーム(持論) is 　スケーラブルで回復性のあるチーム 　　チームにおいて人数を増やせばそれだけチームのパフォーマンスが上がる 　　誰が作業してもクオリティが変わらない 　メンバー同士はいい意味で疎結合 　　各自が自らやるべきことを探し、自立できている

Kubernetes Fest Tokyo 2020 Presented by @makocchi 16 Knowledge as Code (a.k.a Best Practice as Code) IaC もそうですが、大切なのは継続して実践していくこと そしてそれは口で言う程簡単ではないです まずは出来るところから始めていくことが大切なんじゃないでしょうか みなさんの周りにもコード化できる Knowledgs がきっといろいろあるはずです！

Presented by @makocchi Kubernetes Fest Tokyo 2020 17 身近なものから KaC していきましょう！

Presented by @makocchi Kubernetes Fest Tokyo 2020 18 身近なものといえば？

Presented by @makocchi Kubernetes Fest Tokyo 2020 19 そう Kubernetes 今や一家に一台の時代と言っても過言ではない (多分)

Presented by @makocchi Kubernetes Fest Tokyo 2020 20 Kubernetes のマニフェストが 手元にあるはず！

Presented by @makocchi Kubernetes Fest Tokyo 2020 21 Kubernetes のマニフェストに関するベスト・プラクティスを コード化しよう

Kubernetes Fest Tokyo 2020 Presented by @makocchi 22 Kubernetes のマニフェストに関するベスト・プラクティスとは Production Ready なリソースの状態にしよう readinessProbe がきちんと設定されている preStop がきちんと設定されている requests がきちんと設定されている affinity がきちんと設定されている ... ※人やチームによって様々なプラクティスが存在すると思います あくまで一例として参考にしてください セキュリティに配慮されたリソースの状態にしよう コンテナの image タグに latest を使わない allowPrivilegeEscalation が false になっている 不用意に capabilities を与えない runAsUser を root にしない ... 例えばこんな感じでしょうか

Kubernetes Fest Tokyo 2020 Presented by @makocchi 23 Kubernetes のマニフェストに関するベスト・プラクティスとは Production Ready なリソースの状態にしよう readienessProbe がきちんと設定されている preStop がきちんと設定されている requests がきちんと設定されている affinity がきちんと設定されている ... ※人やチームによって様々なプラクティスが存在すると思います あくまで一例として参考にしてください セキュリティに配慮されたリソースの状態にしよう コンテナの image タグに latest を使わない allowPrivilegeEscalation が false になっている 不用意に capabilities を与えない runAsUser を root にしない ... 例えばこんな感じでしょうか ルールを コード化したい ルールを コード化したい

Kubernetes Fest Tokyo 2020 Presented by @makocchi 24 どうやってルールをコード化するのか Bash や Python 等のスクリプトでルールをチェックしてもいいのだが・・・ さすがにそれはツライ そこで登場するのが Open Policy Agent マニフェストに関するルールを記述(Rego言語:後述)し、チェックすることができる やっと登場！ 待たせたな！ https://github.com/open-policy-agent/opa

Kubernetes Fest Tokyo 2020 Presented by @makocchi 25 Open Policy Agent Open Policy Agent(OPA) は OSS の汎用ポリシーエンジン CNCF のプロジェクトで現在は「Incubating」 API に対して "Data(Document)" を送る(query)と、内部の Policy(Rule) にしたがって Data を評価し、結果を返す Policy は Rego 言語で記述する テストに出るぞ！ https://github.com/open-policy-agent/opa https://kccncosschn19eng.sched.com/event/NrrB

Kubernetes Fest Tokyo 2020 Presented by @makocchi 26 Rego Rego は Datalog(Prologのサブセット) を元に作られた宣言型言語 JSON 等の構造化されたドキュメントを扱えるように Datalog を拡張している すごく簡単な例) こんな感じ Lego の方じゃないぞ 間違えないようにな！ https://www.openpolicyagent.org/docs/latest/policy-language/ 呼んだ？ # ม਺ͷఆٛ event := "kubefest" # ৚݅൑ఆ (͜Ε͸ false ͕ฦΔ) event == "kubecon" https://en.wikipedia.org/wiki/Datalog

Kubernetes Fest Tokyo 2020 Presented by @makocchi 27 コード化はできる、そう Rego を使えばね Production Ready なリソースの状態にしよう readienessProbe がきちんと設定されている preStop がきちんと設定されている requests がきちんと設定されている affinity がきちんと設定されている ... ※人やチームによって様々なプラクティスが存在すると思います あくまで一例として参考にしてください セキュリティに配慮されたリソースの状態にしよう コンテナの image タグに latest を使わない allowPrivilegeEscalation が false になっている 不用意に capabilities を与えない runAsUser を root にしない ... 例えばこんな感じでしょうか (再掲)

Kubernetes Fest Tokyo 2020 Presented by @makocchi 28 コード化はできる、そう Rego を使えばね Production Ready なリソースの状態にしよう readienessProbe がきちんと設定されている preStop がきちんと設定されている requests がきちんと設定されている affinity がきちんと設定されている ... ※人やチームによって様々なプラクティスが存在すると思います あくまで一例として参考にしてください セキュリティに配慮されたリソースの状態にしよう コンテナの image タグに latest を使わない allowPrivilegeEscalation が false になっている 不用意に capabilities を与えない runAsUser を root にしない ... Rego Rego Rego Rego Rego Rego Rego Rego 例えばこんな感じでしょうか (再掲) kubernetes の ルールもおまかせあれ

Presented by @makocchi Kubernetes Fest Tokyo 2020 29 Rego でルールを記述し、 Open Policy Agent でルールを判定するのは分かった

Presented by @makocchi Kubernetes Fest Tokyo 2020 30 では Kubernetes と Open Policy Agent は どうやって組み合わせて使えばいいのか？

Kubernetes Fest Tokyo 2020 Presented by @makocchi 31 Open Policy Agent を Kubernetes に組み込む 先程の図を思い出してみましょう

Kubernetes Fest Tokyo 2020 Presented by @makocchi 32 Open Policy Agent を Kubernetes に組み込む これを Kubernetes に組み込むと

Kubernetes Fest Tokyo 2020 Presented by @makocchi 33 Open Policy Agent を Kubernetes に組み込む https://www.openpolicyagent.org/docs/edge/kubernetes-introduction/

Kubernetes Fest Tokyo 2020 Presented by @makocchi 34 Open Policy Agent を Kubernetes に組み込む https://www.openpolicyagent.org/docs/edge/kubernetes-introduction/

Kubernetes Fest Tokyo 2020 Presented by @makocchi 35 Open Policy Agent を Kubernetes に組み込む Kubernetes の Admission Controller の機能の内、 "ValidatingAdmissionWebhook" を有効にする あとは "ValidatingWebhookConfiguration" を定義し、Open Policy Agent と連携させる Open Policy Agent は Deployment で作成しておき、webhook 用に証明書の作成と service の作成をしておく 詳しい手順は公式の Document で kind: ValidatingWebhookConfiguration apiVersion: admissionregistration.k8s.io/v1beta1 metadata: name: opa-validating-webhook webhooks: - name: validating-webhook.openpolicyagent.org namespaceSelector: matchExpressions: - key: openpolicyagent.org/webhook operator: NotIn values: - ignore rules: - operations: ["CREATE", "UPDATE"] apiGroups: ["*"] apiVersions: ["*"] resources: ["*"] clientConfig: caBundle: .... service: namespace: opa name: opa https://www.openpolicyagent.org/docs/latest/kubernetes-tutorial/

Kubernetes Fest Tokyo 2020 Presented by @makocchi 36 Open Policy Agent を Kubernetes に組み込む Rego は ConfigMap に記述することで Open Policy Agent が動 的に読んでくれる デフォルトでは "opa" namespace 内の ConfigMap を探してく れるが、他の namespace でも openpolicyagent.org/ policy=rego の label を付ければ参照してくれる 正常に取り込まれれば openpolicyagent.org/policy-status: '{"status":"ok"}' の annotation が付与される kind: ConfigMap apiVersion: v1 metadata: name: opa-default-system-main namespace: opa data: main: | package system import data.kubernetes.admission main = { "apiVersion": "admission.k8s.io/v1beta1", "kind": "AdmissionReview", "response": response, } default response = {"allowed": true} ... ...

Kubernetes Fest Tokyo 2020 Presented by @makocchi 37 というわけで ValidatingWebhookConfiguration として Open Policy Agent を動かす方法を 紹介したのですが、今ではこの方式よりも後述する Gatekeeper を使う方式をオススメします 先程紹介した公式の Document も最近は更新されていないようだし・・・ でも手軽に試すことはできるので、ちょっと試してみたい場合はいいかもしれません Open Policy Agent はそもそも Kubernetes だけではなくて様々なものに対応しています (Kubernetes 専用ってわけじゃない) Gatekeeper は Open Policy Agent を Kubernetes で動かす為に作られているので、 こちらのほうが親和性が高いです Open Policy Agent を Kubernetes に組み込む https://www.openpolicyagent.org/docs/latest/kubernetes-tutorial/ 古い

Kubernetes Fest Tokyo 2020 Presented by @makocchi 38 Gatekeeper は Open Policy Agent に比べて、より拡張性に優れていて policy を template 化して管 理することができます policy の template 化が出来るということは、template 使用時に与える parameter を変えることで policy をより柔軟に、そして簡単に定義して使うことができるようになるということです 例えば、「Deployment に対して特定の Label を付けなければならない」というルールを template 化(constraint templates)し、特定の Label をパラメーターとして渡して使う(constraints)ことがで きます(再利用性が高い) Gatekeeper を Kubernetes に組み込む ConstraintTemplate NewRuleA NewRuleB パラメーター として "foo" を渡す パラメーター として "bar" を渡す "foo" の Label が必須だよ！ "bar" の Label が必須だよ！ https://github.com/open-policy-agent/gatekeeper

Kubernetes Fest Tokyo 2020 Presented by @makocchi 39 Gatekeeper の魅力はまだまだ終わらない！ Gatekeeper であれば、現在 deploy されているリソースを参照することができます つまり、現在 deploy されているリソースと適用しようとしているリソースの比較も可能です (Rego 内で "data.inventory" で参照可能) 例えば新規作成しようとしている Deployment の spec.selector.matchLabels の値が既存のクラス ター内で可動している Deployment と重複していないか、等をチェックすることができます (Rego 内で "data.inventory" と "input.review" を比較する) Gatekeeper を Kubernetes に組み込む

Kubernetes Fest Tokyo 2020 Presented by @makocchi 40 Gatekeeper は現在も活発に開発が進んでいます 現在の所 validating webhook しか対応していませんが、公式 Document(README.md) によれば mutating webhook は将来対応予定なので、今後に期待ですね Gatekeeper is a validating (mutating TBA) webhook that enforces CRD-based policies executed by Open Policy Agent Gatekeeper を Kubernetes に組み込む https://github.com/open-policy-agent/gatekeeper/blob/master/README.md

Presented by @makocchi Kubernetes Fest Tokyo 2020 41 Rego を読んでみよう！

Kubernetes Fest Tokyo 2020 Presented by @makocchi 42 Rego を読んでみよう！ package k8srequiredlabels violation[{"msg": msg, "details": {"missing_labels": missing}}] { provided := {label | input.review.object.metadata.labels[label]} required := {label | label := input.parameters.labels[_]} missing := required - provided count(missing) > 0 msg := sprintf("you must provide labels: %v", [missing]) } https://github.com/open-policy-agent/gatekeeper 本日のお題はこちら！ Gatekeeper の README から持ってきました

Kubernetes Fest Tokyo 2020 Presented by @makocchi 43 Rego を読んでみよう！ package k8srequiredlabels violation[{"msg": msg, "details": {"missing_labels": missing}}] { provided := {label | input.review.object.metadata.labels[label]} required := {label | label := input.parameters.labels[_]} missing := required - provided count(missing) > 0 msg := sprintf("you must provide labels: %v", [missing]) } ここは package 名の定義 ルールの定義毎に好きな名前を入れればいいと思います (同じ package 内では変数を使い回すことが可能)

Kubernetes Fest Tokyo 2020 Presented by @makocchi 44 Rego を読んでみよう！ package k8srequiredlabels violation[{"msg": msg, "details": {"missing_labels": missing}}] { provided := {label | input.review.object.metadata.labels[label]} required := {label | label := input.parameters.labels[_]} missing := required - provided count(missing) > 0 msg := sprintf("you must provide labels: %v", [missing]) } 実際のルールの定義部分 []内はそのルールの評価後に返す構造体

Kubernetes Fest Tokyo 2020 Presented by @makocchi 45 Rego を読んでみよう！ package k8srequiredlabels violation[{"msg": msg, "details": {"missing_labels": missing}}] { provided := {label | input.review.object.metadata.labels[label]} required := {label | label := input.parameters.labels[_]} missing := required - provided count(missing) > 0 msg := sprintf("you must provide labels: %v", [missing]) } 実際のルールの定義部分 []内はそのルールの評価後に返す構造体 { "violation": [ { "details": { "missing_labels": "" }, "msg": "" } ] }

Kubernetes Fest Tokyo 2020 Presented by @makocchi 46 Rego を読んでみよう！ package k8srequiredlabels violation[{"msg": msg, "details": {"missing_labels": missing}}] { provided := {label | input.review.object.metadata.labels[label]} required := {label | label := input.parameters.labels[_]} missing := required - provided count(missing) > 0 msg := sprintf("you must provide labels: %v", [missing]) } "provided" に label という局所変数を入れている label は "input.review.object.metadata.labels[]" 内で定義されているので、実際の値は "input.review.object" すなわち作成、または更新するリソース(Deployment とか) の metadata.labels の値になる というわけでリソースの label の値になる (array)

Kubernetes Fest Tokyo 2020 Presented by @makocchi 47 Rego を読んでみよう！ package k8srequiredlabels violation[{"msg": msg, "details": {"missing_labels": missing}}] { provided := {label | input.review.object.metadata.labels[label]} required := {label | label := input.parameters.labels[_]} missing := required - provided count(missing) > 0 msg := sprintf("you must provide labels: %v", [missing]) } "required" に label という局所変数を入れている label は "input.parameters.labels[_]" から取得されているので、パラメーターとして渡された値となる (array)

Kubernetes Fest Tokyo 2020 Presented by @makocchi 48 Rego を読んでみよう！ package k8srequiredlabels violation[{"msg": msg, "details": {"missing_labels": missing}}] { provided := {label | input.review.object.metadata.labels[label]} required := {label | label := input.parameters.labels[_]} missing := required - provided count(missing) > 0 msg := sprintf("you must provide labels: %v", [missing]) } 先程までに定義してきた "required" と "provieded" を比較し、"missing" という変数に格納

Kubernetes Fest Tokyo 2020 Presented by @makocchi 49 Rego を読んでみよう！ package k8srequiredlabels violation[{"msg": msg, "details": {"missing_labels": missing}}] { provided := {label | input.review.object.metadata.labels[label]} required := {label | label := input.parameters.labels[_]} missing := required - provided count(missing) > 0 msg := sprintf("you must provide labels: %v", [missing]) } 先程までに定義してきた "required" と "provieded" を比較し、"missing" という変数に格納 required 内の label から provided の label を引いている 2つを比較し、provided 内に無い required の要素の数を返している s3 := s1 - s2 s3 is the difference between s1 and s2, i.e., the elements in s1 that are not in s2

Kubernetes Fest Tokyo 2020 Presented by @makocchi 50 Rego を読んでみよう！ package k8srequiredlabels violation[{"msg": msg, "details": {"missing_labels": missing}}] { provided := {label | input.review.object.metadata.labels[label]} required := {label | label := input.parameters.labels[_]} missing := required - provided count(missing) > 0 msg := sprintf("you must provide labels: %v", [missing]) } ͭ·Γ͜͏͍͏͜ͱʁ ["A", "B"] - ["A", "B", "C"] = [] ["A", "B"] - ["B", "C"] = ["A"] 先程までに定義してきた "required" と "provieded" を比較し、"missing" という変数に格納 required 内の label から provided の label を引いている 2つを比較し、provided 内に無い required の要素の数を返している 言い方を変えると required の中で、provided 内と一致しなかった要素を返す

Kubernetes Fest Tokyo 2020 Presented by @makocchi 51 Rego を読んでみよう！ package k8srequiredlabels violation[{"msg": msg, "details": {"missing_labels": missing}}] { provided := {label | input.review.object.metadata.labels[label]} required := {label | label := input.parameters.labels[_]} missing := required - provided count(missing) > 0 msg := sprintf("you must provide labels: %v", [missing]) } ここはそのままですね missing の要素数が 0 以上であれば "true" が返ります "false" になった場合はここで処理が終了

Kubernetes Fest Tokyo 2020 Presented by @makocchi 52 Rego を読んでみよう！ package k8srequiredlabels violation[{"msg": msg, "details": {"missing_labels": missing}}] { provided := {label | input.review.object.metadata.labels[label]} required := {label | label := input.parameters.labels[_]} missing := required - provided count(missing) > 0 msg := sprintf("you must provide labels: %v", [missing]) } 最後に msg を整形して終わりです

Kubernetes Fest Tokyo 2020 Presented by @makocchi 53 Rego を読んでみよう！ package k8srequiredlabels violation[{"msg": msg, "details": {"missing_labels": missing}}] { provided := {label | input.review.object.metadata.labels[label]} required := {label | label := input.parameters.labels[_]} missing := required - provided count(missing) > 0 msg := sprintf("you must provide labels: %v", [missing]) } 最後に msg を整形して終わりです { "violation": [ { "details": { "missing_labels": "foo" }, "msg": "you must provide labels: foo" } ] }

Kubernetes Fest Tokyo 2020 Presented by @makocchi 54 Rego を読んでみよう！ - Appendix - Rego について理解を深めるのに役に立つサイト Policy Language https://www.openpolicyagent.org/docs/latest/policy-language/ Policy Reference https://www.openpolicyagent.org/docs/latest/policy-reference/ instrumenta社の sample kubernetes policy (Conftest 用) https://github.com/instrumenta/policies/tree/master/kubernetes

Presented by @makocchi Kubernetes Fest Tokyo 2020 55 Rego を読めるようになったなら、 次は是非書いてみて下さい！

Presented by @makocchi Kubernetes Fest Tokyo 2020 56 Rego を読めるようになったなら、 次は是非書いてみて下さい！ 実際に Rego の動作を確認することができる https://play.openpolicyagent.org/ もあるよ！

Kubernetes Fest Tokyo 2020 Presented by @makocchi 57 Gatekeeper/Open Policy Agent は ValidatingWebhookConfiguration によるチェックなので 実際にクラスターに設定変更を行う時に判断されます しかし、場合によってはそもそもクラスターに対して設定変更する前に Rego でルールが守られているか確認しておきたい(CIに組み込みたい)場合もあるでしょう その際には Conftest を使うのがオススメです Rego を使いこなせればこんなこともできる！ 便利だなぁ

Kubernetes Fest Tokyo 2020 Presented by @makocchi 58 Conftest は Rego で記述されたルールを元にマニフェストをチェック(テスト)することができる コマンドラインツールです Rego を使いこなせればこんなこともできる！ 要チェックや https://github.com/open-policy-agent/conftest $ conftest test deployment.yaml FAIL - deployment.yaml - Containers must not run as root FAIL - deployment.yaml - Deployments are not allowed 2 tests, 0 passed, 0 warnings, 2 failures

Kubernetes Fest Tokyo 2020 Presented by @makocchi 59 Conftest は Rego で記述されたルールを元にマニフェストをチェック(テスト)することができる コマンドラインツールです Rego を使いこなせればこんなこともできる！ 要チェックや $ conftest test deployment.yaml FAIL - deployment.yaml - Containers must not run as root FAIL - deployment.yaml - Deployments are not allowed 2 tests, 0 passed, 0 warnings, 2 failures package main deny[msg] { input.kind = "Deployment" not input.spec.template.spec.securityContext.runAsNonRoot = true msg = "Containers must not run as root" } deny[msg] { input.kind = "Deployment" not input.spec.selector.matchLabels.app msg = "Containers must provide app label for pod selectors" } https://github.com/open-policy-agent/conftest

Kubernetes Fest Tokyo 2020 Presented by @makocchi 60 Conftest は GitOps と相性がとてもいいです PR 時に Conftest によるチェックを行っていれ ば、不正な manifest が commit されることを 防ぐことができます GitHub Actions で簡単に Conftest できるような action を公開してますので、よかったら試してみ て下さい Rego を使いこなせればこんなこともできる！ https://github.com/marketplace/actions/kubernetes-yaml-validation-by-conftest

Kubernetes Fest Tokyo 2020 Presented by @makocchi 61 Kubeval マニフェストが kubernetes の schema に準拠しているか確認することができます 詳細は以前に発表した資料を見て下さい 「Kubeval を使って manifest を validation しよう」@Kubernetes Meetup Tokyo #29 GitHub Action も作ってあります https://github.com/marketplace/actions/kubernetes-yaml-validation-by-kubeval Pluto マニフェストが deprecated な API version を使ってないか確認することができます [おまけ] Regoじゃないけどチェック方法はいろいろあるよ！

Presented by @makocchi Kubernetes Fest Tokyo 2020 62 今後の 野望 取り組みについて

Kubernetes Fest Tokyo 2020 Presented by @makocchi 63 弊社では AKE というプライベートクラウドの KaaS を持っていて、Addon 機能によって 様々な機能をクラスターに対して deploy できるようになっています 今後はこの Addon で Gatekeeper を実装し、利用者が使いたい時に すぐに Gatekeeper が使えるようにする予定です また、それと同時にマニフェストに対するベスト・プラクティスを収集、Rego 化して公開していきたい (まずはチーム内から始めて、社内、社外へと広げていけたらいいな) 今後の取り組みについて AKE をよろしくね

Kubernetes Fest Tokyo 2020 Presented by @makocchi 64 Rego で Knowledge をコード化したい！ Rego に詳しくなりたい！ そんな人達で勉強会とかできたらいいなと考えています (というか詳しい人にいろいろ教えてもらいたい) なんなら Open Policy Agent meetup とか Rego meetup とか立ち上げてもいいんじゃないか？ って思ったりしてますので、興味ある方是非一緒に考えましょう！ (需要あるかな？) 今後の野望について

Presented by @makocchi Kubernetes Fest Tokyo 2020 65 本日のまとめ

Kubernetes Fest Tokyo 2020 Presented by @makocchi 66 本日のまとめ ベスト・プラクティスをコード化していこう KaC (BPaC) 身近なところから始めてみよう (今日のお題は Kubernetes のマニフェストでした) Rego を使えばマニフェストに関する KaC が実現できる Rego にすることで Gatekeeper や Conftest を使ってテストができる Gatekeeper/Conftest/Rego に関する勉強会したい ちなみに表紙のライオンには何の意味もありません

Presented by @makocchi 67 Open Policy Agent を使って ベスト・プラクティスをコード化しよう Kubernetes Fest Tokyo 2020 おしまい