鳩小屋

落書き帳

クラウドKubernetesのセキュリティ

今回はクラウドKubernetesサービス(別名フルマネージドKubernetes)は、通常のKubernetesよりも構築運用の負担が少なく、使い勝手のいいコンテナオーケストレータです。今回はクラウドKubernetesのセキュリティについてです。

責任共有モデル

f:id:FallenPigeon:20210630222756j:plain
f:id:FallenPigeon:20210630222814j:plain

上記はAmazon Elastic Kubernetes Serviceの責任共有モデルです。
Kubernetesはコンテナが動作するNodeとそれらを集中制御するMasterで構成されています。
フルマネージドKubernetesでは、Master側のインフラからサービスまでほぼすべてがクラウドベンダの管轄となります。
そのため、ファイルパーミッションやサービスのオプション指定などはクラウドベンダの責任範囲となり、ユーザ側のセキュリティ範囲は限定されます。ただし、すべてがクラウドベンダ側の責任というわけではなく、ネットワーク設定やユーザアクセス制御など、ユーザに委ねられている設定に関しては、ユーザが責任を負うことになります。また、フルマネージドKubernetesでは、IaaSやサーバレスコンテナなど、Nodeに複数の選択肢があり、構成に応じた責任範囲を理解する必要があります。

Self Managed Workers

OS以上のレイヤがすべてユーザの責任範囲となるため、kubeletからコンテナまですべてが対象。
自由度の高い選択肢であるものの、kubeletやコンテナランタイムも責任範囲となるため、ユーザ側の対策事項が多くなります。
kubeletの要塞化はそれなりに複雑なので、理解が怪しい場合は、EKS FargateやMangaed Node Groupsを選択した方が安心かもしれません。

Mangaed Node Groups

OS、kubelet、コンテナランタイムはAWS側で管理されます。OSにはアクセスできるものの、変更は自由に行えないため、IaaSよりも自由度が下がります。
ただ、要塞化にコストのかかるOS、kubelet、コンテナランタイムがベンダ管轄となります。アンチウィルス製品が対応していないなどの問題が出てきますが、OSレイヤの設定ミスによる感染リスクが大きく軽減できることを考慮すればそれほど大きな問題ではないかもしれません。

EKS Fargate

コンテナランタイムやkubeletはAWS側で管理されるため、ユーザのインフラ管理はコンテナ本体のみとなります。
Nodeについてはコンテナ本体のみを考慮すれば良いため、負担は最も少なくなります。ただ、OSの操作権限がほとんどないため、コンテナ外でソフトウェアを動作させることはできません。コンテナランタイムの機能でコンテナを参照することもできないため、小回りが利かなくなり煩わしく感じることもあります。

セキュリティ考慮

ユーザアクセス制御

Kubernetesには、ロール ベース アクセス制御 (RBAC)の機能があり、認証されていないユーザによるアクセスを制限することが可能です。また、EKSやAKSではIAMのようなクラウド固有のRBACが用意されており、KubernetesのRBACと統合されています。基本的には、従来の機能を利用するだけでも十分なアクセス制御が実現できますが、クラウドネイティブな機能であるため、他のクラウドサービスと親和性が高いという利点があります。ただ、KubernetesのRBAC単体でもそれなりにややこしいので両方利用すると何が何やら状態に陥ります。

ネットワーク

Kubernetesシステムでは、コンテナ単体のバインドポート、コンテナノードの解放ポート、コンテナの論理集合であるポッド単位のネットワークポリシーがネットワークフィルタリングとして機能します。特に、ネットワークポリシーはKubernetes固有の仕組みになります。IPアドレスが動的に変化する問題をネットワークポリシーが解決してくれます。

インフラ

コンテナを実行するOSの要塞化がメインになります。特にコンテナを動作させるのに最低限の機能のみを提供するマシンイメージも存在します。 例例としてはCoreOSやBottlerocketが該当します。これらをIaaSで利用することでOSへの操作性を維持したまま強固なコンテナインフラを運用することができます。コンテナ以外でアプリケーションを動かす予定がない場合は選択肢に入るかと思います。

Kubernetes masterコンポーネント

Kubernetesのmasterノードは、api server、etcd、scheduler等のサービス群で構成されています。それらのほとんどがベンダ管轄となるため、ユーザはほとんどセキュリティを考慮する必要がありません。ただし、これらの一部はユーザに操作機能が提供されているため、その範囲内で適切に制御する必要があります。例として、api serverのエンドポイント設定、マスターノードのロギング設定、管理データの暗号化機能などがあります。

ポッド

コンテナ本体のセキュリティ設定は、コンテナの設定が記載されたポッド構成ファイル、ポッド構成ファイルの設定を強制するポッドセキュリティポリシが該当します。これらのファイルには、コンテナの公開ポート、特権コンテナ、権限昇格、ホストOSのユーザバインドのような実行コンテナに適用されるセキュリティ設定が集約されています。そのため、これさえ覚えておけば、コンテナ本体のセキュリティの半分ぐらいはカバーできると言っても過言ではありません。
ちなみに通常のKubernetesでは、デフォルトのポリシが存在しませんが、EKSのポッドセキュリティポリシは特権ポリシがデフォルトで割り当てられます。そのため、ノーガード状態と同じ状態となります。これは、ポッドセキュリティポリシを有効化する機能自体がMasterノードの機能としてロックされているため、機能を提供しながらユーザにMasterノードを操作させないための仕様と思われます。一方、Azure側では、後述するGatekeeperベースのAzure Policyが推奨されている印象です。
その他の機能には、ReplicaSetのような冗長性を維持する機能もKubernetesで提供されています。

apiVersion: policy/v1beta1
kind: PodSecurityPolicy
metadata:
  name: eks.privileged
  annotations:
    kubernetes.io/description: 'privileged allows full unrestricted access to
      pod features, as if the PodSecurityPolicy controller was not enabled.'
    seccomp.security.alpha.kubernetes.io/allowedProfileNames: '*'
  labels:
    kubernetes.io/cluster-service: "true"
    eks.amazonaws.com/component: pod-security-policy
spec:
  privileged: true
  allowPrivilegeEscalation: true
  allowedCapabilities:
  - '*'
  volumes:
  - '*'
  hostNetwork: true
  hostPorts:
  - min: 0
    max: 65535
  hostIPC: true
  hostPID: true
  runAsUser:
    rule: 'RunAsAny'
  seLinux:
    rule: 'RunAsAny'
  supplementalGroups:
    rule: 'RunAsAny'
  fsGroup:
    rule: 'RunAsAny'
  readOnlyRootFilesystem: false

アドミッションコントロール

先ほど紹介したポッドセキュリティポリシですが、実は非推奨化が決定しています。もともと設計がよろしくなかったようで廃止されるようです。ただし、代替機能も開発が進んでいるらしく、それほど心配する必要はないのかもしれません。
それまでの乗り換え先候補となるのがアドミッションコントロールという機能になります。
Kubernetesでは、コンテナの操作はapi serverを経由して行われます。このapi serverでapiリクエストを実行する前に先程紹介したRBAC、ポッドセキュリティポリシ、さらにアドミッションコントロールによるアクセス制御が実行されます。イメージとしては現場猫3人がコンテナノードの門番をしているような状態となります。

f:id:FallenPigeon:20210701002327j:plain

このアドミッションコントロールがなんなのかというと主にwebhookの機能を利用して様々なチェック処理を走らせることができます。例えば、デプロイ寸前のコンテイメージの脆弱性診断を実施したり、実装次第ではポッドセキュリティポリシ以上の機能を提供することができます。ただ、実装にはそれなりの知識が求められるため、敷居の高い機能となっています。
そこで頼りになるのがGatekeeperというテンプレートアドミッションコントロールとなります。従来であれば一から実装すべき機能をフレームワークとして提供しており、ポッドセキュリティポリシの上位互換機能を組み込むことができます。EKSではagentをポッドとして容易にデプロイすることができます。AKSではAzure Policyという機能に統合されており、直接操作はできませんが、間接的にこの機能を利用することが可能です。

参考

フルマネージドKubernetesのセキュリティはベンダが提供するベストプラクティスやCIS benchmarkが参考になります。
基本はKubernetesの対策がメインですが、クラウドサービス固有の機能や責任共有モデルが絡んでくるため、自由度とセキュリティを天秤にかけながらアーキテクチャを決定し、セキュリティを担保するとよいでしょう。

f:id:FallenPigeon:20210701004050p:plain
aws.amazon.com
aws.github.io