namespaceを本物の分離境界に変える:RBACとNetwork Policy

要点まとめ

• namespaceが引くのは名前の境界であり、セキュリティ境界ではありません。それ単体では、namespaceをまたいだAPIアクセスも、ネットワークトラフィックも、リソースの奪い合いも防げません。
• RBACは、namespace内のリソースを誰が操作できるかを制御します。デフォルトは拒否で、Roleを作成してバインドするまで誰もアクセスできません。
• NetworkPolicyは、何が何と通信できるかを制御します。ここでのKubernetesの挙動はRBACと正反対で、制限するポリシーを追加するまで、すべてのPodは他のすべてのPodに到達できます。
• ResourceQuotaとLimitRangeは、コンピュートとオブジェクト数の両面でnamespaceの消費量に上限を設け、1つのテナントがクラスタの残りやコントロールプレーンを枯渇させないようにします。
• これらはどれも最初から設定されていません。namespaceごとにすべて自分で追加しない限り、分離は存在しません。

一見すると、namespaceは分離そのもののように見えます。チームA用とチームB用にそれぞれ作成すれば、両チームのPod、Service、設定は別々の名前を持つ別々の入れ物に収まります。しかし境界はそこまでです。namespace自体には、チームAのサービスアカウントがチームBのSecretを読むこと、チームAのPodがチームBのデータベースへ接続を開くこと、チームAのワークロードが共有ノード上でチームBのPodのリソースを奪うことを防ぐ仕組みは何もありません。

Kubernetesのマルチテナンシーは、その名前の境界を実際のセキュリティ境界・リソース境界へと変える3つの仕組みの上に成り立っています。RBAC、NetworkPolicy、ResourceQuotaです。それぞれが異なる種類のアクセスを制御し、それぞれに、チームの想定を裏切りがちなデフォルト挙動があります。

RBAC:誰が操作できるかを制御する

RBACは、どのユーザー、グループ、サービスアカウントが、どのnamespaceのどのリソースに対して何をできるかを決めます。デフォルトの挙動は安全側に倒れています。Roleで権限を付与し、RoleBindingでそのRoleを割り当てるまで、サービスアカウントやユーザーの権限はゼロです。うっかり権限が漏れることはありません。

namespaceスコープのRoleは、その権限付与の影響範囲を1つのnamespaceに限定します:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: team-a
  name: team-a-editor
rules:
  - apiGroups: ["", "apps"]
    resources: ["pods", "deployments", "services"]
    verbs: ["get", "list", "watch", "create", "update", "patch"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: team-a-editor-binding
  namespace: team-a
subjects:
  - kind: Group
    name: team-a-engineers
    apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: team-a-editor
  apiGroup: rbac.authorization.k8s.io

次の3つの習慣を守れば、RBAC自体がリスクになるのを防げます。

個々のユーザーではなくグループにバインドする。特定のユーザーに紐づけたRoleBindingは、誰かがチームを異動した瞬間に陳腐化します。グループへのバインドなら、IDプロバイダー側のグループメンバーシップが変わると自動的に反映されます。

テナントの利便性のために付与されたClusterRoleBindingに注意する。クラスタ全体にバインドされたClusterRoleは、クラスタ上のすべてのnamespaceへのアクセスを与えてしまい、そもそもRoleをteam-aにスコープした意味がなくなります。ClusterRoleは本当に必要な場合にだけ使い、可能な限りnamespaceスコープのRoleBindingでバインドしましょう。

バインディングを定期的に見直す。RBACの無秩序な増殖(ほぼ重複したRoleが何十個も存在し、チームを去った人向けの古いバインディングが残ったままの状態)は、監査を数分ではなく数日がかりの作業にします。四半期ごとの棚卸しで、セキュリティインシデントになる前にドリフトを捕捉できます。

RBACは、namespace内で誰がKubernetes Secretsを読めるか、リソースのオーナーシップを管理できるかも決めるため、広すぎるRoleはコンピュートへのアクセス以上のものを晒します。また、RBACがリクエストをブロックした場合、Kubernetesは404ではなくForbiddenエラーを返します。これはクラスタのエラーをデバッグする際に知っておく価値のある違いです。

NetworkPolicy:何が何と通信できるかを制御する

RBACのデフォルトを反転させると、NetworkPolicyの初期状態になります。Kubernetesは標準でフラットなネットワーク構成になっており、何かがブロックしない限り、あらゆるPodはすべてのnamespaceをまたいで、クラスタ上のあらゆるPodへ接続を開けます。ブロックされるのはNetworkPolicyを追加して初めてです。それまでは、RBACでアクセスを厳格に制御していても、侵害されたPodがネットワーク経由でnamespaceの境界を越えるのを止めることはできません。

まずは、namespaceごとにデフォルト拒否のポリシーから始めます:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-all
  namespace: team-a
spec:
  podSelector: {}
  policyTypes:
    - Ingress
    - Egress

egressを拒否すると、DNSもブロックされます。CoreDNSは通常、kube-system namespaceのポート53で稼働しています。DNSにアクセスできないと、team-aのPodはサービス名を解決できず、DNSに依存するアプリケーションは失敗し始めます。 他のegressルールを追加する前に、DNSを許可しておきましょう: apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: allow-dns namespace: team-a spec: podSelector: {} policyTypes: - Egress egress: - to: - namespaceSelector: matchLabels: kubernetes.io/metadata.name: kube-system ports: - protocol: UDP port: 53 - protocol: TCP port: 53

そのうえで、実際に通信が必要なものだけを明示的に許可します。次の例では、同じnamespace内の他のPodからのトラフィックのみを許可します:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-same-namespace
  namespace: team-a
spec:
  podSelector: {}
  policyTypes:
    - Ingress
  ingress:
    - from:
        - namespaceSelector:
            matchLabels:
              kubernetes.io/metadata.name: team-a

経験したことのないチームほどはまりやすい落とし穴が1つあります。NetworkPolicyは、CNIプラグインが強制して初めて機能します。CalicoやCiliumをはじめいくつかのプラグインはNetworkPolicy APIを実装していますが、実装していないCNIプラグインも存在し、その場合、丹念に書いたポリシーはAPIサーバーには受理されるものの、ネットワーク層では黙って無視されます。NetworkPolicyを本物の境界として扱うのは、CNIがNetworkPolicyを強制することを確認してからにしてください。事後ではなく、事前の確認が必要です。

ResourceQuotaとLimitRange:namespaceの使用量に上限を設ける

RBACとNetworkPolicyはアクセスを止めます。ResourceQuotaは消費を止めます。クォータがなければ、1つのnamespaceがクラスタの残りに何も残らないほどのCPUとメモリを要求したり、クラスタ上のすべてのテナントにとってAPIサーバーが遅くなるほど大量のオブジェクトを作成したりできます。これはノイジーネイバー問題の背後にあるのと同じメカニズムです。

apiVersion: v1
kind: ResourceQuota
metadata:
  name: team-a-quota
  namespace: team-a
spec:
  hard:
    requests.cpu: "10"
    requests.memory: 20Gi
    limits.cpu: "20"
    limits.memory: 40Gi
    pods: "50"
    count/deployments.apps: "20"

最後の行は、その上にあるコンピュート制限と同じくらい重要です。コンピュートのみのクォータでは、namespaceはDeployment、ConfigMap、Serviceを無制限に作成でき、etcdを圧迫してクラスタ上の他のすべてのテナントのコントロールプレーンを遅くします。オブジェクト数に上限を設けることで、すべてのnamespaceが共有しているものを守れます。

クォータにはLimitRangeを組み合わせましょう。requestsとlimitsを自分で宣言しないPodが、即座に拒否されるのではなく妥当なデフォルト値を得られるようにし、さらにコンテナごとの上限を設定して、単一のPodがnamespaceの予算全体を占有できないようにします。数値を推測ではなく実際の使用量に合わせてサイジングする方法を含む詳しい仕組みは、ResourceQuotaとLimitRangeの専用ガイドを参照してください。