• 信頼できないレジストリのコード。信頼できないコードにはマルウェアやバックドアが含まれていることがあり、悪意ある人物に意図せずアクセスを許可してしまう可能性があります。
• 基本イメージの肥大化。コンテナ化されたアプリケーションでは、よりコンパクトであることが重要であるため、危険にさらされる可能性のある不要なパッケージ、ライブラリ、およびシェルは排除する必要があります。
  

• 不要な権限の付与。可能な限り権限を最小限に抑え、タスクが必要とするシークレットのみをマウントすることで、攻撃対象領域を縮小できます。
• クラスタ内のアプリケーションを分離できない。ネームスペースを使用して、リソースとチームを相互に分離する必要があります。
• クラスタ内でのラテラルムーブメント。ネットワークをセグメント化するポリシーを使用して、クラスタ内での攻撃のラテラルムーブメント防ぎます。
• 不正アクセス。アクセスを制限するためのロールベースのアクセス コントロール（RBAC）を確実に設定します。
  

• インフラストラクチャ攻撃。API サーバ、etcd、コントローラなど、Kubernetes のすべてのインフラストラクチャ要素は、実行時にそれぞれが攻撃対象領域となります。
• 複雑性。Kubernetes クラスタの継続的な健全性には、さまざまな動的要素があります。侵害されたコンテナは迅速に隔離、停止して、健全なコンテナと交換する一方で、攻撃源を突き止め、修正する必要があります。
  

ベスト プラクティスの推奨事項は以下のとおりです。最小限の Distroless イメージから始め、絶対に必要なものだけを追加します。コンパクトであるほど安全です。

• 最小限のホスト OS を使用し、読み取り専用マウントを終了して、SELinux オプションによって制御をさらに強化します。
• OS イメージや外部イメージなど、あらゆる種類のイメージに脆弱性がないか、徹底的にスキャンします。外部に信頼できるソースなど存在しません。
• ネームスペースと RBAC を使用して、クラスタとユーザーを論理的にセグメント化します。不要なものは視認できないようにします。
• Kubernetes ネットワークのデフォルトでは Any-to-Any の通信が許可されるため、ネットワーク セグメンテーションは本番稼働の前に実装する必要があります。接続が適切にルーティングされるように、Ingress と Egress のポリシーを慎重に定義します。
• 権限は最小限にとどめ、決してアプリケーション プロセスを root で実行してはなりません。読み取り専用のルート ファイルシステムを使用することで、ソフトウェアのインストールやファイルシステムの変更による攻撃を防ぐことができます。
• CI/CD パイプラインにイメージ スキャンなどのセキュリティを統合します。さらに、CIS Benchmark のセキュリティ テストを実施するのもおすすめです。
• クラスタ自体の安全性を確保します。API サーバへのアクセスを制限する RBAC を設定し、すべての etcd 通信が TLS 暗号化によって保護されていることを確認します。同様に、kubelet の RBAC を設定して、kubelet の認証をロックダウンします。
• ポッドへのアクセスを制限するためのセキュリティ コンテキストを設定するなど、Kubernetes に組み込まれたコントロールを活用します。
• プロアクティブなセキュリティでは、プロセスのアクティビティ、サービス間の通信、クラスタの外部との通信を監視することが必要になります。