2023 年の振り返り

はじめに

2023 年の振り返りです。

お仕事とか

インプット

2022 年の振り返りでも書いたのですが、友人と O'Reilly の課題図書を決めて読む取り組みは継続して行うことができました。去年と比べて一緒に本を読んでくれる人が増えたのも嬉しいことです。今年はこんな本を読みました。

アウトプット

去年は自分のブログによるアウトプットが主でしたが、今年は外部での登壇や各種メディア記事への寄稿も実施しました。こういう機会を持ってきてくれる縁に感謝です。

まだ諸事情で公開できないのですが、この他にいくつか他メディアで公開予定の記事も控えていたりします。

プライベート

あまり公には言っていなかったのですが、10/24 に入籍をしていました！これが今年一番の報告事項です。

2022 年の振り返り

はじめに

2022 年の振り返り＆ちょっとした新年の抱負です。

お仕事、etc.

インプット

丁度今年の 3 月でしょうか？友人と O'REILLY の課題図書を決めて毎週木曜日の夜に輪読会を始めました。1 章を 1 週間でそれなりにきちんと読んでいくので毎回時間はかかりますが、確実に身になっている気がするので良い取り組みだと思っています。今年は、読みかけのものも含まれていますが、こんな本を読みました。

取り組みに Join したい方は是非私に声をかけてください！

アウトプット

アウトプットは例年とあまり変わらずで、ブログによるアウトプットが主なものでした。一応、こんな記事を書いています。

はてなブログで、SPIFFE の仕様を全部読んでいくシリーズをやろうと思いましたが、道半ば挫折しました。中途半端な状態で残っているので、2023 年に残りのコンテンツをやらなければ...

また、ありがたいことに外部のイベントにスピーカーとして呼んでいただけることもありました。

コミュニティ活動

今年は、新しくコミュニティ活動も始めて、CloudNative Days 実行委員の Observability チームに Join しています。来年は面白そうなイベントも企画されているので、もっと積極的に関わっていければな、と思っています。

プライベート

麻雀以外のゲームをほとんどやらない僕ですが、今年は GW 明け頃からマリオカート 8dx にドはまりしていました。是非、皆さん一緒にやりましょう。

SPIFFE 仕様全部読んでく - JWT-SVID

spiffe tech

SPIFFE に個人的に興味を持ち始めたので、https://github.com/spiffe/spiffe/blob/main/standards/ にある仕様を全部読んで簡単にまとめてく。今回は、JWT-SVID についてです。 尚、学習中であるため解釈が間違っている可能性は存分にあります。

ざっくりまとめ

原文: JWT-SVID

Schema は、ここを見るとよい: https://github.com/spiffe/spiffe/blob/main/standards/JWT-SVID.schema

Introduction

JOSE Header

以下に記載のないヘッダーはいかなる場合も JWT-SVID JOSE Header に含めてはいけない。

  • MUST
    • alg(Algorithm)
      • 以下、参照
  • OPTIONAL
    • kid(Key ID)
    • typ(Type)
      • JWT or JOSE

alg でサポートされているアルゴリズムは以下の通り

alg Param Value Digital Signature Algorithm
RS256 RSASSA-PKCS1-v1_5 using SHA-256
RS384 RSASSA-PKCS1-v1_5 using SHA-384
RS512 RSASSA-PKCS1-v1_5 using SHA-512
ES256 ECDSA using P-256 and SHA-256
ES384 ECDSA using P-384 and SHA-384
ES512 ECDSA using P-521 and SHA-512
PS256 RSASSA-PSS using SHA-256 and MGF1 with SHA-256
PS384 RSASSA-PSS using SHA-384 and MGF1 with SHA-384
PS512 RSASSA-PSS using SHA-512 and MGF1 with SHA-512

JWT Claims

  • RFC 7519 で定義された claim にいくつか制限を加えている（新しい claim は追加されていない）

    • 実装のために、新しい claim を追加しても良いが、相互運用性に影響を与える可能性には考慮する

  • MUST

    • sub(Subject)
    • aud(Audience)
    • exp(Expiration Time)

Token Signing and Validation

Token Transmission

  • Serialize は、JWS Compact Serialization を必ず使用すること
  • HTTP でトークンを送信する場合には、Bearer スキームを使用し、Authorization ヘッダーで送信するべき
  • gRPC でトークンを送信する場合には、メタデータキー authorization に Bearer <serialized_token> を設定するべき

Representation in the SPIFFE Bundle

  • JWT-SVID の署名鍵は、JWK として表現される
  • MUST
    • use
      • jwt-svid
    • kid

Security Considerations

  • JWT-SVID を使用する際のセキュリティ上の考慮点
    • リプレイ攻撃からの保護
      • exp は短めに設定する
      • jti を使用する
    • 複数の aud を持つ場合
      • Bearer トークンという性質上、audience の範囲を必要以上に広げることは十分注意する必要がある
      • 原則は、単一 audience を持つ JWT-SVID を運用することが強く推奨されている
    • Transporting の際に発生するセキュリティリスク
      • 他の Bearer トークンと同様に傍受された際には、攻撃者に対して権限を与えてしまうことになる
        • 基本的には、JWT-SVID が伝送される全ての経路は機密性を提供するべき

SPIFFE 仕様全部読んでく - SPIFFE ID

tech spiffe

SPIFFE に個人的に興味を持ち始めたので、https://github.com/spiffe/spiffe/blob/main/standards/ にある仕様を全部読んで簡単にまとめてく。今回は、SPIFFE-ID についてです。 尚、学習中であるため解釈が間違っている可能性は存分にあります。

ざっくりまとめ

原文: https://github.com/spiffe/spiffe/blob/main/standards/SPIFFE-ID.md

SPIFFE ID

  • SPIFFE ID
    • RFC 3986 準拠の URI として定義
    • spiffe://trust-domain/path

trust-domain

  • SPIFFE を実行する個人、組織、環境、部門等を示す
    • ※パブリック DNS のようにどこか公な場に登録するようなものではない
  • trust-domain 名の制限
    • 空文字であってはならない
    • 小文字でなければならない
    • a-z0-9.- で構成されなければならない
    • パーセントエンコードされた文字を使ってはいけない
      • i.e. URI として使用できない文字は使用してはいけない
    • IPv4 形式のアドレスは ↑ の制約を満たすが、IPv6 形式のアドレスでは制約を満たさない
      • DNS 名であれば、完全に満たす
  • trust-domain は自由に選択することができるが、規約や登録を行うための中央集権的な機関は存在しない
    • i.e. グローバルに一意であることは全く保証できない
    • 偶発的な衝突を避けるために、グローバルユニークな可能性が高いものを trust-domain として選択することが推奨されている（DNS 名など）
    • trust-domain 名を自動生成する場合は、グローバルに衝突しにくいような UUID 等を用いることが強く推奨されている
    • 衝突が発生した場合は、独立して動作し続けることが可能だが、フェデレート（相互接続）は行うことができない

path

  • path の制限
    • パーセントエンコードされた文字を使ってはいけない
    • パスのコンポーネントには、空のセグメントや相対パスの修飾子（., ..）を使ってはいけない
    • 末尾に / を含んではいけない
    • 個々のパスセグメントは a-z0-9.- で構成されなければならない
    • パスは階層表現してよい
      • 具体的な階層の仕様に関しては、実装者に委ねられる（Istio の場合は、Service Account で埋めている）
  • パスの例
    • サービスを指定する
      • spiffe://staging.example.com/payments/mysql, spiffe://staging.example.com/payments/web-fe
    • サービスの所有者を指定する
      • spiffe://k8s-west.example.com/ns/staging/sa/default
    • 不透明な情報でパスを埋める
      • これが最も一般的な模様
      • spiffe://example.com/9eebccd2-12bf-40a6-b262-65fe0487d453

Maximum SPIFFE ID Length

  • RFC 3986 で定義されているように、URI には長さの制限がない
  • SPIFFE では、相互運用性を考慮しこの長さを 2048 バイトまでに制限している
    • ただし、推奨最大長なので一応これを超過することも可能
  • trust-domain の最大長は 255 バイト
    • これは、RFC 3986 の host 部の最大長で定義がされている

SPIFFE ID Parsing

  • RFC 3986 に従ってパースされる
    • スキーム（spiffe）と trust-domain は大文字と小文字を区別しないが、パスは区別される

SVID(SPIFFE Verifiable Identity Document)

  • SVID
    • ワークロードが SPIFFE ID を呼びだし元／先と通信する仕組み
    • trust-domain 内の CA によって署名された場合、その ID を有効とみなす

SVID Trust

  • 署名機関は、trust-domain 内に存在しなければならず、自身の SVID を有さなければならない
    • 署名機関自身の SPIFFE ID は trust-domain に存在するべきで、パスコンポーネントを持つべきではない
    • 必要に応じて、外部の trust-domain の秘密鍵で署名することもできるが、基本的には自己署名

SVID Components

  • 3 つの要素から構成される
    • SPIFFE ID
    • 有効な署名
    • （オプション）公開鍵
  • SPIFFE ID と（オプション）公開鍵は、署名される Payload の一部に含めなければならない
  • SVID 内には上記の情報以外を含めてもよい
    • JWT-SVID とかはその典型例

SVID Format

  • (2022/07 現在)サポートされているドキュメントタイプ
    • X.509
    • JWT
  • 詳細は、別記事で

Security Considerations

SVID Assertions

Temporal Accuracy

  • SVID は、鍵の漏洩とそれに伴う損害を軽減することを目的として、限られた時間だけ有効なものとなっている
    • アサーションは発行時に真であることが多いが、使用時には必ずしもそうとは限らない
    • 変更される可能性が高い情報
      • SA, Role, Member of group, Access Policy, etc.
    • 変更される可能性が低い情報(i.e. 時間的精度の問題の影響を受けづらい)
      • SPIFFE ID, Region, etc.
  • どのような情報を含めるか？を検討する際は上記のようなことを考慮することが重要

Scope and Influence

  • SVID は、それが存在する trust-domain 内の署名機関によって署名される
    • i.e. SVID の情報全てを検証するのは、署名機関の責任
  • アサーションの有効範囲は、trust-domain に閉じるべき
    • e.g. ある trust-domain A で "admin" というロールを持つエンティティを他の trust-domain B で "admin" として扱うべきではない、etc.

Interpretation

  • 柔軟性を持たせるために SVID 仕様は、任意の情報を含めることを許可している
    • 任意の情報を含めたとしても原則は、意味が合意された trust-domain に限定するべき

Veracity

  • 同じ trust-domain 内で発行された SVID に含まれるアサーション -> 真実であると仮定できる
  • 別の trust-domain で発行された SVID に含まれるアサーション -> 真実だと仮定することに意味なし

SPIFFE 仕様全部読んでく - 全体概要

tech spiffe

SPIFFE に個人的に興味を持ち始めたので、https://github.com/spiffe/spiffe/blob/main/standards/ にある仕様を全部読んで簡単にまとめてく。 尚、学習中であるため解釈が間違っている可能性は存分にあります。

ざっくりまとめた各仕様のリンク先

TODO

ざっくりまとめ

原文: https://github.com/spiffe/spiffe/blob/main/standards/SPIFFE.md

  • SPIFFE を構築する 3 つの主要コンポーネント
    • identity namespace の標準化: SPIFFE ID
    • 発行された ID の提示と検証の方法: SPIFFE Verifiable Identity Document(SVID)
    • ID の取得、発行のための API を規定: Workload API

SPIFFE ID

  • ワークロードを識別するための ID の形式を規定している
    • URI 形式（RFC3986）で表現される
    • spiffe://trust-domain/path
      • trust-domain
        • ID の発行者を示す
        • e.g. cluster.local
      • path
        • trust-domain 内のワークロードを識別するためのパス
        • Istio では、ワークロードが実行される Service Account を使ってパスを決定している模様
        • e.g. ns/hoge/sa/fuga

SVID(SPIFFE Verifiable Identity Document)

  • SPIFFE ID 搭載した検証可能なドキュメントのこと
  • X.509 or （JWS 形式の）JWT で表現される
    • X.509-SVID
    • JWT-SVID
  • 各詳細は、別のまとめを参照

Workload API

  • 大別すると以下の 2 つの API から成り立つ
    • SVID(SPIFFE Verifiable Identity Document)を提供する API
    • CA bundle を提供する API

Kubernetes 認定資格(CKA)でよく使いそうなコマンド等のメモ

tech

はじめに

2021 年の年末から Kubernetes 認定資格（CKA）のお勉強を本格的に開始しました。この記事は、資格対策講座で勉強しながら”これ試験でも使いそう...!!”と思ったものを自分のためにメモしていくものです。（※随時追記します）

alias etc.

試験が始まったら、まずこれ。他にもありそうだけど、個人的には一旦これで十分な気がしている。

bash シェルにコマンド補完を設定する。

source <(kubectl completion bash)
echo "source <(kubectl completion bash)" >> ~/.bashrc

エイリアスを設定する。

alias k=kubectl
complete -F __start_kubectl k

ちなみに、Kubernetes の公式ドキュメントのチートシートに記載があるので、試験本番中も閲覧可能。

--dry-run=client -o yaml は、めちゃ使うので、環境変数とかで設定しておくと良さそう。

export do="--dry-run=client -o yaml"
# この辺はお好みで...
export oj="-o json"
export oy="-o yaml"
export ow="-o wide"

ついでに、.vimrc に以下の設定をしておく。

set tabstop=2
set expandtab
set shiftwidth=2
set autoindent
set number
set ignorecase

コマンド

とにかく時間が足りないらしいので、極力 Manifest を手書きで書くことは避ける。

Pod の作成

そのまま、作成する場合

k run <pod-name> --image=<image-name>

一旦、YAML 形式で出力してから手直しする場合（securityContext や toleration など kubectl のオプションに含まれていない設定を行う場合）

k run <pod-name> --image=<image-name> --dry-run=client -o yaml > <file-name>

リソースの作成

ここで指しているリソースは以下の通り。特に、clusterrole, clusterrolebinding, deployment, namespace, role, rolebinding, secret, service, serviceaccount 辺りはよく使うのでヘルプしなくてもある程度は使えるようになっておいた方がいい。

  • clusterrole
  • clusterrolebinding
  • configmap
  • cronjob
  • deployment
  • ingress
  • job
  • namespace
  • poddisruptionbudget
  • priorityclass
  • quota
  • role
  • rolebinding
  • secret
  • service
  • serviceaccount

そのまま作成する場合

k create <resource-name> ...

一旦、YAML 形式で出力してから手直しする場合

k create <resource-name> --dry-run=client -o yaml > <file-name>

この Pod どの Node に配置されてる？

-o wide で OK

k get po -o wide

ラベル付きで Pod の一覧を出力したい

Network Policy の設定等の際に、ラベル付きで一覧表示したいときに使う。

--show-labels でOK

k get po --show-labels

ここの Manifest どう書くんだっけ...？

ドキュメントに記載の Manifest を参照するか、 一部分だけ分からないなら explain で調べる。

k explain po.spec

ブックマーク

CKA では試験中にドキュメントを参照できます。一応サイト内に検索機能はあるのですが、本番中に許可されていないサイトへのリンクも含まれているためちょっとリスキーです。そのため、基本は自分のブックマークから飛ぶと良いでしょう。（と言いつつ、私は普通にサイト内検索しまくりましたが...）一応、当日はこんな感じのブックマークを作成していました。ほとんど使わなかったけど... ご参考までに。