Kubernetes Meetup Tokyo #10レポート #kubernetes

内容の正当性は保証できません。こういう雰囲気でした。

スライドとか公開されたら更新します。

概要

Kubernetes Meetup Tokyo #10
日時: 2018年3月8日19時から
URL: https://k8sjp.connpass.com/event/76816/

Open Service Broker APIとKubernetes Service Catalog

by Toshiaki Maki (@making) (Pivotal)

データベースをどこにだれが作成していますか？

よくある例: 開発者がDBが必要な時にDBAに依頼 (DB作成、ユーザ作成)。

Service Brokerを使えば、DBの作成・構築・設定まで自動で行える。

Service Brokerを使うにはOpen Service Broker APIを使う。
これはもともとはCloud Foundryのサービスだった。

KubernetesではService Catalogを経由してService Brokerを使う。

Service Brokerによって作成される機密情報はSecretに入れてくれる・

helmでインストールできる。

ブローカーが構築済みであれば、開発者は下記手順を踏むことでリソース(DB等)を用意できる。

ServiceInstance作成 -> リソース（DB等）が作成される
ServiceBinding作成 -> パスワード等がシークレットにセットされる

Kubernetesセキュリティベストプラクティス

by Ian Lewis (Google)

Guestbookアプリを例にベストプラクティスを紹介。

フロントはHTML/CSS/JS
メッセージが保存・閲覧できる
NGワード検出機能がある
よくあるマイクロサービス

Kubernetes API Serverについて

シナリオ: フロントエンドPodからトークン取得、APIサーバを攻撃、シークレットを取得しさらに攻撃

Podにはトークンがマウントされているので、Podに侵入されるとトークンが抜かれるおそれがある。
トークンを使ってAPIサーバにアクセスすればシークレット（パスワード等)が抜かれる。

改善策1: RBACを使おう

例えばWebサーバはAPIサーバにアクセスする必要が無いので、アクセス出来ないようRBACを設定する。
GKEだとIAMと連携でき、管理が楽。

改善策2: APIサーバにファイアウォールを設定しよう

APIサーバへのアクセスをIPアドレスに制限
gcloud container clusters create --enable-master-authorized-networks --master-authorized-networks=...
https://cloud.google.com/sdk/gcloud/reference/container/clusters/create

改善策3: ネットワークポリシーを設定しよう

データベースへのアクセスを必要なPodに制限したりする。
networkpolicyのpodSelectorを使う。iptablesが設定される。

ホストについて

シナリオ: コンテナを突破され、ホスト上で色々される。

Podはサンドボックスで実行されるのでrootで動いていても通常問題ないが、コンテナを突破されるとホストにrootで入られてしまう。

改善策1: non-rootで実行

podのrunAsUserを使う。

改善策2: 読み込み専用ファイルシステム

podのreadOnlyRootFilesystemを使う。

改善策3: no_new_privs

podのallowPrivilegeEscalationを使う。
コンテナを実行する時、フォークする時自分以上の権限を与えない。

その他改善策:

seccomp, AppArmor, SELinuxを使う。または組み合わせる。

おすすめはruntimeのdefaultを使う。

その他改善策2: kubeletの権限を制限する

できるだけkubeletに必要な権限だけ与える。

--authorization-node=RBAC,Node
--admission-control=...,NodeRestriction

kubeletの証明書をローテーションする
kublet... --rotate-certificates

短い期間でローテーションすれば盗まれても有効期間が限られる。

Unsecured Pods

シナリオ: 同じクラスタ内にセキュリティが甘いPodがある場合がある。そこから色々されてしまう。

改善策1: PodSecurityPolicyを使う

トラフィック傍受

シナリオ: ネットワークトラフィクを傍受され、サービス拒否攻撃等をされる。

改善策1: istioを使う

サービス間のプロキシ
暗号化
証明書の自動更新
ポリシーの集中管理

Debugging Applications in Kubernetes

by Takashi Kusumi (Z Lab)

問題点

PodやServiceにクラスタ外からアクセスできない（負荷試験など）
コンテナにデバッグツールがはいってない（tcpdumpとか)

kubectlでの基本

使えるサブコマンド

run
- -itでインタラクティブに操作できる
- クラスタ内からPodやServiceにアクセスしたい時に最適
- --rmと--restart=Neverをつけよう
- --serviceaccountオプションを使うとServiceAccount権限周りのデバッグに便利。この時googlのhyperkubeイメージを使うと便利。
- --overridesオプションを使うと、JSONの上書きができる。runでは設定できないフィールドも設定できる。
logs
- --sinceで時間を指定できる
- --timestampでタイムスタンプを表示できる
- wercker/sternというツールを使うと複数のログを一度に見れて便利
exec
- コンテナ内で任意のコマンドを実行
port-forward
- ポートフォワード
- ローカルにListenしてるものにも使える
cp
top
- ノードとPodのCPU/メモリ使用率がわかる

PodとLinux名前空間

Podで共有されるのは

IPC
- シグナルとか送れる
- pauseというコンテナが共有する舐め空間を保持している
- scratchのイメージだとシェル入ってない
  - /proc/[pid]/rootでそのPIDがマウントしているルートがみれる
  - kubectl get podsしてノードを確認
  - --overridesでdockerを起動
  - docker run --pidを使う
  - マウントしているディレクトリを覗ける
  - scratch-debuggerツールを使う
Network