１クール続けるブログ

とりあえず１クール続けるソフトウェアエンジニアの備忘録

【AWS Re:Inventレポート】CON334-R1 - [REPEAT 1] Running high-security workloads on Amazon EKS

Running high-security workloads on Amazon EKS

5日目にして初めてセッションに参加しました。
セッション参加して思ったこととしては、まず前を取ることが重要だなと感じました。英語読むスピードはどうしても日本語より遅くなってしまうので、追いきれないと思ったスライドは写真に収めてしまうのが吉ですね。動画見ていても思うことではあるのですが、画面読んでると話聞けなくなるし、聞いてると画面読めないという板挟みにあいます。どうすれば…？
もちろん救いもあります。スライドと口頭の説明だけかと思いきや、デモとかもあって割と分かりやすいです。
あと、事前知識がまったくない分野の話になると、英語がまったくわからなくなります。今回のケースだと、SELinuxが全然分かりませんでした。「SELInuxわかんないのかよ。インフラエンジニアの癖に。」という石を投げるのはやめてください。

セッションの概要

Amazon EKSのセキュリティについてのお話です。Amazon EKSはKubernetes API層/Container Runttime Operating system層/AWS層というレイヤーで構築されていると思いますが、前者2つをセキュリティ性高くしていくにはどのようにすべきかという内容でした。

セッションの内容

（このパートは動画見た後に直すかもです）
最初にセキュリティを考える上での基礎に触れていたように思います。例えばCIAA modelだとかThe actor and capablities modelについてです。
EKSに対してどんな攻撃方法があるか？例えばL7での攻撃（XSS等）だとか、containerdやruncなどのオープンソースに潜んでいるバグを利用するもの、DDoS攻撃などが考えられます。

一つ例を挙げてみます。例えば、とあるブログの記事で見つけたyamlを適用したら、マルウェアが含まれていたケース。これはごく稀にあるかもしれないと思ってしまいますよね。curlで落としてきたマニフェストを確認せずにapplyしてしまったりとか。マルウェアは自分たちのシステムにアクセスできてしまうし、関連しているAWSのマネージド・サービス、例えばRDSなんかもそうです。

そういった驚異からの影響をどう小さくしていくか、緩和していくか
EKSの構造を Kubernetes API -> Container Runtime -> AWSの3層構造と考える

Kubernetes API層

  • namespaces
  • ServiceAccounts
    • これはかなり効くと思っています。特に上であげた例のようなケースだと。
    • serviceAccountNameをマニフェストに追記することになるので、権限をかなり意識するようになる。
  • ResouseQuota/LimitRange
    • リソースをガンガン食いまくる系のマルウェアだった場合に制限がかけられる
  • NetWorkPolicy
  • RBAC
  • Dynamic Admission Webhooks
    • Mutableの方ではなく、おそらくvalidatingの方を使っての制限と思う
    • Admission Webhooksを使うとnamespaceとかも確認しつつ制限かけられるのは柔軟で良さそう
  • API AuditLogs
  • Pod Security Policies

PodSecurityPoliciesは下記のようなサンプルとともに深堀りされていました。確かにかなり効果的な制限が出来るようです。 これはClusterリソースでPodが作成・更新されるときにシステムに受け入れられるように必要な条件を定義できるものだそうです。

apiVersion: policy/v1beta1
kind: PodSecurityPolicy
metadata:
  name: restricted
spec:
  privileged: false # 
  allowPrivilegeEscalation: false
  requireDropCapabilities: ['all']
  volumes: ['configMap', 'secret', 'projected']
  hostNetwork: false
  hostIPC: false
  hostPID: false

詳しくはこちら

kubernetes.io

Security Contextでシステムコールを制限できる。単純にprivillagedを使うんでなくSecurityContext使って極力権限を絞っていくと良い。

kubernetes.io

Container Runttime Operating system

SELInux勉強不足であまり理解出来なかったので、勉強しつつ動画みれるようになったら補足して書きます。

感想

セッションもかなり学びがあると思いました。もちろん動画公開もあるので、なんとも言えないのですが…。
これにてAWS Re:Inventは終わりでした！学習型カンファレンスと言われているように多くの学びがありました。反省点としては英語の能力が書けていたこと、同じ分野のワークショップを取り続けてしまったことでしょうか。
初めてのアメリカ、（ほぼ）はじめての海外旅行なので、色々戸惑った点などあったのですが、それはまた別で記事にしようと思います。