Google Cloudとコンテナの継続的なセキュリティ
本文の内容は、2020年9月25日にDavid Lorite Solanasが投稿したブログ(https://sysdig.com/blog/monitor-istio/)を元に日本語に翻訳・再構成した内容となっております。
この記事では、Kubernetesクラスタ上で Istio をデプロイして監視します。Istioは、高度なルーティング、バランシング、セキュリティ、高可用性機能に加えて、サービスのPrometheusスタイルのメトリクスをアウトオブボックスで提供するサービスメッシュプラットフォームです。
Istioはマイクロサービスを相互接続するためのプラットフォームです。サービスコードを変更することなく、ロードバランシング、サービス間認証、モニタリングなどの高度なネットワーク機能を提供します。
Kubernetesのコンテキストでは、Istioはサービスを提供するすべてのポッドの内部にサイドカーコンテナとしてEnvoyプロキシを配置します。
これらのプロキシはすべての接続を仲介し、その位置からincoming/outgoingトラフィックをルーティングし、さまざまなセキュリティとネットワークポリシーを実施します。
このダイナミックなプロキシのグループは、ルーティング、セキュリティ、ライブルールセットの更新などをオーケ ートレートするポッドの別のセットであるIstioの「コントロールプレーン」によって管理されています。
Istioプロジェクトのドキュメントに各サブシステムコンポーネントの詳細な説明があります。
コンテナは信じられないほど軽量で高速なので、その密度が仮想マシンよりも一桁以上高いのは当然のことです。古典的モノリシックなコンポーネントの相互接続図は、独自の内部セキュリティルール、ラベリングベースのルート、DNSやサービスディレクトリなどを備えた、高度に動的でフォールトトレラントなN-to-N通信へと急速に変化しています。これが有名なマイクロサービスメッシュです。
つまり、ソフトウェア自律ユニット（コンテナ）がよりシンプルで多数になる一方で、分散したソフトウェアの動作の相互接続やトラブルシューティングは実際には難しくなってきているということです。
そしてもちろん、このような複雑さでコンテナに負担をかけるのではなく、薄くてプラットフォームに依存しない状態を維持してほしいと考えています。
Kubernetesはすでにサービス自体とサーバーポッドを分離する基本的な抽象化レイヤーを提供しています。いくつかのソフトウェアプロジェクトが、可視性、トレーサビリティ、その他の高度なポッドネットワーキング機能を提供して、この複雑さを手なずけようと努力しています。Linkerdを監視する方法はすでにカバーしましたが、Istioについて話しましょう。
インテリジェントなルーティングとロードバランシング：静的なサービスインターフェースを異なるバックエンドバージョンにマッピングするためのポリシーを定義し、A/Bテスト、カナリアデプロイ、段階的なマイグレーションなどを可能にします。Istioでは、セッショントークンやユーザーエージェント文字列のようなHTTP層のメタデータに基づいてルーティングルールを定義することもできます。
ネットワークの回復力とヘルスチェック：タイムアウト、リトライバジェット、ヘルスチェック、サーキットブレーカーを設定することで、サービスメッシュから不健全なポッドを素早く取り除くことができます。
ポリシーのエンフォースメント：ピアTLS認証、事前条件チェック（ホワイトリストや同様のACL）、サービスの乱用や消費者のリソース不足を避けるためのクォータ管理。
テレメトリ、トレーサビリティ、トラブルシューティング：テレメトリは、PrometheusスタイルのネットワークとL7プロトコルのメトリクスを提供するサービスポッドに自動的に注入されます。Istioはまた、マイクロサービス・メッシュのフローと連鎖接続を動的にトレースします。
Istio Envoyプロキシを介してサービス・トラフィックをトンネリングする主要なインフラストラクチャー強化の1つは、（サービス・プロキシごとに報告されるため）きめ細かく、高レベルのアプリケーション情報を提供するメトリクスを自動的に収集することです。
これらの個別のメトリクスはプロメテウスによって収集されますが、プロメテウスのエンドポイントにアクセスすることもできます。
ミキサーは非推奨なので、メトリクスはポッドから直接来ています。
Istioプロジェクトは、最も関連性の高いメトリクスをスクレイプして分析するためにPrometheusサーバを設定するための例とドキュメントも提供しています。
kubectl apply -f install/kubernetes/addons/prometheus.yaml
ポッドの準備が整うまで待ち、Prometheusサーバのポートをローカルマシンに転送します。
kubectl -n istio-system port-forward $(kubectl -n istio-system get pod -l app=prometheus -o jsonpath='{.items[0].metadata.name}') 9090:9090 &
Web ブラウザで http://localhost:9090/ を開いて、Prometheus サーバーの UI にアクセスできるようになりました。
また、IstioのリポジトリにはGrafanaのデプロイメントがあらかじめ設定されており、テストする準備ができています：
$ kubectl create -f install/kubernetes/addons/grafana.yaml
再度、ポッドとサービスが起動するのを待ち、Grafanaのサービスポートをリダイレクトします。
kubectl -n istio-system port-forward $(kubectl -n istio-system get pod -l app=grafana -o jsonpath='{.items[0].metadata.name}') 3000:3000 &
事前に設定されたダッシュボードには http://localhost:3000/dashboard/db/istio-dashboard からアクセスできます。
サービスとアプリケーションの動作の監視を始めましょう。
サービスとサービスバージョンによってセグメント化された、Istio Prometheusテレメトリと Sysdig out-of-the-box メトリクスコレクションの両方から得られる、通常監視したいいくつかのメトリクスです：
PromCat.ioを使うのが一番早くダッシュボードを作成する方法で、コマンドを1回実行するだけで、すべてのメトリクスを一度にダッシュボードを取得することができます。
Prometheusのメトリクス形式を使用したIstioのコアサービスは、ご存知のようにSysdigがPrometheusのエンドポイントを自動的に検出してスクレイプするので非常に便利です。
Sysdigエージェント設定ファイル(dragent.yaml)を編集して、どのポッドとポートをスクレイプするかを設定してみましょう。
prometheus:
enabled: true
...
- include:
process.name: envoy
conf:
port: 15090
path: "/stats/prometheus"
Prometheusが有効になっていることを確認し、インクルードフィルタを記述します。
この設定であれば、追加設定なしですべてのenvoyコンテナをスクレイプして、envoyが提供するすべてのメトリクスを取得することができます。これはいくつかのポッドをスクレイプするだけなので、どんな小さなクラスタでも動作しますが、クラスタが大きくなるとメトリクスが圧倒的になることがあるので、最も簡単な解決策は、IstioがデプロイしたPrometheusをSysdigエージェントとフェデレートすることです。
プロセスは複雑ではありませんが、何をしているのかを理解しておく必要があります。このプロセスを支援するために、PromCat.ioのIstioページには、ダッシュボードとアラートを動作させるために必要なすべてのステップとファイルが含まれています。それらを簡単に見てみましょう。
まず、レコーディングルールを適用します。これらのルールは、インジェストするメトリクスの量を減らすために作成されます。小さなクラスタでは、多くのメトリクスを作成することはありませんが、クラスタが大きくなるにつれて、これらのメトリクスのカーディナリティは爆発的に増加します。
$ kubectl apply -f rules.yaml
Prometheusサーバでレコーディングルールを取得するには、ボリュームとしてマウントする必要があります。
$ kubectl -n istio-system patch deploy prometheus -p '{"spec":{"template":{"spec":{"volumes":[{"name":"config-rules","configMap":{"defaultMode":420,"name":"rules"}}]}}}}'
$ kubectl -n istio-system patch deploy prometheus -p '{"spec":{"template":{"spec":{"containers":[{"name":"prometheus","volumeMounts": [{"mountPath": "/opt/rules","name": "config-rules"}]}]}}}}'
Prometheusサーバのルールは、それを見つけられるように、そのconfigmapの中になければなりません。
$ kubectl -n istio-system edit cm prometheus
そして、この行をグローバル設定と同じレベルで追加します：
rule_files:
- /opt/rules/rules.yaml
また、Prometheusは、Sysdig Agentがスクレイプしないといけないので、アノテーションをつける必要があります。
$ kubectl -n istio-system patch deploy prometheus -p '{"spec":{"template":{"metadata":{"annotations":{"prometheus.io/scrape": "true", "prometheus.io/port": "9090"}}}}}'
設定がPrometheusで有効になっているのかを確認するために、一度、ポッドを削除します：
$ kubectl -n istio-system delete pods $(kubectl get pods --namespace istio-system -l "app=prometheus,release=istio" -o jsonpath="{.items[0].metadata.name}")
最後に、Sysdig Agentの設定を変更します。もしあなたがまだ別のPrometheusの設定を持っていないのであれば、提供されているconfigmapにパッチを当てるのが一番早くて簡単な方法です。
$ kubectl -n sysdig-agent patch cm sysdig-agent -p "$(cat patch.yaml)"
Sysdig AgentがPrometheusメトリクスの収集を開始したら、アラートとダッシュボードを作成します。このシンプルなコマンドを実行するだけで、Sysdigアカウント内のすべてを作成してくれます。必要なのは、$MONITOR_TOKENをSysdig Monitorの設定からSysdig APIキーに置き換えるだけです。
docker run sysdiglabs/promcat-connect install istio:1.5 -t $MONITOR_TOKEN
サービスの監視とは別に、IstioとSysdigの集約されたメトリクスを使用して、Istioの内部サービスの健全性とパフォーマンスを監視することができます。
Istioは独自のIngressコントローラを提供しており、監視すべきインフラストラクチャーにおいて非常に関連性の高い部分です。ユーザーがパフォーマンスの問題やエラーを経験している場合、エッジルーターは最初にチェックすべきポイントの1つです。
エッジルーターの接続のグローバルな健全性を評価するには、接続テーブル、グローバルHTTP応答コード、リソース使用量、サービスごとのリクエスト数、またはURLを表示することができます。
Istioの主な機能の1つは、サービスのバージョンに基づいてインテリジェントなルーティングを確立する機能です。
特定のサービスのバックエンドを提供するポッドは、異なるKubernetesラベルを持つことになります。
Labels: app=reviews
pod-template-hash=3187719182
version=v3
これらの異なるバックエンドは、消費者（サービスやファイナルユーザー）からは透過的ですが、Istioはこの情報を利用して実行することができます。
IstioとSysdigのメトリクスを集約することで、さらなる意思決定に必要なすべての情報を持って、これらのサービス移行を監督することができます。
例えば、アルファサービスポッドとベータサービスポッドを比較しています。彼らは同じKubernetesサービスを提供しており、Istioトラフィックシフトを使用して、イングレストラフィックを50対50で分割することを決定しています。
ご覧のように、リクエスト数とリクエストの持続時間(上の2つのグラフ)は非常に似ているので、負荷の面では公平な比較だと考えられます。
下の2つのグラフを見てみると、サービスαはHTTPエラーが3倍近く発生していることがわかります。また、最悪の場合のレスポンスタイム (99パーセンタイルの右下のグラフ) xn--nxa997t1fa1au5d8cya7ab3c9lsb5e4ad83eicz0an0ay953o.xn--n8je4cj2a9be2dvnqd9trjukxf6e2773c69a415yfx2c94wbbvkxo6h.)
Istioは「メッシュのもつれ」を解決し、サービスプロバイダーのポッドにサイドカーとして透過的なプロキシを追加します。この見晴らしの良い場所から、きめ細かなメトリクスを収集し、ポッドソフトウェアに干渉することなくルーティングフローを動的に変更することができます。
この戦略は、サービスポッドのシンプルさとインフラに依存しない（はずの）サービスポッドを維持するためのSysdigの類似した、非侵入的で最小限のインストルメンテーションアプローチをうまく補完しています。
今、あなたはサービスメトリクスを収集して、見栄えの良いダッシュボードに整理しています。サービスの品質を測定し、正しいアプリケーションの動作を診断するために、どのメトリクスが本当に重要かわかりますか？モニタリングの4つのゴールデンシグナルについて読む事をお勧めします。
Sysdigはモニタリングのベストプラクティスに従うのに役立ちます。今すぐお試しください。