Nodeの保護

Nodeの保護を実装する上で検討が必要な以下の観点のうち、ここでは★印の2つを扱います。

  • ネットワークアクセスの制限
  • 特権操作からの保護
  • 不審なアクティビティの検出
  • リソースの保護 ★
  • ストレージの暗号化 ★

「ネットワークアクセスの制限」については、次回以降で取り上げます。

「特権操作からの保護」はいくつかの観点に分かれます。今後、イメージ内にSUIDやSGIDが付与されたファイルが存在しないかを検査したり、SecurityContextで設定するPodやコンテナのCapabilityやhostNetworkなどのPodをデプロイしたりする際の設定の話のほか、クラスタ内に特権を持ったPodがデプロイされるのを検知し防止する方法は、Azure Policyを使ったSecurityContextの設定の検査の話として紹介します。

「不審なアクティビティの検出」についてはMicrosoft Defender for Containersを扱うパートで扱います。

リソースの保護

リソースの保護をどの程度慎重に検討する必要があるかは、クラスタを何単位で構築しているのかによります。

クラスタを複数のチームで共有している場合は、特定のチームがリソースを食いつぶさないように制限をする必要があります。クラスタを1つのチームで占有している場合は、主に以下のような観点でリソースの保護を検討することになります。

  1. クラスタ全体を安定稼働させるため、システムPodが動作するNodeを保護する（システムノードプール）
  2. GPUなどの特殊なハードウェアを備えるNodeに配置されるPodを制限する
  3. 巨大なPodがなんらかの理由によってデプロイされ、リソースが占有されてしまうことを防ぐ
  4. 異常な動作をしているPodによって、Nodeのリソースが食いつぶされてしまうことを抑制する

TaintとToloration

TaintはPodをNodeに配置させないための仕組みです。TaintsをNodeにTolerationsをPodに設定することで、条件が一致したPodのみがNodeに配置されるように制限できます。この仕組みを利用することで、以下を実現できます。

  • クラスタ全体を安定稼働させるためにシステムPodが動作するNodeを保護する（システムノードプール）
  • GPUなどの特殊なハードウェアを備えるNodeに配置されるPodを制限する
  • クラスタを共有するチームごとに利用するNodeを住み分ける

TaintsとTolorationの一致条件は「key」「operator」「value」の組み合わせで条件を定義します。operatorはExistsとEqualの2種類あります。Existsが指定されている場合は、keyがTaintsに存在しているかどうかを検査します。Equalが指定されている場合は、keyとvalueの組み合わせがTaintsに存在しているかどうかを検査します。

Taintsのeffectは、Podに設定されたTolorationが条件に一致しなかった場合に、そのPodをどのように扱うかを定義するものです。effectには、以下の3種類が存在します。

  • NoSchedule：TaintとTolerationが一致した場合にのみにPodをNodeに配置する
  • PreferNoSchedule：基本的にはNoScheduleと同じだが、Podの配置先がどこにもない場合はPodを受け入れる
  • NoExecute：基本的にはNoScheduleと同じだが、起動済みのPodにも影響し、条件に合わないPodはNodeから追い出される

運用環境では、「kube-system」や「gatekeeper-system」などにあるシステムPodを安定して動作させるため、システムPodのデプロイ先となるNodeと、ユーザーアプリケーションのデプロイ先となるNodeを分離することが推奨されています。この分離に使われるのもTaintsとTolorationです。

もともと「kube-system」や「gatekeeper-system」のPodには、CriticalAddonsOnlyというkeyのTolerationが設定されています。そのため、NodeにTaintとしてCriticalAddonsOnly付与することで、システムPod以外のPodがデプロイされないNodeにできます。