kubernetes

Kubernetes Meetup Tokyo #10レポート

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

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

概要

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等)を用意できる。

  1. ServiceInstance作成 -> リソース(DB等)が作成される
  2. 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

今後使える新機能

Debug Containers
kubectl debugでデバッグコンテナが使える

LT 『入門Kubernetes』の紹介

by @dblmkt

自身が翻訳した入門Kubernetesの書籍の紹介。
トピックとしては1.9までの情報を追加している。

LT 猫でもわかる Pod Preemption

by @y_taka_23

Podをノードに振り分ける時、キャパシティ不足になった。

  • Priorityを高いものを配置する時、低いものを落として高いものを配置する

意義について 

  • 今までは積極的にPodを追い出す方法がなかった。
  • ノードがスケールしない環境がある。
  • ノードのスケールには時間がかかる
  • コストが予測可能になる

仕組み

  • 配置しようとするPodのプライオリティより低い物を選ぶ
  • Nodeに順位付けして配置

ただしAffinityの指定が問題になるので、注意する。

LT Amazon Container Services

by @riywo

Amazon Container Servicesの信条

  1. エンタープライズのワークロードを動かす
  2. UpstreamのK8s
  3. AWSサービスとの連携
  4. コントリビュート

他AWSサービスと連携できる。

例えば

  • kubectlのクレデンシャルにIAMが使える
  • EFSをPersistentVolumeで使える
  • IngressでALBで使える。Route53連携もできる。

LT other ingress voyager

by @gavinzhm

voyagerはAppCodeが開発しているIngress

  • Ingressが一つで済む
  • Lets Encryptが使いやすい
  • ワイルドカード証明書対応
  • ネームスペース超えができる
  • ドキュメントクオリティーが高い
  • issue対応が早い (5分でレスポンスが帰ってきたことも)
  • …等

LT DockerでHelmを使おう

by @ShoutaYoshikai

ローカル / 開発でHelmを使うと色々便利
しかしhelmでは設定できない項目があったりする。

helmみんなも使っていこうぜ。