Kubernetesにおけるベストプラクティスを取り巻く流れ
Kubernetesが成熟してきたことと、DevとOpsの責任範囲分離などの背景があり
アプリケーションエンジニアもKubernetesを扱う場面が増えてきたという話をちらほら耳にする。
ここで、Kubernetesわかるマンにとっては朝飯前であったYAMLをこねこねする作業を、誰でも行うような動きが加速しており、今後もこの状態が続いていくと想像できる。
特にKubernetesのセキュリティ観点に目を向けると、CNCFが新たにKubernetesのセキュリティに特化した新試験を近日公開することもあり、Kubernetesを用いた開発をより均質化・安定化させていく動きがみられる。
https://training.linuxfoundation.org/ja/certification/certified-kubernetes-security-specialist/
ここでは、手元のKubernetesクラスタがベストプラクティスに沿っているかを手軽に確認できるツールである、Polarisを紹介する。
Polarisの機能概要
FairwindsのPolarisは、クラスターの円滑な運用を維持する。様々なチェックを実行して、Kubernetesポッドとコントローラがベストプラクティスに沿っていることを確認し、将来的な問題を回避することに役立てられる。Polarisは、下記の3つのモードで実行できる。
ここではダッシュボードについて取り上げ、まとめにてValidating Webhook, CLI toolについて触れる。
- ダッシュボード
- Validating Webhook
- CLI tool
Dashboard Quick Start
クラスタの用意
ここは環境に合わせて用意ください。ここではkindを用いた例で説明します。
kind create cluster
porarisをダッシュボードとしてデプロイし、ダッシュボード Serviceをホストにポートフォワード
kubectl apply -f https://github.com/FairwindsOps/polaris/releases/latest/download/dashboard.yaml
kubectl port-forward --namespace polaris svc/polaris-dashboard 8080:80
以上で、polarisが動作している状態になります。
※port-forwardコマンドのタイミングが早すぎると、Pod起動前にポートフォワードが試行されエラーが返ります。
動作確認
localhost:8080にブラウザでアクセスすると、polarisのダッシュボードを確認できる
5つのカテゴリごとにテスト結果のパーセンテージが表示される
- Health Check:
- Images
- Networking
- Resources
- Security
HealthCheck
HelathCheckのテストはシンプルで、下記のページに示されている通り**ReadinessProbeとLivenessProbeが定義されていなければ失敗する。**デフォルトはWarningとしている
Images
Imagesのテストも下記に示されている２点のテストを行っている。
イメージのタグが指定されていないかlatestの場合に失敗する。デフォルトはdanger
**イメージのpullPolicyがAlwaysじゃない場合に失敗する。**デフォルトはignore
Networking
hostNetworkやhostPortが設定されている場合に失敗する。デフォルトはWarning
Resources
**Resource Requests/LimitsがCPU, Memoryそれぞれに定義されていなければ失敗する。**デフォルトはdanger
Security
下記の通り、特にホストマシンに影響を与える部分がdangerとなっている。
Namespace内のKind別にテスト結果を確認できる
polaris以外に特に何も動かしていないクラスタのため、Kindにデフォルトで入っているlocal-path-storageとkube-system, polaris用のnamespaceが表示されている。
kube-system namespace上のkindnetというDaemonsetに焦点を当ててみる。
Daemonsetから生成されるkindnet-cni コンテナに対して、危険なCapabilityを持っているというdangerアラートが出ている。CNIなのでこれは仕方ないが。
まとめ
Polarisを使うことで、Kubernetesクラスタがベストプラクティスに沿っているかを手軽に検証することができる。
今回紹介していないが、KubernetesのAdmission ControllerにValidating Webhookとして組み込むことで、dangerと判定されるマニフェストが適用される場合に、それを自動的に拒否する仕組みにも対応している。
また、CLIとしても動作するためCI/CDのパイプラインに組み込み、dangerやwarningなどの閾値を設定することでCI/CDパイプラインを停止させる仕組みにも対応している。