AWS Certified Database - Specialtyに合格した

本日、2021年6月25日(金)にAWS Certified Database - Specialtyに合格しました!

f:id:ryskit:20210625224807p:plain

ちょっと待て

今日の午前中に試験を受けている最中、データベース固有の問題に関して記憶が曖昧で合ってるかな?と思いながら回答した問題が多々ありました。

まぁでも概ね自信を持って回答したつもりだったのですが、スコアは 774 と受かったとはいえさすがに低い。

試験結果の内訳を見ても、記憶が曖昧だなと思った問題はやはり間違っている傾向があります。

f:id:ryskit:20210625225247p:plain

「分野1のワークロード固有のデータベース設計」ここは明らかな改善ポイントです。合格を喜びつつ、ダメなところは反省して再度勉強し直します。

ちなみにどうやって学習した?

まずは、最近出版された『AWS認定データベース - 専門知識』の対策本を読み込みました。

また、最後の章にある練習問題を解いて、解説もしっかり読んで理解しようとしました。

次に、もっと問題を解きたかったので以下を購入。

FullTestの問題が一つとDBSの出題範囲のセクションごとの練習問題を解きました。

Tutorial Dojoにも解説が記載されていて、AWSの公式ドキュメントのリンクも添えられているので、とにかく記載されているものにはすべて目を通すというやり方をしていました。

www.udemy.com

学習方法に関しては参考になれば幸いです。

最後に

今週は仕事でシステム障害対応であまり勉強時間を取れませんでしたが、なんとか合格できて良かったです。

www.credly.com

あと、Specialtyは DAS、MLS、ANS、最後にCloud Practitionerを受ければAWS資格11冠を取得できるので、そこまでは突っ走ろうと思います。

ちなみに、DBS合格してオフィスに到着してすぐに、次のDASの試験の申し込みをしましたw

ダラダラ試験勉強しても忘れていく方が多そうなので、短期集中で頑張るぞ!

AWS CDK + Step Functionsで入門してみた

AWS資格取得のためにドキュメントを読んだりしてStep Functionsは知っていましたが、仕事で使う機会もなかったのでとりあえず触っておくかということで 、AWS builders.flashに公開されている「Step FunctionsでFizzBuzzを実現する」というのをやってみました。

aws.amazon.com

AWS Serverless Application Model (SAM) を使ってデプロイできるように完成済みのプログラムが提供されていましたが、コンソールでポチポチ試したかったので、jsonベースの構造化言語である Amazon States Language(ASL) を記事通りに写経しました。

やってみて分かりましたが正直ASLを手で書くのはツラいw

「これをどうにか楽に書きたい、できればLambdaを組み合わせても試してみたい」と社内Slackでつぶやいたところ、以下のブロク記事を紹介してもらいました。

紹介

前置きが長くなりましたが、紹介したかったのはこちら!

dev.classmethod.jp

AWS CDK + Step Functions + AWS Lambdaの構成で、様々なステートを用いたステートマシンの書き方が紹介されています。

ステート

以下に関しては、実際にAWS CDKで定義してステートマシンを作成するところまでできるので、真似して書くだけで試せるのがありがたいところです。

  • Task
  • Wait
  • Parallel
  • Pass
  • Choice
  • Success *こちらは説明のみ
  • Fail *こちらは説明のみ

docs.aws.amazon.com

実践

ブログ記事を参考にステートを組み合わせてステートマシンを作ってみました。

リポジトリにあるREADMEにはセットアップ方法・ビルド・デプロイ方法を記載しています。

github.com

最後に

AWS CDKでStep Functionsを書くのは書き心地が最高に良いので、引き続きいろいろ試してみたいと思います。

Amazon ECSのrun-taskでタスク実行が失敗する

Go言語で書いたプッシュ通知システムをAmazon ECS上で構築・運用し始めてから安定稼働していました。

ある日、朝会でチームメンバーとシステムのメトリクスを見ていたら、SQSのメッセージが前日から滞留している不穏なメトリクスを確認しました。

その障害内容と調査内容、原因、対応内容について備忘録として書いていきます。

プッシュ通知システムの前提知識・その他

  • Amazon ECS on Fargate上で構築・運用(Fargate Platform Versionは1.4.0)
  • Go言語で実装
  • プッシュ通知システムはいくつかの種類のECSタスク(以下、タスクと呼ぶ)で構成されている
    • その中でいくつかのタスクは他のタスクから Amazon ECSの run-task APIをコールして実行されている
  • 障害が発生した当日に、別チームがVPCのデフォルトセキュリティグループを削除する対応を行っていた

障害内容

Amazon ECSの run-task APIをコールして実行されるタスクが起動に失敗しており、ステータスが PENDINGSTOPPED となっており、メッセージの処理ができず、プッシュ通知を送信できていませんでした。

調査内容

エラー内容を確認する

タスクのステータスが PENDINGSTOPPED の状態ではアプリケーションはログを出力しませんが、AWSの管理コンソールからタスクの停止理由を確認することができます。

確認すると以下のように表示されていました。

ResourceInitializationError: unable to pull secrets or registry auth: execution resource retrieval failed: unable to retrieve secrets from ssm: service call has been retried 5 time(s): RequestCanceled: request context canceled caused by: context deadli...

ドキュメントでエラーコードの内容を確認すると、以下のように記載がありました。

docs.aws.amazon.com

このエラーは、コンテナの起動に必要なリソースやタスクの所属先のリソースを作成またはブートストラップすることに Fargate エージェントが失敗した場合に発生します。 このエラーは、プラットフォームバージョン 1.4 以降を使用している場合にのみ発生します。

エラー内容やドキュメントを見て、イメージの取得やネットワーク周りが原因だろうと考えました。

アプリケーションコードを確認する

run-task を実行する場合に以下のようなインプットを渡して実行しています。

func (c ECSClient) NewRunTaskInput(clusterName string, arn string, subnets []string, securityGroupId *string, count int64) ecs.RunTaskInput {
    input := ecs.RunTaskInput{
        Cluster:        aws.String(clusterName),
        PlatformVersion: aws.String("1.4.0"),
        Count:          aws.Int64(count),
        TaskDefinition: aws.String(arn),
        NetworkConfiguration: &ecs.NetworkConfiguration{
            AwsvpcConfiguration: &ecs.AwsVpcConfiguration{
                Subnets: aws.StringSlice(subnets),
            },
        },
        LaunchType: aws.String("FARGATE"),
    }
    if securityGroupId != nil {
        input.NetworkConfiguration.AwsvpcConfiguration.SecurityGroups = []*string{securityGroupId}
    }
    return input
}

今回障害が発生してしまったタスクに関しては、セキュリティグループのIDを引数として渡していないのを確認しました。(それでも今までは動作していた)

おそらくこのSecurityGroupを指定していないことが原因だろうと思い、アウトバウンドを許可したセキュリティグループのIDを渡すように書き換えたところ、検証環境で正常に動作することが確認できました。

原因

いくつかの要因が重なり、障害が発生しました。

  • 障害発生当日に別チームがセキュリティリスクを減らすため、VPCのデフォルトのセキュリティグループを削除する対応を行っていた
  • 障害が発生したプッシュ通知システムのタスクでは特定のセキュリティグループを指定せずに実行していた

特定のセキュリティグループIDを指定せずに run-task を実行すると、どうなるのか?

aws-sdk-goのコメントに記載がありました。

aws-sdk-go > service > ecs > api.go

// The security groups associated with the task or service. If you do not specify
// a security group, the default security group for the VPC is used. There is
// a limit of 5 security groups that can be specified per AwsVpcConfiguration.
//
// All specified security groups must be from the same VPC.
SecurityGroups []*string `locationName:"securityGroups" type:"list"`

特定のセキュリティグループIDがある場合はそれを使用し、指定がない場合はVPCのデフォルトのセキュリティグループを利用して実行されると明記されています。

つまり、今までVPCのデフォルトセキュリティグループで実行されていたタスクは、デフォルトのセキュリティグループが削除されたことでアタッチできず、ECRと通信ができなくなりイメージを取得できなくなった。

その結果、タスクの実行に失敗していました。

対応内容

run-task 実行時のインプットにセキュリティグループIDを指定するよう修正しました。

まとめ

  • ちゃんとライブラリのコードを読もう
  • run-task 実行時のインプットには必ず適切なセキュリティグループIDを指定しよう
    • VPCのデフォルトのセキュリティグループを使っちゃダメ

Serverless Framework内部で使用しているwsライブラリの脆弱性対応を行う

とあるシステムでServerless Framework(以下、serverlessと呼ぶ)を使っているのですが、Githubのリポジトリ上で Dependabot alert が出ていたので、それの調査と対応の内容を書き留めておきます。

前提

  • serverless@2.41.0 を使用

脆弱性の内容を確認する

npm audit コマンドを実行して脆弱性の内容を確認します。

$ npm audit

                       === npm audit security report ===

# Run  npm update ws --depth 7  to resolve 4 vulnerabilities
┌───────────────┬──────────────────────────────────────────────────────────────┐
│ Moderate      │ Regular Expression Denial of Service                         │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Package       │ ws                                                           │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Dependency of │ serverless [dev]                                             │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Path          │ serverless > @serverless/components >                        │
│               │ @serverless/platform-client > ws                             │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ More info     │ https://npmjs.com/advisories/1748                            │
└───────────────┴──────────────────────────────────────────────────────────────┘


┌───────────────┬──────────────────────────────────────────────────────────────┐
│ Moderate      │ Regular Expression Denial of Service                         │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Package       │ ws                                                           │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Dependency of │ serverless [dev]                                             │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Path          │ serverless > @serverless/enterprise-plugin >                 │
│               │ @serverless/platform-client > ws                             │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ More info     │ https://npmjs.com/advisories/1748                            │
└───────────────┴──────────────────────────────────────────────────────────────┘


┌───────────────┬──────────────────────────────────────────────────────────────┐
│ Moderate      │ Regular Expression Denial of Service                         │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Package       │ ws                                                           │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Dependency of │ serverless [dev]                                             │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Path          │ serverless > @serverless/components >                        │
│               │ @serverless/platform-client-china > @serverless/utils-china  │
│               │ > socket.io-client > engine.io-client > ws                   │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ More info     │ https://npmjs.com/advisories/1748                            │
└───────────────┴──────────────────────────────────────────────────────────────┘


┌───────────────┬──────────────────────────────────────────────────────────────┐
│ Moderate      │ Regular Expression Denial of Service                         │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Package       │ ws                                                           │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Dependency of │ serverless [dev]                                             │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Path          │ serverless > @serverless/components >                        │
│               │ @serverless/platform-client-china > ws                       │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ More info     │ https://npmjs.com/advisories/1748                            │
└───────────────┴──────────────────────────────────────────────────────────────┘


found 4 moderate severity vulnerabilities in 668 scanned packages
  run `npm audit fix` to fix 4 of them.

脆弱性の詳細

脆弱性の詳細情報を見ると、以下のように記載がありました。

Overview

In ws before versions 6.2.2 and 7.4.6 there is a ReDOS vulnerability.

Impact

A specially crafted value of the Sec-Websocket-Protocol header can be used to significantly slow down a ws server.

Patches

The vulnerability was fixed in ws@7.4.6

  • ライブラリ ws@7.4.6 より前のバージョンで ReDOS の脆弱性がある
  • Sec-Websocket-Protocolヘッダに特別な細工を施した値を使用すると、wsサーバの速度を大幅に低下させることができる
  • ws@7.4.6 で脆弱性は修正された

対応内容

serverless@2.44.0 にアップデートしました。 serverless@2.44.0package.json の内容を確認すると、脆弱性が修正された ws@7.4.6 を指定しているのを確認できます。

https://github.com/serverless/serverless/blob/v2.44.0/package.json

2.44.0 より前のバージョンでは ws@7.4.5 を使用しているため、2.44.0 までアップデートするのが良さそうでした。 脆弱性の内容を見る限り、AWS Lambdaのデプロイにserverlessを使っているだけだったのでそこまで影響がない内容でしたが、アラートを放置するのも良くないのでサクッと対応しました。

最後に

ライブラリはこまめにアップデートしていきたいですね!

『イラストでわかるDockerとKubernetes』を読んだ

どんな本か

この本はタイトルどおりイラストを交えてDocker・Kubernetesについて分かりやすく説明された本です。

構成は以下の通りで、ページ数も130ページ程度なのでサクッと読めるようになっています。

  • 第1章 コンテナ技術の概要
  • 第2章 Dockerの概要
  • 第3章 Kubernetesの概要
  • 第4章 コンテナランタイムとコンテナの標準仕様の概要

目的

普段はローカル環境でDockerを使ったり、本番環境にAWSのAmazon ECSを導入してみたりはしましたが、Kubernetesは全くさわってきませんでした。

最近ふとKubernetesを実際にさわってみて、仕事に活かしたりできないかと思い、この本を手に取りました。

「まずはKubernetesやその周辺技術の概要をざっくりで良いので掴みたい」というのが目的です。

感想

Kubernetesの仕組みやより踏み込んだコンテナランタイムや標準仕様などの説明が分かりやすく、個人的にすごく面白かったです。 特にkubelet、CRIランタイム、CNIプラグイン、OCIランタイムらへんはもっと深堀りしてみたい。

要所要所にイラストや実際に実行したコマンドの結果を載せてくれているので、手を動かさずに読み進めても雰囲気で理解できますが、一度Kubuernetesの環境構築をしたほうが良さそうです。 あと、実際に使う場合、Amazon EKSやGoogleのGKEを利用すると思うので、そこらへんの構築も試して手順として残しておきたいところ。

以下の本は初めてKubernetesさわる人が読むと良いらしいとTwitterで見たので、次はこれを読みつつ手を動かしていこう。

あと、以前聞いたfukabori.fmのdocker/kubernetes周りのネットワーキングの話も改めて聴く。

fukabori.fm

eh-career.com

読書ノート

第1章 コンテナ技術の概要

  • コンテナもその実態はプロセスで、異なるのはOSカーネルの機能を用いて通常のプロセスよりもより強く環境が隔離されている点

第2章 Dockerの概要

  • コンテナイメージの作成
    • Dockerfile: コンテナの作成手順書
    • コンテキスト: コンテナに格納するプログラムなどのファイル群
  • コンテナイメージのレイヤ構造
    • レイヤ(変更差分)
    • コンテナは変更差分を集めたもの
  • コンテナのレイヤ構造は、その実行時にも保たれている
  • コンテナのレイヤ構造は、コンテナ同士で可能な限りデータの重複を作らないようにしつつ、お互いの環境が影響し合わないようにする
  • あるイメージからコンテナを複数実行する場合でも、それらコンテナ同士で共通のレイヤ群はコピーされることなく、共有される
  • Storage Driverは、コンテナを構成する各レイヤをホスト上で保持しており、それらを重ね合わせてコンテナのルートファイルシステムとして利用できるようにするなど、レイヤ群の管理を担うコンポーネント
    • 実装は、aufs, btrfs, overlayfsなど、さまざまなファイルシステムなどの技術が用いられている
  • overlayファイルシステムはLinuxカーネル3.18から導入され、あるディレクトリを別のディレクトリへ重ね合わせ、その重ね合わせた結果をマウントすることができるファイルシステム
  • マシン上ではDockerデーモン(dockerd)が起動しており、dockerコマンドからDocker APIと呼ばれるHTTP API経由で支持を受ける
  • Dockerデーモンは、コンテナの実行だけでなく、そのイメージやネットワーク、ストレージなどコンテナのライフサイクル全体にわたる管理を担っている
  • ホストから隔離された実行環境をコンテナとして作り出したり、それを直接操作するのはDockerデーモンではなく、OCIランタイム(低レベルランタイム)と呼ばれるソフトウェアが担当する

第3章 Kubernetesの概要

  • Kubernetesに対して「アプリケーションやそれを構成するコンテナ群はこういう状態であるべき」というような理想状態をYAMLやJSON形式の「マニフェスト」と呼ばれる設定ファイルの形で宣言すると、それを実現・維持するための具体的な作業をKubernetesがよしなに行ってくれるというもの。
  • Kubernetesは管理情報をHTTP APIで公開しており、ユーザはそのAPIの操作を通じて前節で述べたような理想状態の宣言や、アプリケーションに関する状態の確認などを行う
    • このAPIを参照・操作しながら、ユーザーが宣言した理想状態を維持するために具体的な管理作業を行うコンポーネント群は「コントローラ」と呼ばれる
  • コンテナ群を実行するマシンの集合を「クラスタ」と呼ぶ
  • 各コンテナが実行されるマシンは「ノード」と呼ぶ
  • ノード上では複数の「ノードコンポーネント」が稼働し、そのノード上のコンテナ群の実行管理やイメージの管理、通信の管理などを行う
  • Kubernetesクラスタ全体の管理を担うコンポーネントは「コントロールプレーン」と呼ぶ
    • コントローラーやコンテナのデプロイ時にそのスケジューリングを行うコンポーネントなどが含まれる
  • Kubernetesにおいて最も基本的なデプロイ単位は関連する複数のコンテナ群を1つにまとめた「Pod」と呼ばれているもの
  • 1つのPodに含まれるコンテナ群は同一のノード上にデプロイされ、ネットワーク・インターフェースやストレージの割当などを共有する
  • KubernetesはIPアドレスをPodごとに払い出すため、Pod同士はそれぞれのIPアドレスを使って通信できる。またPod内のコンテナはlocalhostで通信できる。
  • Pod群のデプロイにまつわるリソース
    • Deployment
      • Pod群を一定数を維持しながらクラスタ上に展開するのに有用なリソース
      • セルフヒーリング
        • 障害の発生などによりクラスタ全体で設定された数のPodが正常に稼働していない場合に、自動敵に新たなPodを実行し復旧を試みる機能
      • スケーリング
    • StatefullSet
      • ステートフルなコンテナの実行をサポート
      • Podにはインデックス0を含むPod名と固有のボリューム)PersistentVolume)が付与される
    • DeamonSet
      • 各ノード上にPodが1つずつ実行されている状態を維持するリソース
    • Job
      • 単発に実行するユースケースに有効
    • CronJob
      • Conフォーマットで実行開始時間や定期実行など設定可能
  • Podやコンテナは、長期的な状態を持たないステートレス、またはエフェメラルな(揮発性の)実行単位と言われる
  • 設定項目・秘匿項目を独立して管理できるように、ConfigMapやSecretというリソースがある
    • コンテナ内の環境変数としてみせる
    • コンテナ内のファイルシステムに読み取り専用でマウントし、ファイルとして見せる
  • Service
    • あるサービスを提供する複数のPodに共通のIPアドレスを付与し、1つの「サービス」のようにアクセスできるようになる
    • Pod自体にもIPアドレスが付与されているが、Serviceが必要なのはなぜか?
      • Kubernetes上ではPodのIPアドレスは頻繁に変わり得るという点が挙げられる
    • リソースの種類
      • NodePort
        • 各ノード上のポートをクラスタ外に公開し、そのポートを通じた通信を、そのServiceを構成するPodのいずれかにロードバランスする。
      • Load Balancer Service
      • Ingress
        • L7ロード・バランシングの機能を提供する
        • 1つのアプリケーションを複数のServiceを用いて構成し、URLのホスト名やパスのルールベースで、実際にアクセス先として用いる
  • kubelet
    • ノード上のPod群の実行管理を行う
  • CRIランタイム
    • イメージの取得やPod・コンテナ群の管理を行う
  • CNIプラグイン
    • Podの作成はCRIランタイムが担当するが、そのPodにIPアドレスを払い出し、仮想的なNICをPodに付与するのはCNIプラグインが行う
      • flannel, Calico
  • OCIランタイム
    • CRIランタイムなど高位のランタイムから指示を受け、ホストから隔離された実行環境をコンテナとして作り出しその直接操作の手段を与える

第4章 コンテナランタイムとコンテナの標準仕様の概要

  • containerd
    • Dockerはコンテナ実行のためにcontainerdを内部で使用している
    • containerdはCRIを実装しているため、Kubernetes環境ではcontainerdを単体のCRIランタイムとして用いることができる
    • containerdが低レベルランタイムを呼び出すときは、shimと呼ばれるバイナリコンポーネントを介する。低レベルランタイムは、それぞれの持つアーキテクチャに合ったshimを実装し、それをcontainerdにプラグインすることで、containerdを通じてそれら低レベルランタイムを操作できるようになる。
  • 低レベルランタイムはOCIで定義されたインターフェースを通じて高レベルランタイムから指示を受け、ホストから隔離された実行環境を作成したり、その操作手段を提供する
    • コンテナ(ホストから隔離された実行環境)の作り方は1つではなく、低レベルランタイムによってさまざなバリエーションがある。
    • runc, gVisor, Kata Containersas
  • OCI Runtime SpecificationはOCIによって策定されている低レベルランタイムの仕様のこと
  • Filesystem bundle
    • ファイル群が格納されたディレクトリ
      • コンテナのルートファイルシステム
      • コンテナ実行環境の設定ファイル
  • コンテナのライフサイクル
    1. Filesystem bundleをOCI準拠のランタイムに指定し、コンテナを作成
    2. コンテナの実行を開始
    3. コンテナ内のアプリケーションが終了する
    4. コンテナを削除する
  • コンテナに対して可能な操作
    • create
    • start
    • kill
    • delete
    • state
  • OCI Image Specification
    • マニフェスト
    • レイヤ
    • コンフィギュレーション
    • インデックス(optional)
  • namespace
    • あるプロセスから操作可能なリソースを、その他のプロセスから隔離できる機能
    • PIC namespace プロセス群の管理
    • Mount namespace マウントポイントリストの隔離
    • Network namespace ネットワーク関連のリソースの隔離
  • cgroup
    • プロセスが使用可能なリソースについて、たとえば以下を含むさまざまな設定を施せる機能
    • デバイスファイルへのアクセス権限
    • プロセスから利用可能なCPUの制限
    • プロセスが利用可能なメモリ使用量の制限

2021年5月10日 ~ 17日 振り返り

GWと先週の振り返り。

仕事

CircleCIの設定ファイルの修正

概要

CircleCI上でサブプロジェクトをsbt assemblyするよう設定ファイルを修正しました。

詳細

今進めているプロジェクトのコードは一つのディレクトリに複数のサブプロジェクトが入っており、それらをマルチプロジェクトビルドしています。

その中にはEC2上で実行されるアプリケーションやAWS Lambdaとして起動されるものも含まれています。

CI上ではこれらサブプロジェクトのビルドやテストを実行していたのですが、AWS Lambdaとして起動されるサブプロジェクトのコードはCI上ではビルドする設定が記述されていませんでした。

そのため、あるライブラリをバージョンアップしてdevelopブランチでは動いていたため、masterブランチにマージしてリリースしようとした際に、sbt assemblyコマンドでjarを生成する段階でエラーが発生しました。

エラー内容としては、sbt-assemblyを使用してjarを生成する際に同名ファイルがあったためエラーになっていました。

気づかなかった原因としては、違うタイミングでsbtのMergeStrategyが修正されており、masterブランチにそれらが含まれていなかったということです。

ただ、CIでsbt assemblyをするよう設定をしておけばもっと早い段階で気づけたため、今回の修正対応を行いました。

解決策

.circleci/config.yml に以下のような設定を追加

      - run:
          name: run lambdaXXXX/assembly
          command: |
            if [ "$CIRCLE_NODE_INDEX" == "5" ]; then cat /dev/null | sbt 'set lambdaXXXX/test in lambdaXXXX/assembly := {}' lambdaXXXX/clean lambdaXXXX/assembly; else true; fi
          no_output_timeout: 30m

CIRCLE_NODE_INDEX はCircleCIが定義している環境変数で、並列実行しているジョブのIndexを指します。

circleci.com

なぜ、以下のような書き方をしているかというと、他のジョブでテストを実行するよう設定しているため、ここではsbt assembly時はテストの実行を無視したかったからです。

sbt 'set lambdaXXXX/test in lambdaXXXX/assembly := {}' lambdaXXXX/clean lambdaXXXX/assembly

プロジェクトに新しいAPIを追加

概要

PoCプロジェクトで利用するAPIを新規で追加しました。

詳細

あまり詳細に書けないのであれですが、以下のライブラリとかプロジェクトで使ってて便利だしバリバリ使ってるので、コードリーディングしないとなーと感じてます。

github.com

github.com

github.com

プライベート

読書

『雰囲気でOAuth2.0を~』等

Auth屋さんのOAuth2.0・OIDC関連の本を読みました。

OAuth2.0とOIDCがいまいち分からない人やOAuthを利用したり実装したりする場合に気をつけるポイントを押さえたいと思っている方はぜひ読んでみてください!

かなりおすすめです!

blog.ryskit.com

blog.ryskit.com

blog.ryskit.com

やったこと

GW中や休日は FP in Scalaをやり直してました。

tatsu-zine.com

前回やったときはPart1 までやったのですが、今回はすべてやり抜こうと思い少しずつ進めています。

今はやっと第8章のプロパティベースのテストに入りました。

Part2 から難しく感じて、進みが遅いですがやり抜きたい!

github.com

『エルゴトロン LX デスクマウント モニターアーム』を買った

タイトルのとおり、エルゴトロンのLX デスクマウント モニターアームを買いました!

なぜ買ったのか?

以前はディスプレイと一緒に買った安物のモニターアームを使っていました。

ただ、この安物のモニターアームが届いてからずっと気に入りませんでした!

何が気に入らなかったかというと、ディスプレイの位置を調整するには付属品の六角レンチを使わなくて、わざわざ六角レンチを使って緩めては締めてという動作がかなり面倒な点です。

それが嫌で一時はある程度の高さまで積んだ本の上に、ディスプレイに付属していたスタンドで作業をしていました。

ただそれだとデスクの奥行きがなくなりPCと本の距離が近くなってしまい、PCの熱が逃げにくくなってファンが回りやすい状態でした。

これではイケないなと思い、ちょっとお高いですが今回のエルゴトロンのモニターアームを買いました!

感想

めちゃめちゃ良いです!

最初はお使いのディスプレイの重量に合わせて微調整は必要ですが、それ以降はディスプレイを好きな場所に簡単に移動させられます。

正直、安いものを買ってガッカリするぐらいなら、エルゴトロンLX買っておいても損しないと思います。

おそらく安いもの買っても結局イライラして買い換えると思うので、それなら最初から買っておくのがおすすめです!

このエルゴトロンの解説動画もおすすめです!買おうか考えている人は見てみてはどうでしょうか?

youtu.be

『OAuth・OIDCへの攻撃と対策を整理して理解できる本(リダイレクトへの攻撃編)』を読んだ

目的

前作・前々作を読んで理解しましたが、攻撃を仕掛ける側はどうやって攻撃をしてくるのか、それの対策方法を知りたかったからです。

techbookfest.org

以下は、前作・前々作の記事です。

blog.ryskit.com

blog.ryskit.com

感想

OAuthやOIDCのおさらいは書かれているものの、理解ある前提ではあると思うので、事前に前作・前々作を読んでから読むのが良いかなと思います。

techbookfest.org

techbookfest.org

この本では、OAuth/OIDCへの5種類の攻撃方法の説明とその対策がシーケンス図とともに分かりやすく書かれています。

だいたいはOAuth/OIDCを使う側だと思うので、認可サーバを実装する機会はあまりないかと思いますが、クライアントやリライングパーティ側で特定の値の検証することで攻撃への対策ができるものもあります。

そういった対策をこの本を読んで知っておくことで、「ライブラリやフレームワークを選定する場合」や「自ら実装する場合」に活きてくるのかなと思いました。

第7章の全体整理では、OAuth/OIDCのどのグラント/フローの場合にどのような攻撃がされるのか、その対策は何なのか、第6章までで説明された内容がフォーマットに沿って整理されているため、時間が経って詳細を忘れた場合でも思い出すのに役立ちそうです。

読書メモ

第1章 OAuth・OIDCのおさらい

  • OAuth Danceとは
    • 認可コードフロー、インプリシットフローではクライアント・認可サーバ間で何度も情報のやりとりが行われるが、その様子を指す
  • OAuth Danceの中で認可レスポンスが狙われる理由は3点
    • 認可コード、アクセストークン、IDトークンなどの情報がURIの中に含まれている
    • 認可サーバ、クライアント間の情報のやり取りの間にブラウザのリダイレクトを介している
    • 認可サーバ・IDプロバイダによるリソースオーナー(エンドユーザー)の認証・同意処理が完了済み
  • 上記のやりとりへの攻撃として5種類の攻撃がある
    • CSRF
    • リプレイスアタック
    • コードインジェクション
    • トークンインジェクション
    • 認可コード横取り攻撃

第2章 CSRF

  • 認可サーバーでは state に対して何の検証も行わない。state の検証を行うのはアプリであることに注意
  • state を使うことで CSRF を防ぐことができる
  • state により 認証リクエストのセッションと認証レスポンスのセッションが同一であることを検証できる
  • OAuthは仕様でstateの利用は任意になっているため、ライブラリやフレームワークを利用する際は事前にstateの検証が正しく行われるかチェックが必要
  • セッションごとにstateを生成しなければならない
  • 推測困難なランダムな文字列を state として使う
  • 認可レスポンスのセッションと state の紐付けを確認する
  • state が含まれていない認可レスポンスはエラーで返す
  • OAuth 2.0 Security Best Current Practice

第3章 リプレイス攻撃

  • 第三者のIDトークンを攻撃者自身の管理下にあるアプリに適用
  • 攻撃対象のフロー
    • インプリシットフロー
    • ハイブリットフロー
  • nonce - number used once
  • リプレイス攻撃を可能にしてしまう原因は、同じIDトークンを他のデバイスのアプリ上で利用できてしまうこと
  • IDトークンの検証完了後、nonce を無効化する

第4章 認可コード横取り攻撃

  • 同じデバイスにインストールされた「同じカスタムスキームを持つアプリ」に認可コードを奪われる。結果、アクセストークンを取得される
  • 対象は、OAuth, OIDC
  • 攻撃対象は、認可コードフロー、ハイブリッドフロー(response_typeにcodeを含むもの)
  • 攻撃を可能にしているポイントが同じカスタムスキームであること
  • PKCE
    • code_verifier
      • 長さ43文字、最大128文字までの間の[A-Z] / [a-z] / [0-9] / "-" / "." / "_" / "~" / からなるランダム文字列
    • code_challenge
      • code_verifierに対して code_challenge_method の計算をほどこして算出された値
    • code_challenge_method
      • plain
        • code_challenge = code_verifier
      • S256
        • code_challenge = BASE64URL-ENCODE( SHA256 (ASCII( code_verifier ) ) )
  • 認可サーバで、code_verifierの検証が行われる

第5章 トークンインジェクション

  • 第三者の有効なアクセストークンを攻撃者自身の管理下にあるアプリに適用
  • 攻撃対象は、OAuth、OIDC
  • OAuthには対策がない(独自対応しているサービスはある)
  • at_hash <- access token hash?
    • IDトークンに含まれるクレームの1つ
  • IDトークンには2つの役割がある
    • 認証アサーションとしての役割
    • デタッチ署名としての役割
  • 認証レスポンスのアクセストークンの情報を、ペイロードに含めることで、アクセストークンの署名としても機能する
  • ペイロードには「IDトークンの署名と同じハッシュアルゴリズムでアクセストークンのハッシュ値を算出し、その左半分をBase64URLエンコードした文字列」を at_hashの値に入れる
  • 取得したアクセストークンに対して、上記で算出したat_hashの値とIDトークンのペイロードに埋め込まれたat_hashの値を比較することで入れ替えに気づくことができる
  • インプリシットグラントは使わず、認可コード + PKCE
  • フラグメントはリダイレクト時にその情報がサーバに送られないため、漏洩のリスクが下がる
  • コラム: トークンはどこからもれるのか?が面白い p.66

第6章 コードインジェクション

  • 第三者の未使用の認可コードを攻撃者自身の管理下にあるアプリに適用
  • 攻撃対象は、OAuth、OIDC
  • PKCE・nonce・c_hash(code hash?)による対策が書かれている
  • OAuthの仕様では認可コードは有効期限が短く、一度しか利用できないため、利用されていない許可コードを取得した上で、短い有効期限内に攻撃を完了する必要がある
  • コードインジェクションを防ぐために、アプリは「」セッションとcode_verifierの紐付け」を管理し、認可サーバは「code_challengeと認可コード(code)の紐付け」を管理する必要がある
  • コードインジェクションを防ぐために、アプリはセッションとnonceの紐付けを管理し、IDプロバイダはnonceと認可コード(code)の紐付けを管理する必要がある
  • c_hashが利用できるのは、response_typeの値にid_tokenとcodeの両方が含まれるハイブリッドフロー
  • c_hashは、「IDトークンの署名と同じハッシュアルゴリズムで認可コードのハッシュ値を算出市、その左半分をBase64URLエンコードした文字列」
    • 認証レスポンスで取得した認可コードに対して、上記と同じ演算を行い、同じく認証レスポンスで取得したIDトークンのc_hashの値を比較することで認可コードの入れ替えに気づくことができる

第7章 全体整理

  • 認可フローやクライアントの種別に応じて、攻撃の種別や対策方法がまとめられている
  • ハイブリットフローでのパラメータ共有について p.106

『OAuth、OAuth認証、OpenID Connectの違いを整理して理解できる本』を読んだ

目的

前作に続いて、OAuthとOpenID Connectの違いを理解したくてこの本を読みました。

techbookfest.org

感想

こちらも前作に続き分かりやすく解説されていて、かつサクッと読めます!

タイトルにもあるように、OAuth、OAuth認証、OpenID Connectの違いが整理して書かれているため、OAuthと比べてどこがどう違うのか上手く説明してくれています。

第2章でOAuthの復習の章を設けられていますが、個人的には前作の『雰囲気でOAuth2.0を使っているエンジニアがOAuth2.0を整理して、手を動かしながら学べる本』を理解した後にすぐ読んだほうがより理解がしやすいのかなと思います。

techbookfest.org

あと、個人的にコラムは絶対読み飛ばさないほうが良いです!

OAuthの脆弱性やアプリのログインに脆弱性があった場合にどうやって攻撃されるのかが説明されているので、読み物としても面白いですし、実際にこうやって攻撃されるのかとOAuth認証やOIDCへの理解も深まると思うので。

読書ノート

  • OAuth認証
    • アプリはプロフィールAPIで得たユーザー識別子の情報などを利用して、ユーザーの認証が可能になる
    • OAuth認証、アプリのログイン実装の脆弱性についてのコラムが面白い - p29
    • Facebookではなりすましログインへの対策に /debug_tokenエンドポイントという独自エンドポイントを用意している
  • OpenID Connect(OIDC)
    • OAuthに IDトークン・UserInfoエンドポイントを加えたものを言う
    • IDトークンはユーザーの認証に利用
    • UserInfoエンドポイントはユーザーのプロフィール情報を得るために利用
    • OAuthとOIDCのロール関連用語に違いがある - p36
  • OIDCのフローは3つ
    • 認可コードフロー
    • インプリシットフロー
    • ハイブリッドフロー
      • インプリシットフローと認可コードフローのハイブリッドなフロー
      • パブリッククライアントとコンフィデンシャルクライアントの両方で構成されているクライアントに利用する
        • JavaScriptアプリ・ネイティブアプリ + バックエンドサーバー
  • OIDCでは scopeの値は仕様で決まっている
  • OAuthとOIDCの一番のち外はフローにおいて、IDトークンの発行が行われること
  • デタッチ署名とは、署名の対象と署名が分離した形式の署名のこと

『雰囲気でOAuth2.0 を使っているエンジニアが OAuth2.0を整理して、手を動かしながら学べる本』を読んだ

目的

OAuth2.0への理解を整理したい思い読みました。

techbookfest.org

感想

タイトルにもあるように雰囲気でOAuth2.0を使っている人やとりあえずOAuth2.0って何?って人にすごくおすすめです!

分かりやすいし、安い!

1~5章は、OAuth2.0とは何か?から始まり、OAuthの各グラントタイプごとにクライアントがどのような流れでトークンを受け取るか分かりやすく説明されています。

本自体は100ページ程度ですが、OAuth2.0の説明自体は60ページほどで1時間弱あればゆっくり読んでも読み終わるので、すごく良くまとまっているなと思いました!

個人的に、パブリッククライアント向けのグラントタイプとして推奨されている、「認可コードグラント+ PKCE」は知らなかったので勉強になりました!

6章は、実際にGoogleのPhoto Library APIを用いてOAuth2.0を手を動かしながら学べます。

1~5章で学んだ内容を実際に手を動かして復習できるので、理解も深まりやすいです。

OAuth2.0の説明を読んでよく分からなければ、まず6章の内容に従い手を動かしてから読むと良いかも知れません。

読書メモ

  • 認可エンドポイントとトークンエンドポイントは、認可サーバが提供するURI
  • リダイレクトエンドポイントはクライアントが提供するURI
  • トークンエンドポイントではBasic認証によって、クライアントのアイデンティティが確認される
  • Basic認証としてAuthorization ヘッダーに設定されるのは、クライアントID と クライアントシークレット
    • これらは認可サーバーにクライアントを事前登録する際に発行される
  • OAuthのグラントタイプ
    • 認可コードグラント
    • インプリシットグラント
      • 非推奨
    • クライアントクレデンシャルグラント
    • リソースオーナーパスワードクレデンシャルグラント
  • リソースオーナーパスワードクレデンシャルグラントを利用できるのは、リソースサーバーおよび認可サーバーとクライアントの提供元が同じ組織である場合
    • クライアントタイプがコンフィデンシャル、パブリックの両方で利用可
  • PKCE は「Proof Key for Code Exchange」の略で「ピクシー」と読む