はじめに
Kubernetesのようなオーケストレーションツールは、ソフトウェアのデプロイと管理に前例のないレベルの復元力と汎用性をもたらしました。彼らはまた、現在のセキュリティ環境の不十分さにスポットライトを当てました。
Kubernetesの分散アーキテクチャは、いくつかの追加レイヤーを提供します。これらを使用して、既存のセキュリティ設定を強化および構築できます。これらのレイヤーを適切に構成すると、セキュリティの脅威を元の場所から発生する前に隔離できます。
この記事では、Kubernetesクラスタの全体的なセキュリティを向上させるために実行できる対策に焦点を当てています。
1。役割ベースのアクセス制御（RBAC）を有効にする
複数のデバイスで実行されるシステムの複雑さは、相互接続された多くのマイクロサービスが数百人の個人やユーティリティによって管理されているため、ロジスティック上の悪夢です。
ユーザーに付与される権限を厳密に制御します。 Kubernetesは、役割ベースのアクセス制御の提案者です（RBAC） 方法。ロールベースのアクセス制御方法は、必要以上の権限を持つユーザーがいないことを意味します。 彼らの仕事を効果的に達成するために。 Kubernetesは自動化がすべてであり、RBACはAPIグループを使用して、KubernetesAPIを介して承認の決定を推進します。
Kubernetesバージョン1.8の時点で、RBACモードは安定しており、rbac.authorization.k8s.io /v1APIによってサポートされています。次のコマンドでAPIサーバーを起動して、RBACを有効にします。
--authorization-mode=RBACKubernetesには、人間のユーザーと、アプリ、コントローラー、ノードなどのコンポーネントの両方に対して事前定義された役割のセットがあります。これらの事前定義された役割は多数あり、最も一般的なタスクに対して適切なデフォルトレベルの個別の役割を提供します。
2。あなたの秘密を秘密にしてください
Kubernetesでは、シークレットはパスワードやトークンなどの機密データを含む小さなオブジェクトです。
ポッドが別のポッドのシークレットにアクセスできない場合でも、シークレットを画像やポッドから分離しておくことが重要です。そうしないと、画像にアクセスできる人は誰でもシークレットにアクセスできます。複数のプロセスを処理し、パブリックアクセスを持つ複雑なアプリケーションは、この点で特に脆弱です。
プロセスを異なるコンテナに割り当てる
ポッド内の各コンテナは、そのボリューム内のシークレットボリュームを要求する必要があります。プロセスを個別のコンテナに分割することにより、秘密が公開されるリスクを軽減します。ユーザーと対話するが秘密鍵を表示できないフロントエンドコンテナを使用します。
そのコンテナを、秘密鍵を確認し、フロントエンドからの単純な署名要求に応答できる署名者コンテナで補完します。この分割されたアプローチにより、攻撃者はセキュリティ対策に違反するために一連の複雑なアクションを実行する必要があります。
3。 Kubernetesネットワークポリシーを使用してポッド間のトラフィックを制限する
これはKubernetesセキュリティのベストプラクティスです アプリケーション展開パイプラインの各レベルにTLSセキュリティプロトコルを課します。ただし、クラスタを構成する個々の要素と、クラスタへのアクセスを制御する要素を保護することも不可欠です。
ポッドは、デフォルトで任意のソースからのトラフィックを受け入れます。 ネットワークポリシーを定義する場合 、ポッドがクラスター内および外部リソースと通信する方法に特定のルールを設定します。
ネットワークポリシーは競合しませんが、代わりに付加的です。名前空間でネットワークポリシーを定義すると、ポッドはそのポリシーで許可されていない接続を拒否し、ポッドを効果的に分離します。ポッドは、複数のネットワークポリシーの組み合わせによって承認されたものに制限されます。
4。ポッドのセキュリティを強化する
AppArmorまたはSELinuxを使用したカーネルの保護
コンテナは同じカーネルを共有するため、コンテナの分離を改善するために追加のツールを使用する必要があります。 AppArmorなどのセキュリティモジュール およびSELinuxなどのアクセス制御ポリシーを適用するシステム 、ユーザープログラムとシステムサービスを制限します。また、ファイルへのアクセスを拒否し、ネットワークリソースを制限するためにも使用されます。
AppArmor システム内のコンテナで使用可能なリソースのセットを制限します。各プロファイルは、強制のいずれかで実行できます。 許可されていないリソースへのアクセスをブロックするモード、または不平を言う 違反のみを報告するモード。潜在的な問題をタイムリーに報告することで、システムのロギングおよび監査機能が大幅に向上します。
SELinux 一般的なLinuxACM（アクセス制御メカニズム）とは独立してリソース割り当てを管理します。スーパーユーザー（root）を認識せず、setuid/setgidバイナリに依存しません。
SELinuxを使用せずにシステムを保護するには、特権アプリケーションとカーネル自体の適切な構成が必要です。これらの領域の設定を誤ると、システム全体が危険にさらされる可能性があります。 SELinuxカーネルに基づくシステムのセキュリティは、カーネルの正確性とそのセキュリティポリシー構成に依存します。
攻撃は依然として重大な脅威をもたらします。ただし、SELinuxでは、個々のユーザープログラムとシステムデーモンが必ずしもシステム全体のセキュリティを危険にさらす必要はありません。
汚染と許容範囲
Kubernetesには、システムが新しいポッドをノードに割り当てるときに、事前定義されたルールを作成するオプションがあります。
オーケストレーションツールとして、Kubernetesは、クラスター内の最も効率的な場所、つまりワークロードが最小の場所でポッドを開始する傾向があります。 汚染と許容範囲を定義することで、ポッドの配置を微調整することができます。
汚染により、ノードは事前定義されたルールに基づいてポッドまたはポッドのセットを「拒否」できます。一方、許容値はポッドレベルで適用され、ポッドが一致する汚染を持つノードにスケジュールできるようにします（キーと効果は同じです）。
ポッドが不適切なノードにスケジュールされないように、汚染と許容範囲を組み合わせて使用する必要があります。
名前空間
Kubernetesには、名前空間全体にセキュリティを提供するメカニズムがありません。セキュリティ機能として、信頼できるドメイン内で、内部目的で名前空間の使用を制限します。 Kubernetesクラスタのユーザーが他の名前空間のリソースにアクセスすることを拒否する場合は、名前空間を使用しないでください。
watch およびlist リクエストにより、クライアントはその名前空間にあるすべてのシークレットの値を検査できます。最も特権のあるシステムレベルのコンポーネントのみが、これらの要求を実装するためのアクセス許可を持っている必要があります。
5。 Kubernetesローリングアップデート
すべての潜在的な攻撃ベクトルを追跡することは不可能になりました。この事実は残念なことです。潜在的な脅威に気づき、その上に立つことほど重要なことはないからです。最善の防御策は、利用可能な最新バージョンのKubernetesを実行していることを確認することです。
ローリング更新やノードプールの移行など、中断とダウンタイムを最小限に抑えて更新を完了することができるいくつかの手法があります。
6。監査ポリシーの定義
監査ログは、Kubernetesクラスターで発生するイベントのタイムラインを記録します。管理者は、ユーザーとKubernetes APIによって実行されたアクションを追跡することで、潜在的な問題の原因となった一連のイベントを分析できます。
Kubernetesを使用すると、イベントがログに記録される頻度、アラートを発行する必要があるかどうか、影響を受けるポッドを終了する手順を定義することで、監査ポリシーを微調整できます。
監査ログを定期的に使用して、システムが最新であり、脅威がタブの下に保持されていることを確認します。コンテナベースの展開は、監査プロセスに別の側面を追加します。元のイメージとコンテナーで実行されているイメージの比較を効果的に使用して、不一致がセキュリティ上の懸念につながる可能性があるかどうかを確認できます。ソフトウェアバージョンに常に最新のセキュリティパッチが含まれていることを確認してください。