Kubernetes 実稼働環境のベストプラクティス

この記事では、Kubernetes 上で安全でスケーラブルかつ回復力のあるサービスをデプロイするための実行可能なベスト プラクティスのみを紹介します。参考用です。

本番環境へのリリースを支援するために設計された、厳選されたベスト プラクティスのリストです。

アプリケーション開発

健康チェック

• コンテナには準備プローブが必要です。
• 注: 準備プローブと生存プローブにはデフォルト値はありません。
• 準備プローブを設定しない場合、kubelet はコンテナが起動するとすぐにアプリケーションがトラフィックを受信する準備ができていると想定します。
• コンテナの起動に 2 分かかる場合、その 2 分間にコンテナに対して行われたすべてのリクエストは失敗します。
• 回復不可能なエラー (致命的なエラー) が発生した場合にコンテナをクラッシュさせます。
• アプリケーションで回復不可能なエラーが発生した場合は、クラッシュさせる必要があります。
• 回復不可能なエラーの例は次のとおりです。

• キャッチされない例外。
• コード内のタイプミス（動的言語の場合）。
• ヘッダーまたは依存関係を読み込めません。

• 失敗した活性プローブを発行してはならないことに注意してください。
• 代わりに、プロセスをすぐに終了し、kubelet にコンテナを再起動させる必要があります。
• パッシブ活性検出を設定します。
• 活性プローブは、コンテナがスタックした場合にコンテナを再起動するように設計されています。
• 次のシナリオを検討してください。アプリケーションが無限ループを処理している場合、終了したりヘルプを求めたりする方法はありません。
• プロセスが CPU を 100% 消費すると、(他の) 準備プローブ チェックに応答する時間がなく、最終的にはサービスから削除されます。
• ただし、Pod は現在のデプロイメントのアクティブなレプリカとして登録されたままです。
• ライブネス プローブがない場合、ライブネス プローブは実行されたままになりますが、サービスからは切り離されます。
• つまり、プロセスはリクエストに応えていないだけでなく、リソースも消費しています。
• 何をすべきでしょうか?
• アプリケーションからエンドポイントを公開します。
• エンドポイントは常に成功応答を返します。
• Liveness プローブでエンドポイントを使用します。
• アプリケーション内の致命的なエラーを処理し、Kubernetes にアプリケーションの再起動を要求するために、ライブネス プローブを使用しないでください。
• 代わりに、アプリケーションをクラッシュさせる必要があります。
• プロセスが応答しなくなった場合にのみ、活性プローブを回復メカニズムとして使用する必要があります。
• 準備プローブと生存プローブの値が異なることを確認してください。
• Liveness と Readiness の値が同じ場合、アプリケーションが準備ができていない、またはオンラインでないことを示す信号を送信すると、kubelet はコンテナをサービスからデタッチして削除し、接続が失われる可能性があります。コンテナには着信接続を処理するのに十分な時間がないからです。

アプリケーションの独立した展開

準備調査は独立している

準備プローブには、次のようなサービスへの依存関係は含まれません。

• データベース。
• データベースの移行。
• API。
• サードパーティのサービス。

参考リンク: https://blog.colinbreck.com/kubernetes-liveness-and-readiness-probes-how-to-avoid-shooting-yourself-in-the-foot/#shootingyourselfinthefootwithreadinessprobes.

アプリケーションの再接続メカニズム

アプリケーションの起動時には、データベースなどの依存関係がまだ準備ができていないため、クラッシュすることはありません。

代わりに、アプリケーションは成功するまでデータベースへの接続を継続的に再試行する必要があります。

Kubernetes では、アプリケーション コンポーネントを任意の順序で起動できることが想定されています。

アプリケーションが依存関係 (データベースなど) に再接続できることが保証されると、より堅牢で回復力のあるサービスを提供できることがわかります。

アプリケーションを正常にシャットダウンする

アプリケーションは、SIGTERM を受信して​​もすぐに終了せず、しばらく待ってから接続を正常に終了します。

終了信号を受信した後でも、すべての kube-proxy が iptables ルールまたは ipvs ルールの更新を完了するまで、ポッドは接続を受け入れ続ける必要がある場合があります。

おそらく、ingress-controller と Loadblance も接続を POD に転送するでしょう。

どのクライアントでも切断が発生しないようにするには、すべてのクライアントがポッドへの接続を転送しないことを何らかの方法で通知するまで待つ必要があります。

しかし、明らかに、これらすべてのコンポーネントが多数の異なるコンピューターに分散されているため、これは不可能です。いずれかが応答の書き込みに失敗した場合、アプリケーションを閉じることができなくなります。

一般的には、事前停止フックを設定します。

 ライフサイクル：
 プレストップ:
 実行:
 指示：
 -sh
 -c
 - 「5時に寝る」

SIGTERMシグナルをプロセスに転送する

ポッドが終了する直前に、アプリケーションで SIGTERM シグナルをキャッチできます。 tini を使用できます。 tini プロジェクト アドレス: https://github.com/krallin/tini。

アイドル状態のkaap-aliveソケットをすべて閉じます

ポッドが削除されたときに呼び出し元のアプリケーションが TCP 接続を閉じない場合、理想的にはリクエストを別のポッドに送信する必要があります。ただし、呼び出し元のアプリケーションは、終了しようとしているポッドへの長時間の接続を保持しており、引き続き使用します。長時間の接続は突然終了しないでください。アプリケーションをシャットダウンする前にそれらを終了する必要があります。

フォールトトレランス

デプロイされたポッドの複数のレプリカを実行する

単一の Pod を単独で実行しないでください。

代わりに、Deployment、DaemonSet、ReplicaSet、または StatefulSet の一部として Pod をデプロイすることを検討してください。

複数の Pod インスタンスを実行すると、1 つの Pod を削除してもダウンタイムが発生しなくなります。

ポッドを単一のノードに配置しないようにする

次のシナリオを考えてみましょう。単一のクラスター ノードに 11 個のレプリカがあります。

ノードが使用できなくなると、11 個のレプリカが失われ、ダウンタイムが発生します。

ポッドがクラスター内のすべてのノードに分散されるように、デプロイメントにアンチアフィニティ ルールを適用する必要があります。

ポッド間アフィニティと反アフィニティのドキュメントでは、ポッドを同じノードに配置する (または配置しない) ように変更する方法について説明しています。

ポッド中断予算を設定します。

ポッド中断予算を設定する

翻訳すると、POD 干渉バジェットを構成することを意味します。通常状態のアプリケーション ポッドの最小数またはパーセンテージを設定することにより、ポッドがアクティブに破棄されるときに、破棄されるポッドが多すぎて異常な業務中断が発生することがなくなり、ビジネスの可用性が向上します。

参考リンク: https://zhuanlan.zhihu.com/p/367827614.

Pod 中断予算を理解するための公式ドキュメントはhttps://kubernetes.io/docs/concepts/workloads/pods/disruptions/ です。

リソースの利用

すべてのコンテナのメモリ制限とリクエストを設定する

リソース制限は、コンテナが使用できる CPU とメモリの量を制限するために使用され、 containerSpecフィールドを使用して構成されます。

スケジューラはこれらをメトリックの 1 つとして使用し、現在の Pod に最適なノードを決定します。

リソース制限のないコンテナのスケジューリング優先度は 0 です。つまり、OOM が発生すると、そのようなコンテナが最初に停止されます。

CPU は圧縮可能なリソースであるため、コンテナーが制限を超えると、プロセスが調整されます。

適切なCPU またはメモリの制限がわからない場合は、Kubernetes の Vertical Pod Autoscaler を使用して推奨モードをオンにすることができます。オートスケーラーはアプリを分析し、アプリの制限を推奨します。

CPU要求を1CPU以下に設定する

計算負荷の高いジョブがない限り、リクエストを 1 CPU 以下に設定することをお勧めします。

CPUスロットリングを無効にする

アプリケーションに最適な設定がわからない場合は、CPU 制限を設定しないことをお勧めします。

さらに詳しく知りたい場合は、この記事で CPU 要求と制限について詳しく説明します。 https://medium.com/@
betz.mark/understanding-resource-limits-in-kubernetes-cpu-time-9eff74d3161b.

名前空間の LimitRange を設定する

メモリと CPU の制限を設定するのを忘れた可能性がある場合は、LimitRange オブジェクトを使用して、現在の名前空間にデプロイされているコンテナーの標準サイズを定義することを検討してください。

LimitRange の公式ドキュメントは https://kubernetes.io/docs/concepts/policy/limit-range/ です。

ポッドに適切なQoS（サービス品質）を設定する

ノードのリソース使用量が高すぎる場合、Kubernetes はノードから一部のポッドを削除しようとします。

Kubernetes は、定義された優先順位と QoS に基づいてポッドをランク​​付けして排除します。

Qos の設定方法については、公式ドキュメント ( https://kubernetes.io/docs/tasks/configure-pod-container/quality-service-pod/) を参照してください。

リソースタグ

テクノロジー関連のタグを定義する

関連技術の公式推奨タグは次のとおりです。

公式ドキュメント: https://kubernetes.io/docs/concepts/overview/working-with-objects/common-labels/。

• name 、アプリケーションの名前（例："User API"）。
• instance 、アプリケーション インスタンスを識別する一意の名前 (コンテナ イメージ タグを使用できます)。
• version 、アプリケーションの現在のバージョン (増加カウンター)。
• コンポーネント「API」や「データベース」など、アーキテクチャ内のコンポーネント。
• part-of 、「支払いゲートウェイ」の一部である上位レベルのアプリケーションの名前。
• managed-by 、「kubectl」や「Helm」など、アプリケーション操作を管理するために使用されるツール。

例：

 apiバージョン: アプリ/ v1
 種類: デプロイメント
メタデータ:
 名前: デプロイメント
ラベル:
 アプリ。 Kubernetes 。 io / 名前: ユーザー- API
 アプリ。 Kubernetes 。 io / インスタンス: ユーザー- API - 5f a65d2
 アプリ。 Kubernetes 。 io / バージョン: "42"
 アプリ。 Kubernetes 。 io / コンポーネント: API
 アプリ。 Kubernetes 。 io / 一部： 支払いゲートウェイ​ ​
 アプリ。 Kubernetes 。 io / 管理元: kubectl
 仕様:
 レプリカ: 3
 セレクター:
 マッチラベル:
 アプリケーション: my - app
 テンプレート：
 メタデータ:
 ラベル:
 アプリ。 Kubernetes 。 io / 名前: ユーザー- API
 アプリ。 Kubernetes 。 io / インスタンス: ユーザー- API - 5f a65d2
 アプリ。 Kubernetes 。 io / バージョン: "42"
 アプリ。 Kubernetes 。 io / コンポーネント: API
 アプリ。 Kubernetes 。 io / 一部： 支払いゲートウェイ​ ​
 仕様:
 コンテナ:
 - 名前: アプリ
画像: myapp

ビジネスタグの定義

Pod には次のラベルをタグ付けできます。

• 所有者: リソースの責任者を識別します。
• project は、リソースが属するプロジェクトを決定します。
• business-unit は、リソースに関連付けられたコスト センターまたはビジネス ユニットを識別します。通常、コストの割り当てと追跡に使用されます。

例：

 apiバージョン: アプリ/ v1
 種類: デプロイメント
メタデータ:
 名前: デプロイメント
ラベル:
 所有者: 支払い- チーム
プロジェクト: 不正行為の検出
事業所- ユニット: 「80432」
 仕様:
 レプリカ: 3
 セレクター:
 マッチラベル:
 アプリケーション: my - app
 テンプレート：
 メタデータ:
 ラベル:
 所有者: 支払い- チーム
プロジェクト: 不正行為の検出
事業所- ユニット: 「80432」
 仕様:
 コンテナ:
 - 名前: アプリ
画像: myapp

セキュリティラベルの定義

Pod には次のラベルをタグ付けできます。

• 機密性: リソースによってサポートされる特定のデータ機密性レベルの識別子。
• コンプライアンス: 特定のコンプライアンス要件に準拠するように設計されたワークロードの識別子。

例：

 apiバージョン: アプリ/ v1
 種類: デプロイメント
メタデータ:
 名前: デプロイメント
ラベル:
 機密性： 公式
コンプライアンス: PCI
 仕様:
 レプリカ: 3
 セレクター:
 マッチラベル:
 アプリケーション: my - app
 テンプレート：
 メタデータ:
 ラベル:
 機密性： 公式
コンプライアンス: PCI
 仕様:
 コンテナ:
 - 名前: アプリ
画像: myapp

ログ記録

アプリケーションログをstdoutとstderrに出力

ログ記録戦略には、パッシブとアクティブの 2 つがあります。

パッシブ戦略を使用するアプリケーションは、メッセージを標準出力に記録します。

このベストプラクティスは、12 要素アプリの一部です。

アクティブ ログでは、アプリケーションは中間アグリゲータへのネットワーク接続を確立し、サードパーティのログ サービスにデータを送信するか、データベースまたはインデックスに直接書き込みます。

アクティブ ログはアンチパターンと見なされるため、回避する必要があります。

ログ記録にサイドカーを使用しない（可能な場合）

非標準のログ イベント モデルを持つアプリケーションにログ変換を適用する場合は、サイドカー コンテナーを使用することをお勧めします。

サイドカー コンテナーを使用すると、ログ エントリを他の場所に送信する前に正規化できます。

たとえば、Apache ログをログ インフラストラクチャに送信する前に、Logstash JSON 形式に変換する必要がある場合があります。

ただし、アプリケーションを制御できる場合は、最初から正しい形式で出力できます。

クラスター内の各ポッドに対して追加のコンテナを実行する手間を省くことができます。

ズーム

コンテナはローカル ファイル システムに状態を​​保存しません。

コンテナには、永続的なデータに使用できるローカル ファイル システムがあります。

ただし、コンテナのローカル ファイル システムに永続データを保存すると、コンテナに含まれる Pod を水平方向にスケーリングできなくなります (つまり、Pod のレプリカを追加または削除することができません)。

これは、ローカルファイルシステムを使用すると、各コンテナが独自の「状態」を維持するため、Pod レプリカの状態が時間の経過とともに変化する可能性があるためです。これにより、ユーザーの観点からは動作に一貫性がなくなる可能性があります (たとえば、リクエストが 1 つの Pod に到達したときには特定のユーザー情報が利用可能になりますが、リクエストが別の Pod に到達したときには利用できません)。

代わりに、永続的な情報は Pod の外部の中央の場所に保管する必要があります。たとえば、クラスター内の PersistentVolume 内、またはさらに良い方法としては、クラスター外のストレージ サービス内です。

使用パターンが変化するアプリケーションに水平ポッドオートスケーラーを使用する

Horizo​​ntal Pod Autoscaler (HPA) は、アプリケーションを監視し、現在の使用状況に基づいて Pod レプリカを自動的に追加または削除する組み込みの Kubernetes 機能です。

HPA を構成すると、予期しない急増を含むあらゆるトラフィック状況でもアプリケーションの可用性と応答性が維持されます。

アプリケーションを自動的にスケーリングするように HPA を構成するには、アプリケーションを監視するメトリックを定義する Horizo​​ntalPodAutoscaler リソースを作成する必要があります。

HPA は、組み込みのリソース メトリック (Pod の CPU とメモリの使用量) またはカスタム メトリックを監視できます。カスタム メトリックの場合は、これらのメトリックを収集して公開する責任も負います。たとえば、Prometheus と Prometheus アダプターを使用してこれを実行できます。

ベータ版のVertical Pod Autoscalerは使用しないでください

水平ポッドオートスケーラー (HPA) と同様に、垂直ポッドオートスケーラー (VPA) も存在します。

VPA は、ポッドのリソース要求と制限に自動的に適応できるため、ポッドがさらに多くのリソースを必要とするときに、それらを取得できます (単一のポッドのリソースを増減することを垂直スケーリングと呼び、ポッドのレプリカの数を増減することを意味する水平スケーリングとは対照的です)。

これは、水平方向にスケーリングできないアプリケーションをスケーリングする場合に便利です。

ただし、VPA は現在ベータ版であり、いくつかの既知の制限があります (たとえば、リソース要件を変更してポッドをスケーリングするには、ポッドを強制終了して再起動する必要があります)。

これらの制限と、Kubernetes 上のほとんどのアプリケーションがいずれにしても水平方向にスケーリングされるという事実を考慮すると、VPA を本番環境で使用することはお勧めしません (少なくとも安定したバージョンが利用可能になるまでは)。

ワークロードが大きく変動する場合は、Cluster Autoscalerを使用してください。

クラスター オートスケーラーは、別のタイプの「オートスケーラー」です (水平ポッド オートスケーラーと垂直ポッド オートスケーラーに加えて)。

Cluster Autoscaler は、ワーカー ノードを追加または削除することで、クラスターのサイズを自動的にスケーリングできます。

既存のワーカーノードのリソースが不足しているためにポッドをスケジュールできない場合にスケーリングが発生します。この場合、Cluster Autoscaler は、ポッドをスケジュールできるように新しいワーカーノードを作成します。同様に、既存のワーカーノードの使用率が低い場合、クラスター オートスケーラーはワーカーノードからすべてのワークロードを排除して削除することでスケールダウンできます。

Cluster Autoscaler の使用は、たとえば、ポッドの数が短期間に増加し、その後以前の値に戻る可能性がある場合など、変動の大きいワークロードに適しています。この場合、Cluster Autoscaler を使用すると、リソースを無駄にすることなくワーカーノードをオーバープロビジョニングすることで、需要の急増に対応できます。

ただし、ワークロードがそれほど変化しない場合は、クラスター オートスケーラーがトリガーされない可能性があるため、設定する価値がない可能性があります。ワークロードがゆっくりと単調に増加する場合は、既存のワーカー ノードの使用率を監視し、臨界値に達したときに手動でワーカー ノードを追加するだけで十分な場合があります。

構成とシークレット

すべての構成を外部化する

構成はアプリケーション コードの外部で維持する必要があります。

これにはいくつかの利点があります。まず、構成を変更してもアプリケーションを再コンパイルする必要はありません。 2 番目に、アプリケーションの実行中に構成を更新できます。 3 番目に、同じコードをさまざまな環境で使用できます。

Kubernetes では、構成を ConfigMap に保存し、環境変数として渡されるボリュームとしてコンテナにマウントできます。

ConfigMaps には機密性のない構成のみを保存します。資格情報などの機密情報については、Secret リソースを使用します。

環境変数ではなくボリュームとしてシークレットをマウントする

Secret リソースの内容は、環境変数として渡すのではなく、ボリュームとしてコンテナーにマウントする必要があります。

これは、コンテナを起動するために使用されるコマンドに秘密の値が表示されないようにするためです。秘密の値にアクセスするべきでない個人が、秘密の値を表示してしまう可能性があります。

ガバナンス

名前空間の制限

名前空間構成の制限範囲

制限のないコンテナでは、他のコンテナとのリソース競合が発生し、コンピューティング リソースの消費が最適化されない可能性があります。

Kubernetes には、リソース使用量を制限するための ResourceQuota と LimitRange という 2 つの機能があります。

LimitRange オブジェクトを使用すると、名前空間内の個々のコンテナのリソース要求と制限のデフォルト値を定義できます。

名前空間内に作成され、リクエスト値と制限値を明示的に指定していないコンテナには、デフォルト値が割り当てられます。

リソースクォータについては、公式ドキュメントを確認してください。 https://kubernetes.io/docs/concepts/policy/resource-quotas/。

名前空間構成リソースクォータ

ResourceQuotas を使用すると、名前空間内のすべてのコンテナの合計リソース消費量を制限できます。

名前空間のリソース クォータを定義すると、その名前空間に属するすべてのコンテナーが使用できる CPU、メモリ、またはストレージ リソースの合計量が制限されます。

現在の名前空間内の Pod の数など、他の Kubernetes オブジェクトのクォータを設定することもできます。

誰かがクラスターを悪用して 20,000 個の ConfigMap を作成する可能性があると思われる場合は、LimitRange を使用すると、そのような事態を防ぐことができます。

ポッドセキュリティポリシー

ポッドセキュリティポリシーを有効にする

Kubernetes Pod セキュリティ ポリシーを使用して、次のものを制限できます。

• ホスト プロセスまたはネットワーク名前空間にアクセスします。
• 特権コンテナを実行します。
• コンテナを実行するユーザー。
• ホスト ファイル システムにアクセスします。
• Linux 機能、Seccomp、または SELinux プロファイル。

Kubernetes Pod セキュリティ ポリシーのベスト プラクティス(https://www.mend.io/resources/blog/kubernetes-pod-security-policy/) を参照してください。

特権コンテナを無効にする

Pod 内では、コンテナは「特権」モードで実行でき、ホスト システム上のリソースにほぼ無制限にアクセスできます。

このレベルのアクセスが必要な特定のユースケースもありますが、一般的に、コンテナにこれを許可するとセキュリティ上のリスクが生じます。

特権ポッドの有効な使用例としては、ノード上の GPU などのハードウェアの使用が挙げられます。

セキュリティ コンテキストと権限コンテナーの詳細については、次の記事を参照してください: https://kubernetes.io/docs/tasks/configure-pod-container/security-context/。

コンテナ内での読み取り専用ファイルシステムの使用

コンテナ内で読み取り専用ファイル システムを実行すると、コンテナは不変になります。

これにより、ホットパッチなどの古い（リスクの高い）手法が軽減されるだけでなく、悪意のあるプロセスがコンテナ内でデータを保存または操作するリスクを防ぐこともできます。

読み取り専用ファイルシステムでコンテナを実行するのは単純に思えるかもしれませんが、いくつかの複雑な問題が発生する可能性があります。

ログを書き込んだり、一時フォルダーにファイルを保存したりする必要がある場合はどうすればよいでしょうか?

本番環境でコンテナを安全に実行することのトレードオフについては、こちらの記事で学べます: https://medium.com/@
axbaretto/実稼働環境で安全に docker コンテナを実行する-98b8104ef68。

コンテナがルートとして実行されないようにする

コンテナ内で実行されているプロセスは、コンテナ内にあることを示す小さなメタデータを持っていることを除いて、ホスト上の他のプロセスと何ら変わりはありません。

したがって、コンテナ内の root はホスト上の root (uid 0) と同じになります。

ユーザーがコンテナ内で root として実行されているアプリケーションから抜け出すことができた場合、同じ root ユーザーでホスト マシンにアクセスできる可能性があります。

権限のないユーザーを使用するようにコンテナを構成することが、権限昇格攻撃を防ぐ最善の方法です。

さらに詳しく知りたい場合は、次の記事で、コンテナをルートとして実行した場合に何が起こるかについての詳細な例をいくつか紹介します: ttps://medium.com/@
mccode/コンテナー内のプロセスは root として実行しないでください-2feae3f0df3b。

Linuxの一部の機能を制限する

Linux の機能により、デフォルトでは root ユーザーのみが実行できる多くの特権操作をプロセスで実行できるようになります。

たとえば、 CAP_CHOWN を使用すると、プロセスは「ファイルの UID と GID に任意の変更を加える」ことができます。

プロセスがrootとして実行されていない場合でも、権限を昇格することでプロセスがこれらの root のような機能を使用することは可能です。

つまり、危険にさらされたくない場合は、必要な機能のみを有効にする必要があります。

しかし、どの機能を有効にすべきでしょうか、またその理由は何でしょうか?

次の 2 つの記事では、Linux カーネルの機能に関する詳細な理論と実践のベスト プラクティスについて説明します。

• Linux の機能: 存在する理由と仕組み: https://blog.container-solutions.com/linux-capabilities-why-they-exist-and-how-they-work.
• Linux 機能の実践https://blog.container-solutions.com/linux-capabilities-in-practice.

Linux の権限昇格を防ぐ

setuidまたはsetgidバイナリを使用した権限の昇格を防ぐには、権限の昇格をオフにしてコンテナを実行する必要があります。

ネットワークポリシー

1. コンテナはネットワーク内の他のコンテナと通信することができ、そのプロセスではアドレス変換は行われません。つまり、NAT は使用されません。
2. クラスター内のノードはネットワーク内の他のコンテナと通信でき、その逆も同様です。この場合でも、アドレス変換、つまり NAT は行われません。
3. コンテナの IP アドレスは常に同じであり、別のコンテナから見ても、それ自体から見ても独立しています。

クラスター内の悪意のあるユーザーはクラスターにアクセスし、クラスター全体にリクエストを送信できるようになります。

これを解決するには、ネットワーク ポリシーを使用して、現在の名前空間内および名前空間間で Pod が通信できる方法を定義できます。

ネットワークポリシーを有効にする

Kubernetes ネットワーク ポリシーは、クラウド内のセキュリティ グループが VM インスタンスへのアクセスを制御するために使用されるのと同じように、Pod のグループに対するアクセス権限を指定します。

つまり、Kubernetes クラスター上で実行されている Pod 間にファイアウォールを作成します。

Kubernetes クラスター ネットワーク: https://ahmet.im/blog/kubernetes-network-policy/。

各名前空間には、デフォルトで保守的な NetworkPolicy が必要です。

Kubernetes 上で実行されているアプリケーションのトラフィックをドロップ/スロットルする方法について詳しく知りたい場合は、このドキュメントをご覧ください。 https://github.com/ahmetb/kubernetes-network-policy-recipes。

ロールベースのアクセス制御 (RBAC) ポリシー

デフォルトのServiceAccountの自動マウントを無効にする

デフォルトの ServiceAccount はすべての Pod のファイルシステムに自動的にマウントされることに注意してください。

これを無効にして、より詳細なポリシーを提供することもできます。

RBACポリシーは、必要な最小限の権限に設定されます

RBAC ルールを設定する方法に関する適切なアドバイスを見つけるのは困難です。 Kubernetes RBAC への 3 つの実践的なアプローチでは、3 つの実際のシナリオと、開始方法に関する実践的なアドバイスを見つけることができます。

実際のシナリオについては、次のドキュメントを参照してください: https://thenewstack.io/three-realistic-approaches-to-kubernetes-rbac/。

RBACポリシーは細かく設定されており、共有されない

ロールと ServiceAccounts を定義するための簡潔な戦略があります。

まず、彼らは自分たちの要件を説明しました。

• ユーザーはデプロイできる必要がありますが、たとえば Secrets の読み取りは許可されません。
• 管理者にはすべてのリソースへの完全なアクセス権を与える必要があります。
• デフォルトでは、アプリケーションに Kubernetes API への書き込みアクセス権を与えるべきではありません。
• 何らかの用途のために Kubernetes API に書き込むことも可能になるはずです。

これら 4 つの要件は、次の 5 つの個別の役割に変換されます。

• 読み取り専用。
• スーパーユーザー。
• オペレーター。
• コントローラ。
• 行政上の。

この定義については、次のリンクで読むことができます: https://kubernetes-on-aws.readthedocs.io/en/latest/dev-guide/arch/access-control/adr-004-roles-and-service-accounts.html。

カスタムポリシー

• 既知のイメージ レジストリからのコンテナのデプロイのみを許可します。
• Ingress で定義されたドメイン名の一意性を強制します。
• Ingress ホスト名には承認されたドメイン名を使用します。

クラスタ構成

推奨されるKubernetes構成

クラスターはCISベンチマークテストに合格しました

インターネット セキュリティ センターでは、コードを保護するためのベスト プラクティスに関するガイダンスとベンチマークを提供しています。

また、Kubernetes のベンチマークも維持しています。公式ウェブサイトのアドレスはhttps://www.cisecurity.org/benchmark/kubernetes です。

長いガイドを読んでクラスターのコンプライアンスを手動で確認することもできますが、より簡単な方法はkube-bench をダウンロードして実行することです。

ダウンロードアドレス: https://github.com/aquasecurity/kube-bench。

kube-bench は、 CIS Kubernetes ベンチマークを自動化し、クラスター内の誤った構成を報告するように設計されたツールです。

サンプル出力:

 [ 情報] 1 マスターノードのセキュリティ構成
 [ 情報] 1.1 API サーバー
 [ 警告] 1.1 .1 --anonymous - auth 引数がfalse （ スコアなし） に設定されていることを確認してください
 [ 合格] 1.1 .2 --basic - auth - file 引数が設定されていないことを確認する( 採点)
 [ 合格] 1.1 .3 --insecure - allow - any - token 引数が設定されていないことを確認する( スコアなし)
 [ 合格] 1.1 .4 --kubelet - https 引数がtrue に設定されていることを確認する( 採点)
 [ 合格] 1.1 .5 --insecure - bind - address 引数が設定されていないことを確認する( 採点)
 [ 合格] 1.1 .6 --insecure - port 引数が0 に設定されていることを確認する( 採点)
 [ 合格] 1.1 .7 -- secure - port 引数が0 に設定されていないことを確認する( 採点)
 [ 不合格] 1.1 .8 --profiling 引数がfalse に設定されていることを確認する（ 採点）

マスターがクラウド プロバイダーによってホストされている場合、 kube-bench は使用できません。

アルファまたはベータ API 機能へのアクセスを制限する

Kubernetes のアルファ版およびベータ版の機能は現在開発中であり、セキュリティの脆弱性につながる可能性のある制限やバグがある可能性があります。

アルファ機能またはベータ機能が提供する価値と、セキュリティ体制への潜在的なリスクを常に評価してください。

確認する

ユーザー認証戦略として OpenID (OIDC) トークンを使用する

Kubernetes は、OpenID Connect (OIDC) を含むさまざまな認証方法をサポートしています。

OpenID Connect を使用すると、シングル サインオン (SSO) (Google ID など) を使用して Kubernetes クラスタやその他の開発ツールに接続できます。

資格情報を別途覚えたり管理したりする必要はありません。

複数のクラスターを同じ OpenID プロバイダーに接続できます。

Kubernetes の OpenID Connect に関する詳細情報。こちらにアクセスしてください: https://thenewstack.io/kubernetes-single-sign-one-less-identity/

ロールベースのアクセス制御 (RBAC)

ServiceAccountトークンはアプリケーションとコントローラーでのみ使用可能です

サービス アカウント トークンは、Kubernetes クラスターと対話しようとするエンド ユーザーには使用できませんが、Kubernetes 上で実行されるアプリケーションやワークロードには推奨される認証戦略です。

ログ設定

ログの保持とアーカイブ戦略

30 ～ 45 日間の履歴ログを保存する必要があります。

ノード、コントロールプレーン、監査からログを収集する

ログが収集される側面:

• ノード (kubelet、コンテナー ランタイム)。
• コントロール プレーン (API サーバー、スケジューラ、コントローラ マネージャー)。
• Kubernetes 監査 (API サーバーへのすべてのリクエスト)。

収集すべきもの:

• アプリケーションの名前。メタデータ タグから取得されました。
• アプリケーション例。メタデータ タグから取得されました。
• アプリケーションのバージョン。メタデータ タグから取得されました。
• クラスター ID。 Kubernetes クラスターから取得されました。
• コンテナの名前。 Kubernetes API から取得されました。
• このコンテナが実行されているクラスター ノード。 Kubernetes クラスターから取得されました。
• コンテナを実行するポッドの名前。 Kubernetes クラスターから取得されました。
• 名前空間。 Kubernetes クラスターから取得されました。

サイドカーの代わりに各ノードでデーモンを使用してログを収集することを優先する

アプリケーションはファイルではなく標準出力にログを記録する必要があります。

各ノード上のデーモンは、コンテナ ランタイムからログを収集できます (ファイルにログを記録する場合は、ポッドごとにサイドカー コンテナが必要になる場合があります)。

参照アドレス: https://rclayton.silvrback.com/container-services-logging-with-docker#effective-logging-infrastructure。

ログ集約ツールの設定

EFK スタック (Elasticsearch、Fluentd、Kibana)、DataDog、Sumo Logic、Sysdig、GCP Stackdriver、Azure Monitor、AWS CloudWatch などのログ集約ツールを使用します。