pokutuna.com

メンバーやサービスアカウントの権限を考える際に、ロールの持つ権限を比較したいことがしばしばある。そういう時は gcloud と diff を使うことで比較できるという素朴なテク。 ロールと権限 ロール(role)は roles/{roleName}, roles/{service}.{roleName} などで表され、許可されている操作を表す権限(permission)の集合である。 例えば BigQuery データ閲覧者 (roles/bigquery.dataViewer) は、以下の permission を持つ。 bigquery.datasets.get bigquery.datasets.getIamPolicy bigquery.models.export bigquery.models.getData bigquery.models.getMetadata bigquery.models.list bigquery.routines.get bigquery.routines.list bigquery.tables.createSnapshot bigquery.tables.export bigquery.tables.get bigquery.tables.getData bigquery.tables.getIamPolicy bigquery.tables.list resourcemanager.projects.get resourcemanager.projects.list cloud.google.com ロールの比較 個別のロールと権限について確認したいときは以下のドキュメントを見る、GCP 屈指の縦に長いページ role から permission Understanding roles | IAM Documentation | Google Cloud permission からそれを持つ role IAM permissions reference | IAM Documentation | Google Cloud role をいじっていると以下のような疑問が湧いてくることがある。 roles/bigquery.dataViewer と roles/bigquery.metadataViewer ってテーブルのデータ読める以外に何が違うんだっけ? roles/browser と roles/resourcemanager.folderViewer ってどう違うんだっけ? roles/editor は強い権限だけど、意外と SecretManager で出来ない操作あった気がする 上のドキュメントを行ったり来たりしてもいいけど、* でサービス内の個別の permission が省略されていたりするのでいまいち分からないし大変。 diff で比較する そういう時は gcloud コマンドで role の permission を得つつ、diff で比較するとよい $ gcloud iam roles describe ROLE で権限のリストが得られるので、これを diff -y で左右に並べる。 roles/bigquery.dataViewer と roles/bigquery.metadataViewer の違いは、 $ diff -y -W80 <(gcloud iam roles describe roles/bigquery.dataViewer) <(gcloud iam roles describe roles/bigquery.metadataViewer) description: Access to view datasets | description: Access to view table and etag: AA== etag: AA== includedPermissions: includedPermissions: - bigquery.datasets.get - bigquery.datasets.get - bigquery.datasets.getIamPolicy - bigquery.datasets.getIamPolicy - bigquery.models.export < - bigquery.models.getData < - bigquery.models.getMetadata - bigquery.models.getMetadata - bigquery.models.list - bigquery.models.list - bigquery.routines.get - bigquery.routines.get - bigquery.routines.list - bigquery.routines.list - bigquery.tables.createSnapshot < - bigquery.tables.export < - bigquery.tables.get - bigquery.tables.get - bigquery.tables.getData < - bigquery.tables.getIamPolicy - bigquery.tables.getIamPolicy - bigquery.tables.list - bigquery.tables.list - resourcemanager.projects.get - resourcemanager.projects.get - resourcemanager.projects.list - resourcemanager.projects.list name: roles/bigquery.dataViewer | name: roles/bigquery.metadataViewer stage: GA stage: GA title: BigQuery Data Viewer | title: BigQuery Metadata Viewer ほうほう、roles/bigquery.dataViewer はテーブルやモデルのスナップショットやエクスポートも取れるんですね。 includedPermissions 以下だけ欲しいなら --format オプションで中身だけ取ることもできる。 --format='value[delimiter="\\n"](includedPermissions)' gcloud の format オプションについてはこちら。 roles/browser と roles/resourcemanager.folderViewer の違いは、 $ diff -y \ <(gcloud iam roles describe roles/browser --format='value[delimiter="\\n"](includedPermissions)') \ <(gcloud iam roles describe roles/resourcemanager.folderViewer --format='value[delimiter="\\n"](includedPermissions)') > orgpolicy.constraints.list > orgpolicy.policies.list > orgpolicy.policy.get resourcemanager.folders.get resourcemanager.folders.get resourcemanager.folders.list resourcemanager.folders.list resourcemanager.organizations.get < resourcemanager.projects.get resourcemanager.projects.get resourcemanager.projects.getIamPolicy < resourcemanager.projects.list resourcemanager.projects.list フムフム。 多くの permission を持つ権限なら比較したい部分で grep すればいいですね。 roles/editor のうち、SecretManager で、roles/secretmanager.admin より弱いのは、 $ diff -y <(gcloud iam roles describe roles/editor | grep secretmanager) <(gcloud iam roles describe roles/secretmanager.admin | grep secretmanager) - secretmanager.locations.get - secretmanager.locations.get - secretmanager.locations.list - secretmanager.locations.list - secretmanager.secrets.create - secretmanager.secrets.create - secretmanager.secrets.delete - secretmanager.secrets.delete - secretmanager.secrets.get - secretmanager.secrets.get - secretmanager.secrets.getIamPolicy - secretmanager.secrets.getIamPolicy - secretmanager.secrets.list - secretmanager.secrets.list > - secretmanager.secrets.setIamPolicy - secretmanager.secrets.update - secretmanager.secrets.update > - secretmanager.versions.access - secretmanager.versions.add - secretmanager.versions.add - secretmanager.versions.destroy - secretmanager.versions.destroy - secretmanager.versions.disable - secretmanager.versions.disable - secretmanager.versions.enable - secretmanager.versions.enable - secretmanager.versions.get - secretmanager.versions.get - secretmanager.versions.list - secretmanager.versions.list > name: roles/secretmanager.admin roles/editor でも、secret に IAM Policy を設定することと、実際の version の読み取りができないのだな〜ということが分かる。 gcloud と diff を使うとこういう感じで比較できます。 適切なロールを選ぶとともに、IAM の推奨事項を見て絞ったりできるとよりよいですね。 cloud.google.com

来週 2022-03-17(木) の Google Cloud オンラインイベント 16:20- 『はてな広告配信システムのクラウドネイティブ化への道のり』で発表します。 データセンター環境で運用していた広告配信システムを GCP へ移転する話です。 派手なメッセージな感じではなく、約1年のプロジェクトの中での採用技術やテクについて紹介する風情の発表になります。EOL 過ぎたソフトウェアたちをまるごとマネージド化し、Elasticsearch を BigQuery に置き換える様子などをご覧にいただけます。 たぶん登録しておけば後日動画で見れると思います。 cloudonair.withgoogle.com 笑顔の写真は締め切り当日にがんばって撮りました。

この記事ははてなエンジニアのカレンダー | Advent Calendar 2021 - Qiita 2日目の記事です。 最近、データパイプラインの整備や営業チームの人力混じりの運用フローを機械化するなどの業務改善に取り組んでいます。 その過程で、運用ドキュメントを読んだりヒアリングして図を描くことがよくあります。 描いた図をもとに「この流れであってますか?」と確認したり「ここ手間結構かかってそうですが困ってませんか?」とコミュニケーションをします。暗黙的な業務の流れが明確になるだけでなく、改善点の発見にも繋がります。 ひととおり改善タスクが終わった後にも図を最新にします。ドキュメントと併せて成果物とします。 どんなデータがあってどのようにビジネスに使われているか、データがどのように取得&保存されているかを残しておくのは今後のデータ活用や改善のためにも必要です。 俺はそんな個々の業務のデータフロー図を描いていって、やがてはおっきなエンタープライズデータモデルを絵にしたいんだ。 でも図やドキュメントを書いていく上で様々な悩みがある!! GUI 作図ツールを使う データフロー図を描くために、draw.io や Cacoo といった作図ツールを使ったり、Google スライド や miro といったスライドツールやホワイトボードツールを使う選択肢がある。 ツリーやダイアグラムを作るためのパーツが用意されていたり、リアルタイム同時編集できるものも多く複数人での認識合わせにも使えて大変便利だけど、いろいろ不満もある。 レイアウトにこだわりがち 自由な絵が描けるのはよいけど、レイアウトに結構な時間を使ってしまう。 ボックスの大きさは揃っているほうがよいしX軸Y軸のアラインを揃えたい、矢印は交差してほしくないし、矢印やボックスの形に一貫した意味が欲しい...とやっていると必要以上に時間を使っていることに気づく。 きれいな図は理解を助けるけど、一世一代のプレゼンテーションでもないのにこだわりすぎるのも無駄が多い。 とはいえある程度は整えないと読み解くのにストレスがあり、ちょうどよい塩梅が難しい。 一貫したルールがないと複数の図を並べた時にもごちゃごちゃした印象になってしまう。 その他いろいろ ドキュメントと別の所にあるので更新されなくなりがち えてして検索性が悪がち 画像として書き出したりスクリーンショットを撮ってドキュメントに移すのがダルいがち やる気のある1人だけがメンテナンスする羽目になりがち 差分管理できながち 図を作る部分の体験はよいけど、その図をどう運用していくか...というところで悩みが出てくる。 Graphviz や PlantUML を使う Graphviz、PlantUMLで図を書く手もある。 普段のテキストエディタで書けて一定のクオリティの図が作れるので重宝している。 レイアウトも多少意識する面はあるものの細かく手をいれられないので適度に妥協できるのも逆に良い点。 社内 Wiki にドキュメントを書く時に、ページ下の方にソースを貼り付けてドキュメントと図のソースの距離を近くすることもできる。 一方で満たされない思いもある。 記法の学習コストがあるがち リポジトリに入れると権限が必要だったりしがち 特に営業チームのメンバーが利用したい時に困りがち 巨大な図を作るとメチャクチャになりがち ドキュメント ここまで図の話をしてきたけど、実際にはドキュメントの一部として図を描きたい。 この業務の背景や目的、関連するドキュメントやダッシュボードへのリンク、新たにデータを利用する際の方法、実装を行っているリポジトリ、権限や窓口、データの更新頻度や扱う諸注意...などなど、図だけで説明しきるのは難しくて、ある程度文章で説明することになる。 ドキュメントを作ってメンテしていく上で、もっとドキュメントと図を近づけたい。 Google Colaboratory でドキュメントを書く Colaboratory は Google の提供する Jupyter Notebook & Python ランタイム。 これを使ってドキュメントを書くのはどうか、というのが今回の試みです。 データを扱うエンジニアには Jupyter はお馴染みだろうから親和性も高い。 Colaboratory へようこそ - Colaboratory やってみます データフローとドキュメント Google Colaboratory でデータフローのドキュメントを書く試み - Colaboratory いかがでしょうか。 果たしてまな板やすし桶はデータストアなのか、これはデータフローなのか、寿司酢を入れなくてよいのか、異論はあるだろうけどデータフロー図とドキュメントを書くことができた。 Colab を使うと 図のソース置き場と表示をどちらも満たせる Markdown を使ってドキュメントを書ける 環境構築にあまり煩わされない BigQuery など実際のデータにアクセスしてサンプルデータを表示したり可視化できる Google アカウントによる権限管理ができる Google Drive 検索にひっかかる 変更履歴が残り古い版に戻せる これらのいいことがある。 やっていること 依存のインストール ! に続けてコマンドを打つことでシェルで実行される。 !apt や !pip で依存を入れることができる。 これをコピペして使っている #@title !pip install graphviz plantuml fonts-noto-cjk #@title は後述 graphviz, plantuml をよく使う fonts-noto-cjk 日本語フォントに Noto Sans Japanese を入れる 入れないと図中に日本語が表示できないことがある 他のフォントウェイトは fonts-noto-cjk-extra にあるけど大きめなので使ってない fonts-ipafont とかでも良いと思います Graphviz や PlantUML のソースを置く %%writefile {filename} から始まるセルを評価すると、以降の内容が filename に保存される。 Python コードで open して文字列を書いている例がよくあるけど、特定のテキストをファイルに書きたいだけならマジックコマンドを使うのが簡単。 Built-in magic commands — IPython 7.30.0 documentation 画像の生成 & 表示 単に Graphviz や PlantUML で画像を作って表示する !dot -Tpng my-flow.dot > my-flow.png # graphviz !plantuml my-flow.puml # plantuml from IPython.display import Image Image('my-flow.png') 一旦完成したらコードを非表示にする ドキュメントとして見せるにはコードを非表示にしておくほうが見栄えがいい。 メニューの "表示" からコードを非表示にするとセルを折りたたむことができる。 非表示にするとセルの先頭に #@title が挿入されるのは、フォームから変数に値を入れる機能を転用して非表示を実装しているからのようだ。つまりメニューを経由しなくてもセルの先頭に #@title を書いて右側の空白をダブルクリックしてもよい。 Forms - Colaboratory 感想 どうでしょうか、Colab にドキュメントを書くのはまだお試し中ですが、悪くない気がします。 特に、ちょっとラベルを変えたり 1~2本フローを増やしたりなどの微修正は画像を生成して Wiki に貼り付けたり、リポジトリにコミットする必要もなくて気楽にできます。 コードセルを非表示にしていても余白ができるのでがちゃがちゃした見た目になりがちだったり、Colab に詳細めなドキュメントが描いてあるという期待がないので社内 Wiki からリンクしていても読まれにくい、という点は気になる。 データアーキテクチャを図にしたりドキュメントにする良いツールやプラクティスがあれば教えて下さい。 アドベントカレンダーについて はてなエンジニアのカレンダー | Advent Calendar 2021 - Qiita 前日は id:nanto_vi による HTMLのdialog要素とフォーム機能 - Hatena Developer Blog でした。 明日は id:gurrium さんの WoTのMODを作りたい - ぜのぜ です。 参考 データフロー図 - Wikipedia DFD（データフロー図）ってなに？DFDの概要と書き方をあわせて紹介 | Cacooブログ

公式ドキュメントで説明されているけど、同僚に何度か説明する機会があったり、作る必要のないサービスアカウントキーを目にすることも多いのでまとめておく。 認証情報が登場しないアプリケーションコード 例えば以下のコードで Secret Manager に保存したトークンを取得することができる。SecretManagerServiceClient にサービスアカウントキーを渡さずとも動作する。 const {SecretManagerServiceClient} = require('@google-cloud/secret-manager'); const client = new SecretManagerServiceClient(); (async () => { const [secret] = await client.accessSecretVersion({ name: 'projects/pokutuna-playground/secrets/token/versions/latest', }); console.log(secret.payload.data.toString('utf8')); })(); これは僕の手元であれば動作するし、みなさんの手元ではエラーになるでしょう。 このコードでアクセス制御ができているのは、クライアントライブラリが実行環境から認証情報を解決しているからです。 Cloud SDKをインストールして gcloud auth application-default login し、name をあなたのシークレットに置き換えれば、あなたのシークレットが読めるでしょう。1 Application Default Credentials Google が提供するクライアントライブラリは以下の優先順位で認証情報を解決している。 GOOGLE_APPLICATION_CREDENTIALS 環境変数に設定されたサービスアカウントキー(のファイルパス) ~/.config/gcloud/applicstion_default_credentials.json に配置された OAuth2 Secret メタデータサーバーに問い合わせて得られた認証情報 これは言語問わず共通して実装されており、Node の場合 google-auth-library-nodejs で実装され、googleapis や、@google-cloud/ 以下のクライアントライブラリで利用されている。 はサービスアカウントキーを使って実行ユーザを上書きするための仕組み で利用されるファイルは gcloud auth application-default login によって配置される Google アカウントログインが求められ、ログインしたユーザの認証情報が配置される。 は GCP 上の実行環境で解決される GCP 上の実行環境では、メタデータサーバーが、アクセス元に応じた認証情報を返してくれる。 Compute Engine、App Engine や Cloud Functions などではインスタンス作成時やデプロイ時にアタッチするサービスアカウントを指定できる。何も指定していなければデフォルトのサービスアカウントがアタッチされている。 Workload Identity を利用して、Kubernetes Service Account と Google Service Account を紐付けて認証情報を解決できる。 この仕組みを使うことで ローカル開発環境ではサービスアカウントキーを使わない(2を利用する) GCP の実行環境ではサービスアカウントキーをデプロイしない(3に任せる) となって、サービスアカウントキーが必要な場面はかなり限定される。 どうしてもサービスアカウントキーを指定したい場合も環境変数で与える(1を使う)ことで、アプリケーションコードに登場しないようにできる。 サービスアカウントキーを配るのを最小にしたい 公式ドキュメントにおいても、開発中は ADC に任せることを推奨している。 サービス アカウントの使用と管理のベスト プラクティス  |  Cloud IAM のドキュメント  |  Google Cloud 開発中にサービス アカウントを使用しない 日常業務で、gcloud コマンドライン ツール、gsutil、terraform などのツールを使用する場合があります。これらのツールの実行でサービス アカウントを使用しないでください。代わりに、gcloud auth login（gcloud ツールと gsutil の場合）または gcloud auth application-default login（terraform などのサードパーティ ツールの場合）を実行して、ツールがユーザーの認証情報を使用することを許可します。 キーの権限や流出に気を使う必要があるので、極力 ADC に寄せたい。 セキュリティ面以外では、1つのサービスアカウントにつきサービスアカウントキーは10個という管理上の制約もある。 開発用サービスアカウントキーを開発者のローカルに配るとすると、先着10回までしか生成できず、10人以上で開発できないし、古いものを消そうにも気を使う、という状況に陥る。 実際のところ、一番サービスアカウントキーを置きたくなるのは外部の CI だろう。 Github Actions などでは渋々配置することになる。AWS や Azure などからは、Workload Identity 連携を使うことで、サービスアカウントキーなしに認証できるようになった。外から BigQuery を叩きたい場合も Workload Identity を設定する手間を厭わなければキーが要らない。 ADC を使うことによる不安と対策 GCP 上で動作させる際に ADC を利用しない理由はほぼない。 開発者はオーナー(roles/owner)などの強力な権限を持っていることが多く、複数のプロジェクトを操作するので、 ローカルでは上手くいくがデプロイして権限が足りないことに気づく 意図したものと異なるプロジェクトに対して操作を実行してしまう ということが起きうる。 1 に関して、サービスアカウントになりすまして確認することができる。 roles/iam.serviceAccountTokenCreator ロールを持っているとサービスアカウントに成り代わって認証情報を取得できる。 このロールは2つのリソース(なりすます側とサービスアカウント)の間の設定であるため、オーナーでもデフォルトで持っていない。以下の手順で設定する。 メンバーに 1 つのサービス アカウントの権限の使用を許可する - サービス アカウントの権限借用の管理  |  Cloud IAM のドキュメント  |  Google Cloud このロールを持っていると gcloud コマンドでは CLOUDSDK_AUTH_IMPERSONATE_SERVICE_ACCOUNT={SA_EMAIL} 環境変数または --impersonate-service-account={SA_EMAIL} でなりすまして操作を実行できる。gcloud コマンドで、このサービスアカウントが PubSub トピックへメッセージをパブリッシュできるか確認できる。 2021-08 現在、まだクライアントライブラリも環境変数などから透過的に解決してくれるわけではなく追加の実装が必要である。 bq コマンドも impersonate に対応していなかったり対応が限定的、gcloud & gsutil 以外で気楽に使える状態ではないので、面倒なのでクライアントライブラリ側で解決するプロトコルを決めて実装してほしいものである。bq は長期的には gcloud bq に機能が移植されていって普段遣いできるようになるんじゃないかなあ〜 有効期間が短いサービス アカウント認証情報の作成  |  Cloud IAM のドキュメント  |  Google Cloud 2 に関して、破壊的な操作で起きると悲惨である。 GCLOUD_PROJECT や GOOGLE_CLOUD_PROJECT 環境変数を設定していない場合、gcloud config list した際の core.project がデフォルトとして使われてしまい、落とし穴として働いてしまう。 googleapis/google-auth-library-nodejs@2fcab77 - src/auth/googleauth.ts#L205L210) 対策としては クライアントに渡すプロジェクトIDを省略しない カレントプロジェクトを設定しない gcloud config unset project するとカレントプロジェクトを設定しないままで居られる 普段から gcloud --project=... で都度プロジェクトを指定する ぐらいしかないので、ややイマイチである。 関連する話題 デフォルトのサービスアカウント GCP の実行環境にアタッチするサービスアカウントを明に指定しない場合はデフォルトのものが使われる。 Compute Engine などでは {PROJECT_NUMBER}-compute@developer.gserviceaccount.com App Engine や Cloud Functions などでは {PROJECT_ID}@appspot.gserviceaccount.com デフォルトでは編集者(roles/editor)ロールという広い範囲を操作できる権限が付いている。 十分強力な権限が付いていることは、初心者に優しかったり、プロジェクト開始時にいきなり IAM の設定を要求されないという良い面もあるのだけど、慣れているユーザはあまり使いたくないだろう。必要最小限の role を与えたサービスアカウントをアタッチするのが理想的だけど、管理の手間もあるので個人的には以下のようにやっている。 小さなプロジェクトでは気にせずデフォルトのサービスアカウントのまま動かす デフォルトサービスアカウントを何かから参照したくなったら変える 別プロジェクトの IAM に追加して権限を与えたくなったりキーを外部に置きたくなったとき ちなみに Secret Manager のシークレットを読むには 編集者(roles/editor) では足りず、Secret Manager のシークレット アクセサー(roles/secretmanager.secretAccessor)ロールが必要である。 gcloud auth login と gcloud auth application-default login の違い gcloud auth login は CloudSDK(gcloudコマンド) で使われる認証情報を設定する。 gcloud auth application-default login は ADC で使われる ~/.config/gcloud/application_default_credentials.json を配置する。 用途が分かれており、ADC を利用したくない場合でも gcloud コマンドの利用に不都合がないように分かれているものと思われる。 両方更新するには gcloud auth login --update-adc ローカルの application_default_credentials.json を使うのを止めたい場合は gcloud auth application-default revoke で削除できる。 コンテナではどうするのか google/cloud-sdk - Docker Image | Docker Hub では named volume に gcloud auth login した認証情報を保管して必要な時にマウントする方法が案内されている。application default についても同様にセットできるだろう。 ADC を使いたいだけなら、ホスト側で作った application_default_credential.json をマウントするのが楽である。 $ docker run -v ~/.config/gcloud/application_default_credentials.json:/root/.config/gcloud/application_default_credentials.json ... Cloud SQL Proxy では実行ユーザが nonroot なのでマウント先を変えなければならない、このあたりは都度調べることになる。 $ docker run -p3306:3306 --rm --hostname=mysql -v ~/.config/gcloud/application_default_credentials.json:/home/nonroot/.config/gcloud/application_default_credentials.json gcr.io/cloudsql-docker/gce-proxy:latest /cloud_sql_proxy -instances=... もちろん自作か Google 提供のイメージ以外に ~/.config/gcloud をマウントするのはリスクがあるので避けるべきである。 リンク 関連する話題への良いドキュメント サービス アカウントとして認証する  |  Google Cloud GCP と OAuth2. | by Yuki Furuyama | google-cloud-jp | Medium Service Accountの運用について · gcpug/nouhau GCP の Compute Metadata Credentials について 関連記事 blog.pokutuna.com 正確にはカレントプロジェクトの設定も必要になる↩