gistfile1.md

"Learn Kubernetes Security" の勉強会資料

Chapter 5 Configuring Kubernetes Security Boundaries

今日の範囲

• Security domainとSecurity boundaryの理解
• Security boundaryとTrust boundaryの区別とその重要性の理解
• KubernetesのSecurity domain
• KubernetesのSecurity boundary
• 関連するKubernetes/Linuxの機能理解
  • Pod Security Policy (K8s)→ will be deprecated
  • Linux Namespace (Linux)
  • Linux Capability (Linux)
  • Network Policy (K8s)

言葉の定義

Security domain

A security domain is the determining factor in the classification of an enclave of servers/computers. A network with a different security domain is kept separate from other networks.

cf Wikipedia

• determine: 判断する
• enclave: 領域
• classification: 区別

= アクセスレベルが同じEntityの要素　

Security boundary

A security boundary is the line of intersection between any two areas, subnets, or environments that have different security requirements or needs. A security boundary exists between a high-security area and a low-security one, such as between a LAN and the Internet.

cf Oreilly CISSP

• boundary: 境界線
• intersection: 交差点

= Security domainの境界線（囲い)

System, Data, Networkが重要なLayer(compute, access, and storageとも言える)

例

• System layer
  • Tradition
    • Hypervisor
  • Microservice
    • Container
• Network layer
  • Tradition
    • Firewall
  • Microservice
    • Network policy(Pod/Namespace/Cluster)
• Data Layer
  • Tradition
    • system dataへのアクセスをroot/system userに対してのみkernelは許可
  • Microservice
    • chrootでcontainer のファイルアクセス権限を独立させる

k8s securityにおいて重要なこと

containerはhypervisorほど強いsecurity boundaryを持っていない。

Trust boundary

A boundary where program data or execution changes its level of "trust," or where two principals with different capabilities exchange data or commands.

　cf: wikipedia

• principal : プリンシパル

プログラムの実行やデータ変更の権限（信頼レベル）を変更する境界線

なぜ、Security boundary, Trust boundaryの理解が重要か？ 適切なvalidationなしに、boundaryを超えると大変なことが起こるから

KubernetesのSecurity domain

注意が必要なのは、Kubernetes上で動かされるアプリケーションやシステムから取り出されるSecurity domainは別途話す必要があるが、ここではKubernetesそのもののSecurity domain をみる。

components

• k8s master component
  • kube-apiserver
  • etcd
  • kube-controller manager
  • DNS server
  • kube-scheduler
• k8s worker component
  • kube let
  • kube proxy

objects

• k8s object
  • pods
  • service
  • volume
  • namespace

Kubernetes entities as security boundaries

Kubernetes entities(object + component)にbuilt inされているsecurity boundaries

entities

• container
• pods
• nodes
• cluster
• namespaces
• k8s api server

objects

• replicasetの繋がりは間違っているので注意
• 青色がロジカル、緑がフィジカル

Actors

• end user
  • 進入：ingress, expose service, open port of node
  • 守る: node, pod, k8s api, firewall
• internal attacker
  • 進入: pods, containerへのアクセス
  • 守る:
    • kube-apiserverでprivilege のエスカレーションやclusterへの進入を防ぐ
    • network policy, RBACでlateral movementを防ぐ
• privilege attacker
  • kube-apiserverに入られたら負け

Trust boundariesとして見ると？

参照: Kubernetes Threat Model

Security Boundaries in Kubernetes

K8Sにおける、Security boundariesをsystem(ビルトイン）とnetwork layerでみていく。

System Layer

前提として重要なことはコンテナーはLinux namespaceで管理されてるプロセスです。

boundaries

• Linux namespace
  • podはnamespaceをnetwork, PID namespaceで分けてくれている、お互いはお互いを見られない
  • default のsettingはよい！
  • しかし
    • hostNetowkr, hostIPC, hostPID, sharedProcessBNamespace
    • 参照: Microsoft attacker matrics
• Linux capability
  • https://gihyo.jp/admin/serial/01/linux_containers/0042
  • 一般ユーザーに特権を与える、そのケイパビリティの定義
  • container内から、tcpdumpしても、対象のcontainer の通信しか見られない

権限を追加可能

- namespaceもlinux capも両方とも追加可能
    - 例えば、monitoringしたいときなどに

対策

- pod security policyを使う
- 廃止されるけど

Network Layer

同クラスター内でPod間の通信はデフォルトで制限されていない。

Network policyで制限をかけられる

network policy

• pod selector ルールを適用する対象のpod
• ingress
  • 外部サービスの場合
    • ip blocks
  • 内部は
    • namespace selector
    • pod selector
  • ports

    apiVersion: networking.k8s.io/v1
    kind: NetworkPolicy
    metadata:
      name: test-network-policy
      namespace: default
    spec:
      podSelector:
        matchLabels:
          role: db
      policyTypes:
      - Ingress
      - Egress
      ingress:
      - from:
        - ipBlock:
            cidr: 172.17.0.0/16
            except:
            - 172.17.1.0/24
        - namespaceSelector:
            matchLabels:
              project: myproject
        - podSelector:
            matchLabels:
              role: frontend
        ports:
        - protocol: TCP
          port: 6379
      egress:
      - to:
        - ipBlock:
            cidr: 10.0.0.0/24
        ports:
        - protocol: TCP
          port: 5978

    apiVersion: networking.k8s.io/v1
    kind: NetworkPolicy
    metadata:
      name: allow-good
    spec:
      podSelector:
        matchLabels:
          app: web
      policyTypes:
      - Ingress
      ingress:
      - from:
        - namespaceSelector:
            matchLabels:
              from: good
          podSelector:
            matchLabels:
              from: good

他

どうなるPSP? 議論されているオプション

SysdigにNetwork Policyの可視化と作成補助ツール

多層防御とZero Trust?

Kubernetesの上下へ範囲を広げると？