G-gen の杉村です。 Private Service Connect は Google Cloud API やユーザー独自で公開するサービスにプライベート接続を提供するサービスです。当記事では、Private Service Connect を使って独自サービスを公開する方法をご紹介します。 概要 Private Service Connect とは Private Service Connect によるサービス公開 Private Service Connect のアーキテクチャ 構成図 通信の流れ 詳細な構成 サービス提供側 サービス利用側 接続元 IP アドレス DNS 名 構築手順 サービス提供側の手順 サービス利用側の手順 Private Service Connect backends Private Service Connect interfaces 料金 サービス提供側 サービス利用側 概要 Private Service Connect とは Private Service Connect とは Google Cloud (旧称 GCP) の Virtual Private Cloud (VPC) に備わった一機能です。 以下の用途で用いられます。 Google Cloud の API にプライベート IP でアクセスする ユーザー独自のサービスを他の Google Cloud プロジェクト向けに公開する 前者は、本来パブリック IP を用いてインターネット経由でのアクセスが必要な Google Cloud の各種 API に対し、プライベート IP による接続を実現する用途です。以下の記事で詳細を紹介しています。 blog.g-gen.co.jp 後者は、当記事でご紹介する内容です。Google Cloud 上でホストするサービス (Web API やその他のサービス) を 他の Google Cloud ユーザー向け 、あるいは 社内の別 Google Cloud プロジェクト向け に公開する用途です。 AWS には類似の機能として AWS PrivateLink があり、これの Google Cloud 版と思えば良いでしょう。 Private Service Connect によるサービス公開 Compute Engine VM 等でホストするサービスを他の Google Cloud プロジェクトや他の VPC に向けに公開するには、以下のような方法が考えられます。 サービスエンドポイントをインターネットに公開する (外部 HTTP(S) ロードバランサ等を利用) VPC Peering で接続する Cloud VPN で VPC 同士を接続する Private Service Connect で公開する 選択肢 1. は、通常の Web サービスのようにインターネット公開する方法です。ただし、サービスが特定少数のクライアントにだけ向けたものであれば、セキュリティ上の理由でこの方法は避けたくなります。 選択肢 2. や 3. は、VPC 同士を直接接続し、プライベート IP で通信する方法です。これなら不特定多数のクライアントからアクセスされることはありませんが、全ての VPC 同士の IP アドレス帯が重複していない ことが必須条件です。複数の会社・官公庁をまたぐネットワークだと、IP アドレス帯が重複してしまっているケースも多いでしょう。 そこで選択肢 4. の Private Service Connect が検討に入ります。 Private Service Connect によるサービス公開では、IP アドレスの重複有無に関係なく、他の VPC 向けにサービスを公開し、プライベートネットワークでの接続を実現することができます。この方法を Private Service Connect によるマネージドサービス公開 と言います。 参考 : Private Service Connect でマネージド サービスを公開して使用する Private Service Connect のアーキテクチャ 構成図 Private Service Connect でのマネージドサービス公開は、以下のようなアーキテクチャで実現されます。 アーキテクチャ 左側の Google Cloud 環境がサービスを利用する側 (サービスコンシューマーとも呼称) で、右側がサービスを提供する側 (サービスプロデューサーとも呼称) です。 通信の流れ 通信は、以下の流れで実現されます。 前提 : 図右端のサーバは HTTP (tcp/80) でサービスを提供。図左端のクライアントからアクセスされる クライアントは 10.100.0.101:80 (Private Service Connect エンドポイント) へアクセス 通信は Google Cloud 内部ネットワークを通りサービス提供側環境の Service Attachment へ到達。SNAT されて内部ロードバランサへ到達 内部ロードバランサが負荷分散してバックエンドのサーバへ通信が届く (レスポンスは逆の経路を通ってクライアントに返る) 詳細な構成 サービス提供側 サービス提供側は 「サービスアタッチメント」「内部ロードバランサ」「バックエンドサーバ」 の組み合わせでサービスを提供します。 サービスアタッチメント はサービス公開のために作成されるリソースであり、1サービスにつき1個のサービスアタッチメントを作成します。サービスアタッチメントはパケット転送先として 転送ルール にひも付きます。この「転送ルール」とは、ロードバランサの「フロントエンド」と思えば良いです。 なおサービスアタッチメントを作成するための 専用サブネット が必要です。サブネット作成時に「Private Service Connect 用」と明示的に選択して作成する必要があります。サイズは任意であり最小サイズ ( /29 ) とすることもできますが同時接続するクライアント数が多すぎると IP 不足になるおそれがあります ( 参考 )。 内部ロードバランサ は、以下の種類に対応しています。 内部パススルーネットワークロードバランサ 内部アプリケーションロードバランサ 内部プロトコル転送 リージョン内部プロキシネットワークロードバランサ バックエンドサーバ としては、内部ロードバランサが対応している各種バックエンドが利用できます。すなわち、Compute Engine VM (インスタンスグループ) や VPN / 専用線で接続されたオンプレミスのサーバなどが利用できます。 サービス利用側 サービス提供側でサービスアタッチメントを作成すると、サービス名が払い出されます ( projects/${PROJECT_ID}/regions/${REGION}/serviceAttachments/${SERVICE_NAME} )。 サービス利用側ではこの名称を指定して、サービスに接続するためのエンドポイント (Private Service Connect Endpoint) を作成します。 エンドポイントを作成するとプライベート IP が割り当てられます。クライアントからはこのプライベート IP を宛先としてサービスを利用します。 なお、サービス提供側ではサービスアタッチメント作成時に、明示的に承認したプロジェクトのエンドポイントだけを受け付けるように設定できます。未承認のエンドポイントではパケットが転送されません。 ※ より詳細な仕様として、Private Service Connect エンドポイントの実体は「サービスアタッチメントをターゲットとする転送ルール」であり gcloud compute forwarding-rules list で一覧表示することができます。転送ルールはロードバランサのフロントエンドとしても利用されるリソースです。 接続元 IP アドレス トラフィックの接続元 IP アドレスはバックエンドサーバからどう見えるのかが問題になることがあります。Private Service Connect でルートされたトラフィックの接続元 IP は、利用しているロードバランサによって異なります。 内部ロードバランサが プロキシ型 の場合、バックエンドサーバから見た接続元 IP は プロキシ専用サブネットの CIDR 範囲 となる 内部ロードバランサが パススルー型 の場合、バックエンドサーバから見た接続元 IP は サービス専用サブネットの CIDR 範囲 となる いずれの場合でも、クライアントの元々の IP アドレスは得ることができません。元々の IP アドレスを知りたい場合にはサービスアタッチメントにて プロキシプロトコル を有効化します。有効化する場合は以下に注意が必要です。 対応しているのは「内部 TCP / UDP ロードバランサ (TCP 通信のみ)」と「内部プロトコル転送」のみ サーバ側でプロキシプロトコルヘッダを処理するように適切に設定しなければ、リクエストが正常に処理されない またプロキシプロトコルを使った場合でも VPC Firewall などではその情報を参照できないため、Firewall rule で接続元 IP に基づいたアクセス制御を行うことはできません。詳細は以下のドキュメントも参考にしてください。 参考 : コンシューマの接続情報を表示する DNS 名 エンドポイントに DNS 名を設定することもできます。 Service Directory の機能を利用することでサービス提供側で DNS 名を定義 することも可能ですし、サービス利用側で Cloud DNS を使って 定義する ことも可能です。 構築手順 サービス提供側の手順 大まかに、以下の作業を行います。 バックエンドサーバを構築 内部ロードバランサを構築 (適切な VPC Firewall rule を作成) Private Service Connect サービス専用サブネットを作成 (パススルー型ロードバランサの場合) サービス専用サブネットからの通信を許可する VPC Firewall rule を作成 サービスアタッチメントを作成 承認するプロジェクトを追加 詳細は以下のドキュメントを参照してください。 参考 : Private Service Connect を使用してマネージド サービスを公開する サービス利用側の手順 サービス利用側では原則的に「エンドポイントを作成する」だけです。 その他にも DNS の設定などを使用する場合は、追加の手順があります。詳細は以下のドキュメントを参照してください。 参考 : Private Service Connect を使用してマネージド サービスにアクセスする Private Service Connect backends 応用として Private Service Connect backends という手法を用いることもできます (かつては「コンシューマ HTTP(S) コントロールを使用する Private Service Connect エンドポイント」と呼称されていました)。 こちらですと、サービス利用側は外部 HTTP(S) ロードバランサをエンドポイントとして利用します。ロードバランサのバックエンドサービスとして「Private Service Connect NEG」を利用することで実現します。 メリットとしては「サービスを柔軟に任意の URL にマップできる」「Cloud Logging に全リクエストをロギングできる」「任意の SSL/TLS 証明書を利用できる」「段階的に Private Service Connect にホストされたサービスへ移行できる」などがあります。 詳細は以下のドキュメントを参照してください。 参考 : About backends 参考 : 初めてのPrivate Service Connect #4 L7 PSC 編 Private Service Connect interfaces Private Service Connect interfaces は、Private Service Connect Endpoint とは逆で、サービス提供側 から開始 してサービス利用側へ通信する経路を確立する機能です。 サービス利用側のサブネットに ネットワークアタッチメント (network attachment) というコンポーネントを作成します。このコンポーネントには Internal IP アドレスが割り振られ、サービス提供側からの通信を中継します。 サービス提供側の Compute Engine VM は最低2つの NIC を持つ必要があり、うち一つが Private Service Connect interface であり、サービス利用側 (顧客側) との通信に使われます。一つの VM には7つまで Private Service Connect interface を作成できます。 当機能の詳細は、以下の公式ガイドを参照してください。 なお当機能は2023年6月現在、Preview であることにご留意ください。 参考 : About Private Service Connect interfaces 料金 サービス提供側 サービスアタッチメントで処理したデータ 1 GB につき $0.01 が発生します (上り・下りの両面)。 料金 | Virtual Private Cloud | Google Cloud Private Service Connect 自体にかかる料金は上記のみですが、これに加えてバックエンドのサーバ (Compute Engine 等) の利用料金や、内部ロードバランサの利用料金も発生しますのでご留意ください。 サービス利用側 エンドポイントに 1 時間あたり $0.01 の料金が発生します。 また処理したデータ 1 GB あたり $0.01 が発生します (上り・下りの両面)。 料金 | Virtual Private Cloud | Google Cloud 杉村 勇馬 (記事一覧) 執行役員 CTO / クラウドソリューション部 部長 元警察官という経歴を持つ現 IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 12資格、Google Cloud認定資格11資格。X (旧 Twitter) では Google Cloud や AWS のアップデート情報をつぶやいています。 Follow @y_sugi_it

G-gen の杉村です。ある Google Cloud 組織でサービスアカウントキーを発行しようとしたところ 不明なエラーです。 というメッセージと共に作成が失敗した事象が起きました。原因と対策を紹介します。 事象 調査 サービスアカウントキー作成の失敗ログ 同時刻のログに解決の糸口 原因と対処 事象 サービスアカウントからサービスアカウントキー (秘密鍵) を生成しようとしたところ、以下のメッセージが出て作成できなかった。 `不明なエラーです。` `操作に失敗しました。もう一度お試しください。` メッセージは 不明なエラーです。 操作に失敗しました。もう一度お試しください。 追跡番号 xxxxxxxxxxxxxxxx のみだ。 またコンソールだけでなく、gcloud コマンドでのキー生成を試みてもエラーとなる。 $ gcloud iam service-accounts keys create ./sa-key.json \ > --iam-account=my-service-account@my-project.iam.gserviceaccount.com \ > --project=my-project ERROR: ( gcloud.iam.service-accounts.keys.create ) FAILED_PRECONDITION: Precondition check failed. 調査 サービスアカウントキー作成の失敗ログ 同プロジェクトの Cloud Logging をクエリすると、以下のログが出ている (一部を伏せ字・仮の値に置き換えている)。 サービスアカウントキーの作成が Precondition check failed. というメッセージ (“前提条件のチェックに失敗” の意味) と共にコード 9 で失敗していることが分かるが、それ以上は分からない。 { " protoPayload ": { " @type ": " type.googleapis.com/google.cloud.audit.AuditLog ", " status ": { " code ": 9 , " message ": " Precondition check failed. " } , " authenticationInfo ": { " principalEmail ": " my-account@my-domain.com ", " principalSubject ": " user:my-account@my-domain.com " } , " requestMetadata ": { " callerIp ": " x.x.x.x ", " callerSuppliedUserAgent ": " Mozilla/5.0 (X11; CrOS x86_64 15183.59.0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/108.0.0.0 Safari/537.36,gzip(gfe) ", " requestAttributes ": { " time ": " 2022-12-14T08:42:34.568951085Z ", " auth ": {} } , " destinationAttributes ": {} } , " serviceName ": " iam.googleapis.com ", " methodName ": " google.iam.admin.v1.CreateServiceAccountKey ", " authorizationInfo ": [ { " resource ": " projects/-/serviceAccounts/123456789012345678901 ", " permission ": " iam.serviceAccountKeys.create ", " granted ": true , " resourceAttributes ": { " name ": " projects/-/serviceAccounts/123456789012345678901 " } } ] , " resourceName ": " projects/-/serviceAccounts/123456789012345678901 ", " request ": { " private_key_type ": 2 , " @type ": " type.googleapis.com/google.iam.admin.v1.CreateServiceAccountKeyRequest ", " name ": " projects/my-project/serviceAccounts/123456789012345678901 " } , " response ": { " @type ": " type.googleapis.com/google.iam.admin.v1.ServiceAccountKey " } } , " insertId ": " abcd123456789 ", " resource ": { " type ": " service_account ", " labels ": { " email_id ": " my-service-account@my-project.iam.gserviceaccount.com ", " project_id ": " my-project ", " unique_id ": " 123456789012345678901 " } } , " timestamp ": " 2022-12-14T08:42:34.548887889Z ", " severity ": " ERROR ", " logName ": " projects/my-project/logs/cloudaudit.googleapis.com%2Factivity ", " receiveTimestamp ": " 2022-12-14T08:42:36.473110470Z " } 同時刻のログに解決の糸口 しかし、上記ログとほぼ同タイミングで、以下のようなログが出力されていた。ほぼ同時刻であるためコンソールの Cloud Logging のログエクスプローラーで隣り合った位置に出力されており、特にクエリでログを絞っていなかったため気がつくことができた。 { " protoPayload ": { " @type ": " type.googleapis.com/google.cloud.audit.AuditLog ", " status ": { " code ": 7 , " message ": " PERMISSION_DENIED " } , " authenticationInfo ": {} , " requestMetadata ": { " callerIp ": " private ", " requestAttributes ": {} , " destinationAttributes ": {} } , " serviceName ": " resourcesettings.googleapis.com ", " methodName ": " google.cloud.resourcesettings.v1alpha1.ResourceSettingsService.LookupEffectiveSettingValue ", " resourceName ": " projects/123456789012 ", " metadata ": { " @type ": " type.googleapis.com/google.cloud.audit.OrgPolicyRestrictionAuditMetadata ", " violationReason ": " SERVICE_USAGE_RESTRICTION_VIOLATED ", " resourceNames ": [ " projects/123456789012/settings/iam-serviceAccountKeyExpiry " ] } , " policyViolationInfo ": { " orgPolicyViolationInfo ": { " violationInfo ": [ { " constraint ": " constraints/gcp.restrictServiceUsage ", " errorMessage ": " Resource Usage Restriction Org Policy is violated ", " policyType ": " LIST_CONSTRAINT " } ] } } } , " insertId ": " 123456789abc ", " resource ": { " type ": " audited_resource ", " labels ": { " project_id ": " my-project ", " service ": " resourcesettings.googleapis.com ", " method ": " google.cloud.resourcesettings.v1alpha1.ResourceSettingsService.LookupEffectiveSettingValue " } } , " timestamp ": " 2022-12-14T08:42:34.705300886Z ", " severity ": " ERROR ", " logName ": " projects/my-project/logs/cloudaudit.googleapis.com%2Fpolicy ", " receiveTimestamp ": " 2022-12-14T08:42:35.286107268Z " } これは、組織のポリシー constraints/gcp.restrictServiceUsage の制限によって API resourcesettings.googleapis.com が拒否されたことを示すログだ。 確かに、今回事象が起きた Google Cloud 組織では 組織のポリシー constraints/gcp.restrictServiceUsage (利用可能な Google Cloud サービスを制限するポリシー) を使って、環境利用者が特定の Google Cloud サービスしか使えないように制限をかけていた。このポリシーが、原因に関係しそうだ。 参考 : Restricting resource usage 二種類のログがセットで出力されていたことに気がついた 原因と対処 対処法を先に書くと、組織ポリシー constraints/gcp.restrictServiceUsage の許可リストに resourcesettings.googleapis.com を追加すると、事象は解決した。 Resource Settings API は Google Cloud リソースの振る舞いを管理する API であり、VM、VPC Firewall、プロジェクトなど様々なリソースの管理のため、バックエンドで用いられている。 また、我々ユーザーも同 API を利用することにより、リソース作成時のデフォルトのロケーションを設定するなど、組織で一貫した設定値を管理することができる。 参考 : リソースの設定の概要 今回の事象の原因は、組織ポリシー constraints/gcp.restrictServiceUsage によってバックエンドで用いられている Resource Settings API が禁止されてしまっていたためだった。そのため同 API を示す resourcesettings.googleapis.com を許可リストに追加することで、事象が解決した。 ほとんどの場合で Google Cloud API は適切なエラーログを出力するため、トラブルに遭遇したらまずを Cloud Logging を精査するのが得策だ。 杉村 勇馬 (記事一覧) 執行役員 CTO / クラウドソリューション部 部長 元警察官という経歴を持つ現 IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 12資格、Google Cloud認定資格11資格。Twitter では Google Cloud や AWS のアップデート情報をつぶやいています。 Follow @y_sugi_it

G-gen の杉村です。Compute Engine VM を自動で管理・運用するための機能である VM Manager について徹底解説します。 概要 VM Manger とは OS Config エージェント 料金 パッチ（Patch） パッチ（Patch）とは パッチ コンプライアンス レポート パッチ デプロイ 概要 適用タイミング 対象 VM の指定 アップデート 前処理・後処理 OS Inventory Management OS Inventory Management とは 閲覧方法 OS ポリシー（OS policies） OS ポリシーとは 構成要素 OS ポリシー OS ポリシーの割り当て ロールアウト エージェントと情報収集 有効化 概要 サービス API の有効化 OS Config エージェント プロジェクト全体でメタデータを設定 VM 単位でメタデータを設定 組織レベルでメタデータを設定 ネットワーク要件 VM にサービスアカウントをアタッチ 組織で VM Manager を利用する 組織レベルまたはプロジェクトレベルで VM Manager を有効化する 組織レベルでのパッチ情報閲覧 OS ポリシーの利用 Policy orchestrator 概要 VM Manger とは VM Manager は、Google Cloud（旧称 GCP）の Compute Engine VM 群の管理・運用を自動化するためのサービスです。 参考 : VM Manager VM Manager は、CentOS、RHEL、Debian、Ubuntu などの各種 Linux ディストリビューションに加えて、Windows Server にも対応しています。対応 OS の一覧は以下のドキュメントから確認できます。 参考 : オペレーティング システムの詳細 VM Manager には、大きく分けて以下の機能が存在します。 No 機能名 用途 利用方法 1 パッチ（Patch） OS やパッケージへのパッチ適用自動化やレポーティング Google Cloud コンソールの「パッチ」、gcloud、REST API 2 OS Inventory Management OS やパッケージの情報収集 Google Cloud コンソールの VM 詳細画面、gcloud、REST API 3 OS ポリシー（OS policies） パッケージのインストール・削除・更新 Google Cloud コンソールの「OS ポリシー」、gcloud、REST API Patch はかつて OS patch management と、OS policies は OS configuration management と呼ばれていましたが2023年9月に機能名が改名されました。 なお Amazon Web Services（AWS）にも類似のサービスとして AWS Systems Manager があります。VM Manger は、AWS Systems Manager の Google Cloud 版とも言えます。 OS Config エージェント VM Manager の機能を実現するため、OS 上には OS Config エージェント と呼ばれるエージェントソフトウェアをインストールします。このエージェントが Google Cloud と通信し、様々な管理タスクを実行します。 OS Config エージェントは、特定日以降（ビルド日付が v20200114 以降）の Ubuntu、Debian、RHEL、Windows Server などの Google Cloud 公式イメージにはプリインストール済みです。 詳細なインストール手順や、ネットワーク要件等は後述します。 参考 : OS Config エージェントがインストールされているかどうかを確認する 料金 VM Manager では、VM Manager が有効化されている VM の台数 に対して発生します。 月に100台の無料枠 があり、100台を超える VM からは1台につき $0.003/時間の料金が発生します。31日ある月の場合、$0.003 × 744時間 = $2.232/台/月の料金が発生することになります。 課金が発生するのは無料枠を超えた 101台目のインスタンスから ですので、安価に大量の VM を管理できます。 参考 : VM Manager pricing パッチ（Patch） パッチ（Patch）とは パッチ （Patch）は Compute Engine VM の OS や、パッケージの管理をするための機能です。2023年9月までは OS Patch Management と呼ばれていました。 パッチには、以下の2つの主要機能があります。 パッチ コンプライアンス レポート パッチ デプロイ パッチ コンプライアンス レポート は VM OS やパッケージのパッチ状況を分析・レポーティングしてくれる機能です。 パッチ デプロイ は OS やパッケージのパッチ適用を自動化する仕組みです。いずれも VM 内で OS Config エージェントが動作し、yum や apt などのコマンドを実行して実現します。 参考 : Patch について パッチ コンプライアンス レポート パッチ コンプライアンス レポート は、VM の OS やインストール済みパッケージの情報をダッシュボード化する機能です。 VM Manager が有効化されると OS Config エージェントは 約10分ごと に各種情報を取得し、VM のメタデータの「ゲスト属性」に書き込みます。この情報は、後述の OS Inventory Management でも利用されます。 参考 : ゲスト属性 さらに VM Manager は、各 OS ごとに一般公開されている脆弱性情報と照合してレポートを作成します。脆弱性情報は RHEL、CentOS、Debian、Ubuntu で対応しており SLES、Rocky Linux、Windows Server では対応していません。 参考 : パッチ コンプライアンス データの生成方法 入手可能なアップデートがある場合、レポート上ではアップデートが「重大（赤）」「重要/セキュリティ（オレンジ）「その他（黄色）」「最新（緑）」に分類されます。 画像は 公式ドキュメント より引用 パッチ デプロイ 概要 パッチ デプロイ 機能は、 OS やミドルウェアに対して自動的なパッチ適用を行う機能です。 パッチ デプロイ機能は、Google Cloud コンソール、gcloud コマンド、REST API エンドポイント経由で、Patch API（OS Config API）を呼び出して実行します。 参考 : パッチジョブを作成する Patch API によりパッチデプロイが開始されると、Patch API は VM 内の OS Config エージェントに指示を出し、エージェントは apt、yum、Windows Update 等、OS 固有のパッケージ管理サービスを呼び出してアップデートを実行します。 そのため yum、apt といったパッケージ管理サービスがレポジトリにアクセスするために、当該 VM がインターネットにリーチできる（パブリック IP を持っているか、Cloud NAT 経由）、またはローカルレポジトリを用意する必要があります。 適用タイミング パッチ デプロイ機能によるパッチ適用は、 オンデマンド実行 （即時実行）するか、事前に スケジュール指定 することができます。また、繰り返し予定としてスケジューリングすることも可能です。 オンデマンド実行は「 同時パッチ適用 （Simultaneous patching）」、スケジュール実行は「 定期パッチ適用 （Scheduled patching）」とも呼ばれます。 参考 : 同期パッチ適用 参考 : 定期パッチ適用 対象 VM の指定 パッチ適用の対象インスタンスは次のいずれかの方法で指定します。 プロジェクトに所属する全 VM を指定 単一のインスタンスを指定 インスタンス名のプレフィクス（接頭辞）で指定 ゾーン単位で指定 ラベルで指定 また、対象となった VM 群のうち一度に停止する VM 数の割合を % で指定することができます。これにより一斉に VM が停止してしまうことを防ぐことができます。 ラベルについては、以下の記事を参照してください。 参考 : タグとラベルの違いについて (Tags / Labels) アップデート アップデートのパッケージは、特定の名称を指定したり、Windows の場合では KB 番号を指定することもできます。 例として、Debian/Ubuntu ではディストリビューションやパッケージマネージャーから配布されるアップデートが対象であり、Windows では定義更新プログラム、ドライバー更新プログラム、機能パックの更新、などが対象です。 対象となるパッケージ種別は以下のドキュメントを参照してください。 参考 : OS パッチジョブの内容 パッチ構成指定画面 前処理・後処理 アップデートを適用した VM の挙動として「再起動なし」「常に再起動」「必要なら再起動」のいずれかから指定することができます。 また、パッチ適用前、あるいは適用後（再起動があれば再起動後）に実行するスクリプトを指定することもできます。スクリプトは Cloud Storage バケットに配置します。 OS Inventory Management OS Inventory Management とは OS Inventory Management は、OS レベルの各種情報や、パッケージ情報を詳細に収集・表示するための機能です。また、パッケージに関する脆弱性情報を表示することもできます。 プロジェクトレベルまたは VM レベルで VM Manager が有効化されると、情報収集が開始されます。 参考 : OS Inventory Management OS Inventory Management では、OS Config エージェントがおよそ10分間隔で収集した以下の情報を表示可能です。 OS 情報 ホスト名 LongName (OS の詳細名称。例 : Microsoft Windows Server 2016 Datacenter) ShortName (OS の短縮名。例 : Windows) カーネルバージョン OS のアーキテクチャ OS バージョン OS Config エージェントのバージョン Last updated (OS Config エージェントが最後に情報を更新した時間) パッケージ情報 パッケージマネージャー（RPM、yum、DEB、apt、GooGet for Windows Server）取得する情報 Windows Server で取得可能な以下の情報 Windows Update Agent Windows Quick Fix Engineering アップデート Windows Installer 閲覧方法 OS Inventory Management の情報を閲覧するには、Google Cloud コンソールの VM 詳細画面で「OS 情報」タブへ遷移します。 また gcloud または REST API を利用することで、特定ゾーンにある VM の情報を一覧取得することもできます。 参考 : オペレーティング システムの詳細を表示する OS Inventory Management の情報閲覧 OS ポリシー（OS policies） OS ポリシーとは OS ポリシー （OS policies）機能は、VM のパッケージ構成のデプロイ、メンテナンス、レポート作成を行うことができる機能です。2023年9月までは OS Configuration Management という名称でした。 参考 : OS ポリシーについて OS ポリシーという定義ファイル（JSON または YAML）により VM のパッケージ構成のあるべき姿を定義して VM に適用すると、その状態とのずれが発生したときに、自動的に是正アクションが実行されます。 前述のパッチ デプロイ機能がオンデマンドあるいは定期的にアップデート指示を配信するものであるのに対して、OS ポリシー機能は あるべき姿を定義してずれをなくしていく というコンセプトです。 以下のようなユースケースが想定されています。 モニタリングエージェントやセキュリティエージェント等のインストール・保守 スタートアップスクリプトの管理 コンプライアンスチェック パッケージレポジトリの管理 ファイルの配信 スクリプト実行によるサーバ内の状態維持 構成要素 OS ポリシー OS ポリシー ファイルは、VM のパッケージ構成のあるべき姿を宣言的に定義するファイルです。OS ポリシーは JSON または YAML 形式で記述します。 参考 : OS ポリシー OS ポリシーファイルは、以下の2つのモードのいずれかとして定義します。 モード名 意味 Validation リソースが望ましい状態かチェックする。是正アクションは行わない Enforcement リソースが望ましい状態かチェックする。望ましい状態でなければ是正アクションを実行する また OS ポリシー内には以下の リソース を定義でき、実施するチェックまたはアクションを定義できます。 リソース名 意味 pkg パッケージのインストールまたは削除を行う（Linux、Windows の両方で利用可能） repository パッケージを取得するレポジトリを指定する exec /bin/sh （Linux）または Powershell（Windows）を実行する file サーバー上のファイルを管理する 以下は、YAML 形式で定義した OS ポリシーファイルのサンプルです。以下のドキュメントから引用しています。以下のサンプルでは、Cloud Storage から MSI ファイルをダウンロードして、サーバーにインストールします。 参考 : Example OS policies # An OS policy to install a Windows MSI downloaded from a Google Cloud Storage bucket. id : install-msi-policy mode : ENFORCEMENT resourceGroups : - resources : - id : install-msi pkg : desiredState : INSTALLED msi : source : gcs : bucket : my-bucket object : my-app.msi generation : 1619136883923956 OS ポリシーの割り当て OS ポリシーの割り当て （OS policy assignment）は OS ポリシーを実際に VM に適用する際に作成する設定です。 1 個の OS ポリシー割り当てで複数の OS ポリシーを指定できます。また適用対象の VM は以下の軸で選択することができます。 ゾーン OS ファミリー ラベル（含める） ラベル（除外） 例えば以下のような指定をすると「 asia-northeast-1-b ゾーンにある」「 ubuntu の VM で」「 env:test というラベルを持ち」「かつ goog-gke-node というラベルを持たない」に当てはまるすべての VM に、OS ポリシーを適用できます。 ゾーン : asia-northeast-1-b OS ファミリー : ubuntu ラベル（含める）: env:test ラベル（除外）: goog-gke-node 参考 : OS policy assignment ロールアウト OS ポリシーの割り当てを作成する際に以下の ロールアウトオプション を設定することができます。 ウェーブサイズ 待機時間 ウェーブサイズは一度にポリシーを適用する VM の割合です。対象となる VM のうち、何割が同時にアップデート等の対象になるかを指定できます。デフォルトは10%です。 待機時間は、ポリシー適用開始から実際にロールアウトが始まるまでの猶予時間です。ウェーブサイズごとにポリシー適用が始まり、最初のウェーブで問題が発生した際などに、次のウェーブが始まるまでにロールアウトを中止することが可能になります。 エージェントと情報収集 OS ポリシーの取得と実行は、VM 上の OS Config エージェントが行っています。OS ポリシーの割り当てが作成されると、VM では 60分のチェック間隔 でポリシー確認と適用が実行されます。 ポリシーが VM に配信されると、OS Config エージェントは VM の内部状況を確認し、ポリシー通りの状態になっていれば何もせず、ポリシーとの差異があれば是正アクションを実行します。 有効化 概要 以下のすべての条件を満たしていると、VM Manager のすべての機能が利用できるようになります。 Google Cloud プロジェクトで OS Config Service API が有効化されている 対象 VM に OS Config エージェントがインストールされている プロジェクト単位または VM 単位で、必要な Compute Engine メタデータが設定されている VM がネットワーク要件を満たしている VM にサービスアカウントがアタッチされている 詳細な手順は、以下の公式ドキュメントに記載されています。当記事では概要を解説します。 参考 : VM Manager を設定する サービス API の有効化 Compute Engine API に加えて、以下サービスの API を有効化する必要があります。有効化は、Google Cloud コンソールの API とサービス の画面から行ったり、gcloud コマンドラインで行うことができます。 OS Config Service API ( osconfig.googleapis.com ) OS Config エージェント VM を VM Manager 機能の対象とするには、VM に OS Config エージェントをインストールします。 Google Cloud 公式のイメージで VM を作成した場合、ビルド日付が v20200114 以降の CentOS、Container-Optimized OS、Debian、Red Hat Enterprise Linux （RHEL）、Rocky Linux、SLES、Ubuntu、Windows Server には既にエージェントがインストール済みです。 もしこれ以外のイメージの場合、以下のドキュメントを参考にしてエージェントをインストールします。 参考 : OS Config エージェントをインストールする VM Manager の各機能がサポートする OS 一覧は、以下の公式ドキュメントに記載されています。 参考 : オペレーティング システムの詳細 プロジェクト全体でメタデータを設定 プロジェクトに所属する全ての VM を管理対象にする場合は、以下の手順を実施します。実施すると、既存の VM に加え今後作成される全ての VM が自動的に対象になります。 該当プロジェクトの Compute Engine コンソールにて「メタデータ」ページに移動します。ここで以下のメタデータを追加します。 enable-osconfig : TRUE メタデータ とは、Compute Engine に設定できる Key-Value のテキスト情報です。プロジェクト単位または VM 単位で、各種メタデータを登録できます。 なお、以前のバージョンの OS Inventory Management 機能では enable-guest-attributes : TRUE というメタデータも追加する必要がありましたが、現在のバージョンでは不要です。 参考 : メタデータ値を設定する VM 単位でメタデータを設定 プロジェクト全体ではなく、個別の VM 単位で有効化したい場合は対象 VM のレベルでメタデータを設定します。メタデータは、VM の新規作成時に追加することもできますし、既存 VM に追加することもできます。 プロジェクト全体レベルでメタデータを追加済みの場合は、当手順を行う必要はありません。 コンソールでは、VM 編集画面からカスタムメタデータを設定できます。追加するメタデータはプロジェクト全体のときと同様で、 enable-osconfig : TRUE です。 組織レベルでメタデータを設定 後述する 組織のポリシー 機能を使うと、組織やフォルダ配下で今後作成されるすべてのプロジェクトにメタデータを自動で追加することができます。 当記事の 組織で VM Manager を利用する の章をご参照ください。 ネットワーク要件 OS Config エージェントが Google Cloud の API と通信できるよう、VM が通信要件を満たしている必要があります。 VM が外部 IP を持っていたり、Cloud NAT 経由でインターネットに出られるようになっていれば問題有りません。そうではない場合、以下のいずれかの方法で VM 内の OS Config エージェントが OS Config API と通信できるようにします。 HTTP プロキシを利用 サブネットで 限定公開の Google アクセス を有効化 VM で HTTP プロキシを利用する方法については、以下のドキュメントを参照してください。 参考 : HTTP プロキシを構成する 限定公開の Google アクセス機能については、以下の記事を参照してください。 参考 : 限定公開の Google アクセスの仕組みと手順をきっちり解説 VM にサービスアカウントをアタッチ 対象 VM に サービスアカウント がアタッチされている必要があります。 ただしこのサービスアカウントには IAM ロールの紐づけは不要です。サービスアカウントは OS Config API との通信に署名をするためだけに用いられるため、IAM ロールが全く付与されていない空のサービスアカウントでも問題ありません。 組織で VM Manager を利用する 組織レベルまたはプロジェクトレベルで VM Manager を有効化する 組織のポリシー 機能を使うことで、組織やフォルダ全体で VM Manager を有効化できます。組織のポリシー機能については、以下の記事も参照してください。 blog.g-gen.co.jp 組織レベルまたはフォルダレベルで Require OS Config （ constraints/compute.requireOsConfig ）制約を TRUE に設定すると、新規に作成されるプロジェクトに、自動的に enable-osconfig : TRUE メタデータが追加されます。 また、 enable-osconfig を FALSE に変えるような設定は拒否されます。 ただし、この組織のポリシーの制約を有効化する前から存在した 既存の Google Cloud プロジェクトのメタデータは変更されません 。既存プロジェクトで VM Manager を有効化したい場合は、 個別にメタデータを追加する必要 があります。プロジェクトの数が多い場合、gcloud コマンドラインや各プログラミング言語用のクライアントライブラリを用いて、プログラマブルにプロジェクトにメタデータを追加することを検討してください。 加えて、この組織のポリシーの制約で有効化できるのはメタデータのみです。前述した OS Config エージェントの要件やネットワーク要件は 個別の VM ごとに満たしている必要 があります。 参考 : 組織のポリシーを使用して VM Manager を有効にする 組織レベルでのパッチ情報閲覧 パッチのサマリ情報を、 組織レベル または フォルダレベル で閲覧することができます。 組織、フォルダ、プロジェクトに対して適切な権限を持っていれば、特別な設定をすることなく、プロジェクトをまたいだ情報確認ができます。Google Cloud コンソール画面の「パッチ」から「プロジェクト」タブを選択したうえで、画面上部のプロジェクトセレクタで、組織またはフォルダを選択します。 この画面では、各プロジェクトの VM の合計、VM Manager のモニタリング対象となっている VM の数、「重大」「重要」など各レベルで検知されているパッケージアップデートの数などのサマリが確認できます。 組織レベルでのパッチサマリ なお「VM の合計」はプロジェクトで VM Manager が有効でなくても確認できますが、App Engine のカスタムランタイムで起動された VM 等もカウントされる場合があります。 組織またはフォルダ配下のすべてのプロジェクトで VM Manager が有効になっていない場合は、有効になっているプロジェクトの情報のみが表示されます。 また、同画面の Query Builder を使うと、OS や OS のバージョン、CVE で脆弱性が報告されている VM などをフィルタして表示することができます。 Query Builder さらに、Google Cloud コンソール画面の「パッチ」＞「ダッシュボード」タブでは、組織やフォルダの配下にある全 VM の OS の総数や、パッチ適用状況を確認できます。ただし、VM Manager が有効になっていないプロジェクトや VM の情報は表示されません。 「パッチ」＞「ダッシュボード」タブ 参考 : View patch summary for VMs in an organization or folder OS ポリシーの利用 OS ポリシーの遵守状況を、 組織レベル または フォルダレベル で閲覧することができます。 パッチ機能と同様に、組織、フォルダ、閲覧対象のプロジェクトに対して適切な権限を持っていれば、プロジェクトをまたいだ情報確認ができます。Google Cloud コンソール画面の「OS ポリシー」から「プロジェクト」タブを選択したうえで、画面上部のプロジェクトセレクタで、組織またはフォルダを選択します。 参考 : View OS policy compliance summary for all VMs in an organization or folder Policy orchestrator Policy orchestrator を使うと、複数のゾーンやプロジェクトをまたいで OS ポリシーを適用することができます。通常、OS ポリシーの割り当てはゾーンレベルですが、フォルダレベルで Policy orchestrator を作成することで、複数のゾーンやプロジェクトに対して OS ポリシーを適用できます。 適用範囲を調整することで、一部のプロジェクトでテスト適用を行い、うまくいったら範囲を広げるといった、順次ロールアウトも可能です。詳細は以下の公式ドキュメントを参照してください。 なお当機能は2024年11月現在、Preview 状態です。 参考 : About policy orchestrator 杉村 勇馬 (記事一覧) 執行役員 CTO / クラウドソリューション部 部長 元警察官という経歴を持つ現 IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 12資格、Google Cloud認定資格11資格。X (旧 Twitter) では Google Cloud や AWS のアップデート情報をつぶやいています。 Follow @y_sugi_it

当記事では、Google Cloud（旧称 GCP）の BigQuery に特定の IP アドレスからのアクセスのみを許可する VPC Service Controls を設定しつつ、Looker Studio には IP アドレスの制限をかけずレポートを閲覧できるようにする方法を紹介します。 サービス・機能の概要 VPC Service Controls Looker Studio サービスアカウントの権限借用 VPC Service Controls と Looker Studio 実施内容 構成図 事前準備 Cloud Storage の設定 BigQuery の設定 Looker Studio でレポートの作成 パターン１ VPC Service Controls の設定 確認 パターン２ サービスアカウントの作成 VPC Service Controls の設定 Looker Studio サービス エージェントにサービス アカウントへのアクセスを許可 ユーザーロールの付与 BigQuery へのアクセスを許可 Looker Studio のデータの認証情報を更新 確認 パターン３ Looker Studio でレポートの共有 確認 監査ログ Looker Studio のログイベント 注意点 サービス・機能の概要 当記事で使用するサービスや機能の概要は以下の通りです。 VPC Service Controls VPC Service Controls は Google Cloud のセキュリティ機能です。 境界 (Perimeter) と呼ばれる論理的な囲いを作り、その囲いの中のリソースへのアクセスを IP アドレスやサービスアカウント等に制限することができます。 詳細ついては以下の記事をご参照ください。 blog.g-gen.co.jp Looker Studio Looker Studio （旧称 データポータル）は Google Cloud が提供する BI ツールです。 Google スプレッドシートや BigQuery 等のデータソースからレポートを作成し、データの可視化をすることができます。 以下の記事で Looker Studio について触れていますので、ご参照ください。 blog.g-gen.co.jp blog.g-gen.co.jp Looker Studio のデータの認証情報には以下の３種類があります。 オーナーの認証情報 閲覧者の認証情報 サービス アカウントの認証情報 後述しますが、当記事では「サービス アカウントの認証情報」を使用します。 なお、現在 サービス アカウントの認証情報はデータソースが BigQuery の場合にのみ使用できます 。 また、サービスアカウントの認証情報を利用するにあたり必要な Looker Studio サービス エージェントを取得するには、Workspace または Cloud Identity のユーザーである必要があります 。 参考： データの認証情報 Looker Studio サービス エージェントをサービスアカウントのプリンシパルに追加することで、サービスアカウントを使用して Looker Studio のレポートを閲覧および編集等ができるようになります。 参考： Looker Studio 用に Google Cloud サービス アカウントを設定する Looker Studio サービス エージェントについては以下の記事でも触れていますので、ご参照ください。 blog.g-gen.co.jp サービスアカウントの権限借用 Identity and Access Management （以下 IAM）には サービスアカウントの権限借用 という機能があります。本機能を使用することで、特定のサービスアカウントへの権限借用を許可されているプリンシパル（ユーザー等）は、そのサービスアカウントの権限を使用してリソースへアクセスすることができます。 参考： サービス アカウントの権限借用の管理 IAM の基本的な概念については以下の記事をご参照ください。 blog.g-gen.co.jp VPC Service Controls と Looker Studio それぞれのサービスや機能を確認したところで、当記事で紹介する内容について触れていきます。 Looker Studio のデータソースに BigQuery を使用した場合、 BigQuery が VPC Service Controls の境界内にあると Looker Studio にも同様の制限がかかります 。 具体的には、BigQuery に特定の IP アドレスからのアクセスのみを許可する VPC Service Controls を設定した場合、Looker Studio にも同様の IP アドレスの制限がかかります。 理由は、Looker Studio のレポートの編集や保存、閲覧時に BigQuery に対するクエリが実行されるからです。 許可されていない IP アドレスから Looker Studio のレポートを閲覧すると以下のように Service Control のエラー と表示されます。 Looker Studio の VPC Service Controls のエラー画面 参考： Google BigQuery に接続する 実施内容 当記事では、以下の内容を実現するための方法を紹介します。 VPC Service Controls を設定することで、 BigQuery へのアクセスは特定の IP アドレスからのみに制限 Looker Studio のサービスアカウントの認証情報を設定することで、ユーザーは IP アドレスの制限なく Looker Studio のレポートの操作および閲覧が可能 構成図 以下の３パターンを順に設定および確認していきます。 なお今回は VPC Service Controls と Looker Studio に焦点を当てて紹介するため、他の部分の設定についての詳細は割愛します。 構成図（パターン１） 構成図（パターン２） 構成図（パターン３） 事前準備 Cloud Storage の設定 Cloud Storage（以下 GCS）でバケットの作成およびオブジェクトをアップロードします。 今回はオブジェクトに「sample-data.csv」としてランダムに生成された販売実績データの csv ファイルを使用しています。 GCS の画面 BigQuery の設定 BigQuery でデータセット「fujioka_dataset_01」を作成し、GCS の「sample-data.csv」をソースとするテーブル「table-01」を作成します。 BigQuery の画面 テーブルの中身は以下のようになっています。 テーブルの画面 Looker Studio でレポートの作成 Looker Studio にログインし、レポートを作成します。 Looker Studio レポート作成画面 データのレポートへの追加 で [BigQuery] を選択します。 データに接続 対象のプロジェクト、データセット、テーブルを選択します。 レポートへ BigQuery のテーブルを追加 円グラフを作成しました。 レポート画面 ここまでで、以下の構成が出来上がりました。 ここまでの構成 パターン１ VPC Service Controls の設定 Access Context Manager でアクセスレベルの作成をします。 今回はアクセスポリシーに default policy を使用するため、VPC Service Controls および Access Context Manager は組織レベルで設定をします。 コンソールで [セキュリティ] > [Access Context Manager] > [+ アクセスレベルを作成] を選択します。 Access Context Manager の画面 新しいアクセスレベル を以下のように設定します。 なお、この IP サブネットワークに プライベート IP 範囲を含めることはできません。 参考： アクセスレベルの属性 項目 設定値 備考 アクセスレベルのタイトル fujioka-home 任意の名前 IP サブネットワーク xxx.xxx.xxx.6/32 アクセスを許可する IPv4 または IPv6 を設定 アクセスレベル 次に [セキュリティ] > [VPC Service Controls] > [+ 新しい境界] を選択します。 VPC Service Controls の画面 新しい VPC サービス境界 を以下のように設定します。 ① Details 項目 設定値 備考 境界のタイトル fujioka-vpcsc 任意の名前 境界のタイプ 標準境界（デフォルト） ① Details ② Projects 項目 設定値 備考 保護するプロジェクト fujioka 対象のプロジェクト ② Projects ③ Restricted Services 項目 設定値 備考 保護するサービス BigQuery API Google Cloud Storage API BigQuery と GCS を境界内に入れる ③ Restricted Services ④ VPC accessible services [すべてのサービス] を選択します。 ④ VPC accessible services ⑤ Access Levels 設定しないで進みます。 ⑤ Access Levels ⑥ 内向きポリシー 今回は、GCP サービス / リソースの TO 属性 のメソッドを All methods にしていますが、 Selected method にすることでより細かに操作を絞ることができます。 ⑥ 内向きポリシー ⑦ 下り（外向き）ポリシー 設定しないで進みます。 ⑦ 下り（外向き）ポリシー 確認 ここまでで、以下の構成が出来上がりました。 構成図（パターン１） アクセスレベルで 許可されていない IP アドレスからレポートを見ると Service Control のエラー と表示されます。 エラー画面が表示されない場合は、ブラウザの更新やディメンションの変更等をお試しください。 Looker Studio の VPC Service Controls のエラー画面 パターン２ 次に、BigQuery と GCS への IP アドレス制限はかけながら、 Looker Studio への IP アドレス制限をかけない ようにします。 サービスアカウントの作成 コンソールで [IAM と管理] > [サービスアカウント] > [+ サービスアカウントを作成] を選択します。 サービスアカウントを作成 任意の サービスアカウント名 および サービスアカウント ID を設定します。 今回は、 looker-studio-sa@<プロジェクト ID>.iam.gserviceaccount.com というサービスアカウントを作成します。 サービスアカウントの作成① ロールは BigQuery ジョブユーザー を設定します。 サービスアカウントの作成② VPC Service Controls の設定 次に、パターン１で作成した fujioka-vpcsc の VPC Service Controls に新しく作成したサービスアカウントからのアクセスを許可する設定を入れます。 VPC Service Controls の画面 [境界を編集] を選択します。 境界を編集 ⑥ 内向きポリシー で [ADD RULE] をし、以下の設定を追加します。 API クライアントの FROM 属性 の ユーザーアカウント / サービスアカウント に作成したサービスアカウント looker-studio-sa@<プロジェクト ID>.iam.gserviceaccount.com を選択します。 ⑥ 内向きポリシー の画面 Looker Studio サービス エージェントにサービス アカウントへのアクセスを許可 Looker Studio サービス エージェントのヘルプページ で表示される Service Agent service-org-<組織 ID>@gcp-sa-datastudio.iam.gserviceaccount.com をコピーします。 Google アカウントでログインしていない場合はログインをしてから、再度ページを開いてください。 Looker Studio Service Agent の画面 コンソールから、作成したサービスアカウント looker-studio-sa@<プロジェクト ID>.iam.gserviceaccount.com に Looker Studio サービス エージェントのアクセスを許可する設定をします。 サービスアカウントの権限画面 Looker Studio サービス エージェントに iam.serviceAccount.getAccessToken 権限を付与するロールを選択します。今回は サービス アカウント トークン作成者 ロールを選択していますが、この権限を付与する任意のカスタムロールも使用できます。 項目 設定値 備考 新しいプリンシパル service-org-<組織 ID>@gcp-sa-datastudio.iam.gserviceaccount.com Looker Studio サービス エージェント ロール サービス アカウント トークン作成者 アクセスの許可画面 ユーザーロールの付与 次に、作成したサービスアカウント looker-studio-sa@<プロジェクト ID>.iam.gserviceaccount.com の権限借用をするユーザーを設定します。 サービスアカウントの権限画面 データソース（BigQuery）を作成または編集する Looker Studio ユーザーに、 iam.serviceAccounts.actAs 権限を含むロールを付与 します。今回は サービス アカウント ユーザー のロールを付与します。 なお、後述のパターン３のような Looker Studio のレポートの表示のみ行うユーザーには、サービス アカウントの権限は不要 です。 項目 設定値 備考 新しいプリンシパル fujioka@xxxx Google アカウント ロール サービス アカウント ユーザー アクセスの許可画面 BigQuery へのアクセスを許可 Looker Studio からサービスアカウントで BigQuery データへのアクセスを許可するには、テーブルまたはデータセットレベルでサービス アカウントに BigQuery データ閲覧者 のロールを付与します。 今回はテーブルレベルでロールを付与するため、今回の Looker Studio のレポートのソースであるテーブル table-01 に対して行います。 [BigQuery] > [fujioka_dataset_01] > [table-01] > [共有] を選択します。 テーブルへアクセス権付与 [プリンシパルを追加] を選択します。 プリンシパルを追加 項目 設定値 備考 新しいプリンシパル looker-studio-sa@<プロジェクト ID>.iam.gserviceaccount.com 作成したサービスアカウント ロール BigQuery データ閲覧者 アクセスの許可画面 Looker Studio のデータの認証情報を更新 Looker Studio のレポート画面から [リソース] > [追加済みのデータソースの管理] を選択します。 Looker Studio のレポート画面 [編集] を選択します。 データソース データの認証情報が現在は作成者になっているため、サービスアカウントに変更します。ユーザーアイコンを選択します。 データの認証情報 [サービスアカウント認証情報] にチェックを入れ、作成したサービスアカウント looker-studio-sa@<プロジェクト ID>.iam.gserviceaccount.com を入力します。 ここで [サービスアカウント認証情報] が選択肢にない場合は、Looker Studio のレポートを開き直してください。 データの認証情報を更新 データの認証情報が以下のようにサービスアカウントに変更されました。 データの認証情報 確認 ここまでで、以下の構成が出来上がりました。 構成図（パターン２） パターン１では、アクセスレベルで 許可されていない IP アドレスからレポートを見ると Service Control のエラー と表示されていましたが、問題なく閲覧ができるようになりました。 Looker Studio のレポート画面 但し、構成図の通りアクセスレベルで 許可されていない IP アドレスから境界内の BigQuery や GCS は閲覧ができません。 BigQuery の閲覧不可（データセット表示されない） GCS の閲覧不可 パターン３ 最後のパターンは、Looker Studio のレポートを他のユーザーに共有した場合についてです。 Looker Studio でレポートの共有 レポートの画面から [共有] > [他のユーザーを招待] を選択します。 レポートの共有 今回は fujioka-dev ユーザーを 閲覧者 として共有しました。 ユーザーを追加 確認 共有されたユーザーで、アクセスレベルで 許可されていない IP アドレスからもレポートが閲覧できます。 Looker Studio のレポート画面 ここまでで、以下の構成が出来上がりました。 構成図（パターン３） 監査ログ 以下は、共有されたユーザーが xxx.xxx.xxx.57 の IP アドレスからレポートのコントロールプルダウン変更をした時の 監査ログ （Cloud Audit Logs）です。 protoPayload.requestMetadata.callerIp= は共有されたユーザーの IP アドレス xxx.xxx.xxx.57 です。 但し、 protoPayload.authenticationInfo.principalEmail="looker-studio-sa@<プロジェクトID>.iam.gserviceaccount.com" となっており、実行はサービスアカウントがしていることが確認できます。 { "protoPayload": { "@type": "type.googleapis.com/google.cloud.audit.AuditLog", "status": {}, "authenticationInfo": { "principalEmail": "looker-studio-sa@<プロジェクトID>.iam.gserviceaccount.com" }, "requestMetadata": { "callerIp": "xxx.xxx.xxx.57" }, "serviceName": "bigquerybiengine.googleapis.com", "methodName": "ExecutionService.Query", "authorizationInfo": [ { "resource": "projects/<プロジェクトID>/datasets/fujioka_dataset_01/tables/table-01", "permission": "bigquery.tables.getData", "granted": true } ], "resourceName": "projects/<プロジェクトID>/datasets/fujioka_dataset_01/tables/table-01", "request": { "@type": "type.googleapis.com/google.cloud.bi.v1.QueryRequest" } }, "insertId": "fjx8nse21hx8", "resource": { "type": "audited_resource", "labels": { "project_id": "<プロジェクトID>", "method": "ExecutionService.Query", "service": "bigquerybiengine.googleapis.com" } }, 〜省略〜 } 参考： AuditLog Looker Studio のログイベント 監査ログでは閲覧元 IP アドレスはわかりますが、 閲覧ユーザーは表示されません 。 閲覧ユーザーを確認したい場合は、Google Workspace 管理コンソール admin.google.com の Looker Studio のログイベント から確認できます。 管理コンソールの Looker Studio のログイベント画面 参考： Looker Studio のログイベント 以下の記事で Workspace レポートと監査ログについて触れていますので、ご参照ください。 blog.g-gen.co.jp 注意点 VPC Service Controls は Cloud Shell をサポートしていません 。Cloud Shell は境界外として扱われます。そのため、今回の構成で IP アドレスが許可されているアクセス元の Cloud Shell から以下のようなコマンドを実行したとしてもエラーになります。 fujioka@cloudshell:~ (fujiokaxxxx)$ bq ls BigQuery error in ls operation: VPC Service Controls: Request is prohibited by organization's policy. vpcServiceControlsUniqueIdentifier: xxxxxx fujioka@cloudshell:~ (fujiokaxxxx)$ fujioka@cloudshell:~ (fujiokaxxxx)$ gcloud storage ls ERROR: (gcloud.storage.ls) HTTPError 403: Request is prohibited by organization's policy. vpcServiceControlsUniqueIdentifier: xxxxxx fujioka@cloudshell:~ (fujiokaxxxx)$ エラー文 参考： Cloud Shell G-gen 編集部 (記事一覧) 株式会社G-genは、サーバーワークスグループとして「クラウドで、世界を、もっと、はたらきやすく」をビジョンに掲げ、クラウドの導入から最適化までを支援している Google Cloud 専業のクラウドインテグレーターです。

G-gen の杉村です。Google Cloud（旧称 GCP）の IAM には、 サービスエージェント という仕組みがあります。 概要 サービスエージェントとは サービスエージェントとサービスアカウントの違い Compute Engine 概要 永続ディスクの CMEK による暗号化・復号 VM の起動・停止スケジューリング Cloud Storage 概要 Pub/Sub 通知 CMEK による暗号化・復号 Cloud Logging 概要 サービスがバックエンドで利用 ログバケットの透過的な暗号化 (CMEK) ログシンクの書き込み ID Looker Studio 概要 データソースへの認証 概要 サービスエージェントとは サービスエージェント とは、Google Cloud サービスが内部的に用いる、特別なサービスアカウントです。プロダクトの API を有効化したときなどに自動的に作成されるため、ユーザーが意識することはあまりありませんが、初期設定時や仕組みの構築の際に、サービスエージェントに対して権限の付与が必要になることがあります。 サービスエージェントは、Google Cloud サービスが別のサービスを呼び出すときなどに使用されます。 サービスエージェントは通常、プロジェクトに所属しますが、組織レベルで作成されるサービスエージェントもあります。 なおサービスエージェントは別名として「Google マネージドサービスアカウント」または「Google が管理するサービス アカウント」とも呼ばれます。 参考 : Service agents サービスエージェントとサービスアカウントの違い サービスエージェントとサービスアカウントの違いは何でしょうか。 サービスエージェントは、サービスアカウントの 一種 です。サービスアカウントの方が広い概念です。 ユーザーが作成する通常のサービスアカウントは、Google Cloud コンソール画面の「IAM と管理 ＞ サービスアカウント」で一覧表示できます。 しかし、サービスエージェントは Google Cloud が管理する特殊なサービスアカウントのため、この一覧には表示されません。 また、プロジェクトの IAM ロール一覧画面（IAM と管理 ＞ IAM）でも、普段は非表示になっています。 Google 提供のロール付与を含める というチェックボックスをオンにすると、非表示だったサービスエージェントと IAM ロールの紐づき（バインディング）が表示されます。 Google 提供のロール付与を含める 当記事では、代表的な Google Cloud サービスで、サービスエージェントがどのように用いられているかを紹介します。 Compute Engine 概要 あるプロジェクトで Compute Engine API を有効化すると、プロジェクトに以下の名称のサービスアカウントが生成されます。これが、Compute Engine のサービスエージェントです。 service-(プロジェクト番号)@compute-system.iam.gserviceaccount.com なお Compute Engine の API を有効化すると (プロジェクト番号)-compute@developer.gserviceaccount.com という名称で、Compute Engine の デフォルトサービスアカウント が生成されますが、これとサービスエージェントは 別物 です。 デフォルトサービスアカウントは VM にアタッチするものですが、サービスエージェントは後述の用途のためにサービス側が使うものです。ユーザーが意識することはほとんどありません。 このサービスエージェントには最初から Compute Engine サービス エージェント というロールがプロジェクトレベルで付与されています。このロール紐づきを削除してしまうと、Compute Engine の正常な動作は保証されません。 参考 : Compute Engine サービス エージェント Compute Engine のサービスエージェントは、内部的に様々な用途に用いられていますが、普段はユーザーに意識されることはありません。 しかし、以下の用途の際にサービスエージェントを意識することがあります。 永続ディスクの CMEK による暗号化・復号 VM の起動・停止スケジューリング 永続ディスクの CMEK による暗号化・復号 以下のスクリーンショットは、永続ディスクの暗号化方式を CMEK での暗号化にするよう選択したときのメッセージです。 CMEK 暗号化にはサービスエージェントに鍵の利用権限が必要 Compute Engine サービスエージェントに、暗号鍵に対して Cloud KMS 暗号鍵の暗号化 / 復号（ cloudkms.cryptoKeyEncrypterDecrypter ）ロールが必要なことを示しています。ユーザーに代わってサービスエージェントがディスク I/O の都度、鍵を利用して透過的な暗号化・復号を行っているのです。 ここで権限を持たせる必要があるのは、VM にアタッチしたサービスアカウント ではなく、 サービスエージェント**である点に注意が必要です。 サービスエージェントが鍵に権限を持つ VM の起動・停止スケジューリング VM の自動起動・停止のスケジュールを設定する際にも、サービスエージェントが関係します。 参考 : VM インスタンスの起動と停止をスケジュールする Compute Engine ではコンソール等から、cron 形式で VM の自動停止・起動をスケジューリングできます。 このスケジューリング機能では、Google Cloud がユーザーに代わって VM を停止あるいは起動します。このときに、サービスエージェントの IAM 権限が使われます。 サービスエージェントにインスタンス停止・起動の IAM 権限が無い場合、以下のようなエラーメッセージが表示されます。 インスタンスのスケジュールで警告 Compute Engine System service account service-(PJ-NUMBER)@compute-system.iam.gserviceaccount.com needs to have [compute.instances.start,compute.instances.stop] permissions applied in order to perform this operation. このメッセージが出た場合、サービスエージェントに、プロジェクトレベルで Compute インスタンス管理者（v1） ( roles/compute.instanceAdmin.v1 ）などのロールを付与する必要があります。 Cloud Storage 概要 Cloud Storage にもサービスエージェントが存在します。名称は以下のとおりです。 service-(プロジェクト番号)@gs-project-accounts.iam.gserviceaccount.com サービスエージェントの名称はコンソールの「Cloud Storage ＞ 設定」画面から確認したり、gcloud コマンドラインで gcloud storage service-agent --project=${PROJECT_ID} を実行することでも確認できます。 参考 : Cloud Storage サービス エージェントの取得 参考 : サービス エージェント Cloud Storage のサービスエージェントは、以下のような用途で用いられます。 Pub/Sub 通知 CMEK による暗号化・復号 Pub/Sub 通知 Cloud Storage ではオブジェクトに変更（作成・削除等）があった際に、Pub/Sub に通知することができます。 参考 : Cloud Storage の Pub/Sub 通知 この機能は、オブジェクト変更をトリガにして Cloud Functions を起動し、後処理を実装する際などに用いられます。 Cloud Run functions を Cloud Storage トリガー関数という形で実装することがありますが、バックエンドではこの Pub/Sub 通知が用いられています。以下の記事も参照ください。 blog.g-gen.co.jp Cloud Storage サービスが Pub/Sub にメッセージをパブリッシュ（通知）する際には、サービスエージェントに権限が必要です。上記の記事の Cloud Storage サービスエージェントに権限付与 の項で示しているように、権限を付与する必要があります。 CMEK による暗号化・復号 Compute Engine と同じように、Cloud Storage でも、ストレージの透過的な暗号化に顧客管理の暗号鍵（CMEK）を指定できます。 その際にサービスエージェントがユーザーに代わって鍵を使い、データを暗号化・復号します。 サービスエージェントは、秘密鍵に対して Cloud KMS 暗号鍵の暗号化 / 復号（ cloudkms.cryptoKeyEncrypterDecrypter ）ロールを持つ必要があります。 プロジェクトレベルでサービスエージェントに上記ロールを付与するか、鍵に個別にロールを付与します。 Cloud Logging 概要 Cloud Logging のサービスエージェントは複数の種類があり、それぞれ用途が異なります。 No 名称 用途 1 service-(プロジェクト番号)@gcp-sa-logging.iam.gserviceaccount.com サービスがバックエンドで利用 2 cmek-p(プロジェクト番号)@gcp-sa-logging.iam.gserviceaccount.com ログバケットの透過的な暗号化 (CMEK) 3 p(プロジェクト番号)-(6桁数字)@gcp-sa-logging.iam.gserviceaccount.com ログシンクの書き込み ID サービスがバックエンドで利用 service-(プロジェクト番号)@gcp-sa-logging.iam.gserviceaccount.com にはデフォルトで、プロジェクトレベルで Cloud Logging サービス エージェント ロールが付与されています。 この IAM ロールは、BigQuery データセットの作成とリンクの権限を持っていることから、 Log Analytics 機能で用いられていることが分かります。 参考 : Cloud Logging Service Agent 参考 : Cloud Loggingの概念と仕組みをしっかり解説 - G-gen Tech Blog - Log Analytics ログバケットの透過的な暗号化 (CMEK) cmek-p(プロジェクト番号)@gcp-sa-logging.iam.gserviceaccount.com は、CMEK 暗号化に用いられます。Compute Engine や Cloud Storage の項で前述した内容と、ほぼ同等です。 KMS の暗号鍵に対して、このサービスエージェントが Cloud KMS 暗号鍵の暗号化 / 復号（ cloudkms.cryptoKeyEncrypterDecrypter ）ロールを持つことで、透過的な暗号化が行われます。 参考 : Logging のストレージ データを保護する鍵を管理する なお p(プロジェクト番号) の部分は、組織レベルのログバケットであれば p(組織番号) になり、フォルダレベルであれば f(フォルダ番号) となります。 ログシンクの書き込み ID p(プロジェクト番号)-(6桁数字)@gcp-sa-logging.iam.gserviceaccount.com は、 書き込み ID と呼ばれるサービスアカウント（サービスエージェント）です。 Cloud Logging では、 ログシンク （ログルーター）を作成することで、Cloud Logging に入ってきたログを様々な宛先に振り分けて保存することが可能です。 ログシンクが書き込み可能な宛先は「Cloud Logging ログバケット」「Cloud Storage バケット」「BigQuery データセット」「Pub/Sub」などですが、ログシンクを作成する際、宛先が「そのシンクが存在するプロジェクトの Cloud Logging ログバケット以外」だった場合、シンクは 書き込み ID （Writer Identity）と呼ばれる専用のサービスアカウントを使います。 書き込み ID の名称を確認するには、Google Cloud コンソールでログシンクを選択し「シンクの詳細を表示する」を押下したり、gcloud で gcloud logging sinks describe ${SINK_NAME} を実行します。 ログシンクの書き込み ID シンクはプロジェクトに作成したり、あるいはフォルダレベル / 組織レベルで作成することができます。プロジェクトレベルで作成したシンクの書き込み ID は p(プロジェクト番号)-(6桁数字)@gcp-sa-logging.iam.gserviceaccount.com となり、フォルダレベルなら f(フォルダ番号)-(6桁数字)@〜 、組織レベルなら o(フォルダ番号)-(6桁数字)@〜 となります。 またシンクを作成するごとに書き込み ID が別個に生成され、一意の6桁の数字が払い出されてサービスアカウント名になります。 シンク（ログルーター）については以下の記事もご参照ください。 参考 : Cloud Loggingの概念と仕組みをしっかり解説 - G-gen Tech Blog - ログルーティングとログの保存 Looker Studio 概要 Google Cloud の無償のダッシュボードツールである Looker Studioにも、サービスエージェントが存在します。サービスエージェントの名称は以下です。 service-org-(組織番号)@gcp-sa-datastudio.iam.gserviceaccount.com サービスエージェント名は、以下の URL にアクセスすることで確認可能です。 参考 : https://datastudio.google.com/serviceAgentHelp データソースへの認証 Looker Studio のサービスエージェントは、「データソースへの認証をサービスアカウントで行う」場合に用います。 Looker Studio には多様なコネクタが用意されており、BigQuery や Cloud SQL、Cloud Storage 上の CSV などにアクセスしてデータを可視化することができます。 参考 : Looker Studio | Connect to Data Google Cloud 上のリソースをデータソースとして扱う際には、認証が必要です。Looker Studio では、データソースへの認証方法として以下を選択できます。 ダッシュボードのオーナーの Google アカウント ダッシュボードの閲覧者の Google アカウント サービスアカウント データソースへの認証にサービスアカウントを使えば、利用者にはダッシュボードの閲覧権限だけを与えるだけでよくなります。Looker Studio レポートからデータソースへのアクセスには、サービスアカウントの認証情報が使われます。 この 3. の用途の際に、サービスエージェントが関係してきます。 認証情報として使うサービスアカウントは、Google Cloud プロジェクトに作成してデータソースへのアクセス権限（BigQuery 閲覧者等）を付与しておきます。 その後 Looker Studio がこのサービスアカウントの権限を借用できるように、作成したサービスアカウントに対して、Looker Studio サービスエージェントをサービス アカウント トークン作成者（ iam.serviceAccount.getAccessToken ）ロールとして紐づけます。 図示すると以下のようになります。 Looker Studio がサービスアカウントを使う仕組み つまり、データソースへのアクセス権限自体は、ユーザーが作成したサービスアカウントが持っていますが、そのサービスアカウント権限を借用するために、サービスエージェントが使われるのです。 参考 : Looker Studio 用に Google Cloud サービス アカウントを設定する 杉村 勇馬 (記事一覧) 執行役員 CTO / クラウドソリューション部 部長 元警察官という経歴を持つ現 IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 12資格、Google Cloud認定資格11資格。X (旧 Twitter) では Google Cloud や AWS のアップデート情報をつぶやいています。 Follow @y_sugi_it

G-gen ビジネス推進部の菊池です。Google Workspace のツールのひとつである Google ドキュメントの意外と知らない機能をご紹介します。 Google Docs Google ドキュメントとは ファイルの共同編集 ファイルの変更内容を確認する ファイルの変更内容を提案する 音声で入力する メールの下書き ページ分けのありなし Google ドキュメントとは Google ドキュメント (英名 Google Docs) とは、オンラインで文書の作成・編集を行うことができるツールです。 Google の提供するコラボレーションツールスイートである Google Workspace のツールの一つとして提供されています。 作成されたドキュメントはクラウドに保存されますが、ダウンロードすることも可能です。作成されたドキュメントは Microsoft Word との互換性があるほか Word のファイルも読み込み・編集できるため「Word の Google 版」とも言えるツールです。 ファイルの共同編集 ファイルの変更内容を確認する ファイルに加えられた変更内容を確認できます。特別な設定は不要で自動的に編集履歴は保存されています。 使い方は [ファイル]>[変更履歴]>[変更履歴を表示] をクリックするだけなので非常に簡単です。 画面上の変更履歴で [すべての版] を選択すると、変更した履歴が表示されます。 間違えて更新してしまった場合は [この版を復元する]>[復元] をクリックするだけで復元されます。 他にも [コピーを作成] で以前の版をコピーしたり、 [この版に名前を付ける] で複数の版を統合されないようにできます。 ファイルの変更内容を提案する 複数人で共同編集をしていると誰が何を編集したのかわからなくなってしまう事を 提案モード で回避できます。 提案モードではドキュメントの内容を直接修正せず、修正内容の提案ができます。 画面右上の鉛筆マークをクリックし [提案] を選択すると提案モードに切り替わります。 削除すると打ち消し線で表示され、追加すると上下色付きで表示されます。変更箇所は右側にリスト表示され、コメント入力も可能です。 音声で入力する 会議の議事録作成やウェビナーを受講しながらのメモなど話を聞きながらドキュメントに文字を入力する作業はよくあるシーンです。タイピングが追いつかなかったり、メモを取ることに精一杯になってしまい、なかなか話が入ってこないと、本末転倒になってしまいます。 そんなときに Google ドキュメントの 音声入力機能 を活用することで、テキスト入力を簡易化し、手間を削減することが可能です。 www.youtube.com メールの下書き スマートチップ を挿入することで日付やファイル、カレンダー、メールの下書きや会議メモなどをドキュメント内に含めることができます。 使い方は至ってシンプルで「＠」と入力することでAIが候補を表示し、リンクを作成します。 一例として メールの下書き 機能を紹介します。 youtu.be このように簡単にメールの下書きを作成することができます。 Gmail の下書き機能では下書きした内容を他のユーザーと共有することができませんが、Google ドキュメントの下書き機能を使えば、他のユーザーと共有、編集が可能になり、様々なシーンで活用できます。 例えば よくあるメールのテンプレート化 メール送信前に他のユーザーに事前確認をしてもらう 複数名でメールの作成を行う など、いままでチャットツールなどを使って実施していたような内容を Google ドキュメント内で完結することができます。 また、下書きした文章はボタンひとつで Gmail に飛ばすことが可能ですので、コピー&ペーストの煩わしさもありません。 ページ分けのありなし [ファイル]>[ページ設定] を選択すると ページ分けのあり / なし が選択できます。 ページ分けをありにしていると余白が気になったり、画像を貼り付けた際に白紙部分が大きく余ってしまうことがあります。 使い分けの一例として PDF化や紙への印刷を前提とした文書の場合はページ分けあり 電子での保存を前提とした定例会議の議事録などをページ分けなし といった方法が考えられます。 デフォルトでどちらかを選択することができますので、よく使うほうに設定しておくと良いでしょう。 菊池 勇一 (記事一覧) ビジネス推進部 2022年5月にG-gen にジョイン。 勢いとスピード感を求めて大手製造業の販売会社からGoogle Cloudの営業にキャリアチェンジ！小さい脳みそをフル回転させながら日々勉強中。

G-gen の杉村です。これまで料金の掛かっていなかった「Cloud Logging ログバケットのログ保存料金」の課金が、2023年4月1日から開始されます。(当記事は2022年11月22日に執筆され、2023年2月27日に更新されました。) 概要と経緯 課金開始が2023年4月1日からに変更 何をすればいいのか 料金の確認 概要と経緯 Cloud Logging の ログバケット は Cloud Logging のログを保管するための独自ストレージです。 これまでログバケットの保存料金は、予告はされていたものの実際に料金は発生していませんでした。 Cloud Logging の課金体型には2つの軸があります。 一つ目は「 ログの取り込み料金 」で、Cloud Logging API にログが送信された GB 数に応じて発生します。単価は $0.50/GiB (2022年11月現在) です。これは2018年7月1日より実際に課金が発生しています。 二つ目は「 ログの保管料金 」で、ログが実際に保管されたストレージの使用料金として、ログの GB 数に応じて発生する料金です。 ログを Cloud Storage や BigQuery に送信していればそちらのストレージ料金が掛かります。しかし Cloud Logging の独自ストレージであるログバケットの保管料金は「30 日を超えて保持されたログに対して $0.01/GiB」とされていたものの、課金が実際に発生するのは「2023年1月16日から」とされており、これまで実際に料金は発生していませんでした。 参考 : Cloud Logging の料金概要 以前は2023年1月16日からの課金が予告されていた 課金開始日が2023年4月1日に訂正されている 課金開始が2023年4月1日からに変更 日本時間 2022年11月21日 に Google Cloud の特定のロールを持つ Google アカウントに対し、以下の要旨のメールが送信されました。 ログバケット保存料金の課金開始は 2023年3月1日 に変更 料金は $0.01/GiB (従来の予告通り) 課金対象はログバケットに30日を超えて保存されるログ (従来の予告通り) 課金開始の日程が変更になった さらに2023年2月24日には Google Cloud から追加の連絡が送信されました。課金開始が 2023年4月1日 からに延期になった旨を伝える連絡でした。 何をすればいいのか この通知により、従来の予告より3ヶ月ほど課金開始が延長されたことになります。 ただし、いずれにせよ間もなく課金が開始されることに変わりはありません。 これまで意識していなかった課金が 2023年4月 より開始されることになるので、Google Cloud 料金の 急激な増加に注意が必要 です。 また、以下のような対策が考えられます。 ログバケットの保管期間 (Custom Retention) の見直し (不要なログは30日で破棄されるように 設定 ) 予算アラート を設定 Google Cloud 利用者部門への注意喚起 支払い関係部署等、関係各所への事前通達 料金の確認 2023年4月の課金開始に備え、自分のプロジェクトの Cloud Logging にどのくらいの課金対象ログがあるのか確認したくなるはずです。 2023年1月より Cloud Monitoring で Billable Storage メトリクスが利用可能になっています。このメトリクスでは、30日を超えて保存されている課金対象のログのボリュームの概算が確認できます。 また、それ以外にも Google Cloud コンソールの「ロギング＞ログストレージ」画面にて、プロジェクトの全ログバケットのサイズ合計や、ログバケットごとの前月使用量、今月使用量、設定してある保持期限などが確認可能です。ただしこちらで確認できるのはログバケットに保存されている ログの全量 です。課金対象である「30日以上保管してあるログ」ではない点にご留意ください。 ログバケットのログサイズの確認 なお、デフォルトで存在する _Required と言うログバケットには課金が発生しません。同じくデフォルトで存在する _Default も、保持期間が 30 日以内になっている限りは、課金が発生しません。これら以外のログバケットで保持期限が 30 日以上になっているものについて、注意が必要です。 以下の記事も参考にしてください。 blog.g-gen.co.jp 杉村 勇馬 (記事一覧) 執行役員 CTO / クラウドソリューション部 部長 元警察官という経歴を持つ現 IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 12資格、Google Cloud認定資格11資格。Twitter では Google Cloud や AWS のアップデート情報をつぶやいています。 Follow @y_sugi_it

当記事では、 Google Cloud (旧称 GCP) の Cloud DNS の DNS ピアリングを使用して、異なるプロジェクトの Cloud DNS ゾーンの名前解決をする方法について紹介します。 Cloud DNS とは 一般公開 DNS ゾーンと限定公開 DNS ゾーン 名前解決の順序 DNS ピアリング 実施内容 構成 API の有効化 限定公開ゾーンの作成 レコードセットの追加 ピアリングゾーンの作成 名前解決の確認 Cloud DNS とは Cloud DNS は、 Google Cloud (旧称 GCP) のマネージドな DNS サービスです。 ここでは、今回の構成で出てくる用語について簡単に説明します。詳細については、公式ドキュメントをご参照ください。 一般公開 DNS ゾーンと限定公開 DNS ゾーン Cloud DNS では以下のゾーンのタイプが作成可能です。 一般公開ゾーン インターネットから名前解決が 可 限定公開ゾーン インターネットから名前解決が 不可 設定した 1 つ以上の VPC ネットワークからのみ名前解決が可能 名前解決の順序 Google Cloud が持つ Virtual Private Cloud（以下 VPC） は、Google Compute Engine 等のインスタンスに名前解決サービスを提供しています。 インスタンスが、デフォルトで設定されているメタデータサーバー（ 169.254.169.254 ）をネームサーバーとして使用する場合、規定された順序に従って名前解決が行われます。 参考 : 名前解決の順序 DNS ピアリング Cloud DNS の機能の中に DNS ピアリングがあります。名前の似ているサービスとして VPC ピアリングがありますが、別サービスです。 DNS ピアリングを使用することで、別の VPC に設定されているゾーンの名前解決が可能になります。 注意点として、 DNS ピアリングは 片方向の関係 です。そのため、当ブログの後半で紹介する構成において、仮に vpc-a で限定公開ゾーンを作成し、 vpc-b でそのゾーンの名前解決ができるようにするには、追加で DNS ピアリングを設定する必要があります。 その他の制約事項等については 公式ドキュメント をご参照ください。 実施内容 構成 今回の構成は以下の通りです。 構成図 構成図に DNS コンシューマネットワーク と DNS プロデューサーネットワーク という聞き慣れない用語がありますが、ここでは詳細な説明は割愛します。DNS コンシューマネットワークは、別 VPC で作成されているゾーンの名前解決を 参照する側 で、DNS プロデューサーネットワークは 参照される側 です。 API の有効化 project-a と project-b で Cloud DNS API の有効化をします。 Cloud DNS API の有効化（project-a / project-b） 限定公開ゾーンの作成 まず、 DNS プロデューサーネットワークである project-b の Cloud DNS で限定公開ゾーンを作成します。 ゾーンの作成には、 dns.managedZones.create の権限が必要です。その他詳細なロールと権限については 公式ドキュメント をご参照ください。 Cloud DNS の画面（project-b） 以下の項目を設定します。 項目 設定値 備考 ゾーンのタイプ 非公開 今回は限定公開ゾーンのため ゾーン名 g-gen-local-zone 任意の名前 DNS 名 g-gen.local 限定公開ゾーンの DNS 名 オプション デフォルト（限定公開） ネットワーク vpc-b ゾーンを使用する VPC DNS ゾーンの作成画面（project-b） ゾーンを作成すると、自動で SOA レコードと NS レコードが作成されます。DNS 名の最後のドット（.）は自動で追加されます。 DNS ゾーンの画面（project-b） レコードセットの追加 検証用にレコードを追加します。 レコードセットを追加（project-b） 今回は、 www.g-gen.local の A レコードを追加します。IP アドレスは 1.1.1.1 とします。 レコードセットの作成画面（project-b） レコードが追加されました。 DNS ゾーンの画面（project-b） 現段階では、 vpc-a と vpc-b は DNS ピアリングをしていないため vpc-a にあるインスタンス からは www.g-gen.local の名前解決はできません。 インスタンスの名前解決画面（project-a） ピアリングゾーンの作成 次に、 project-a でピアリングゾーンを作成します。 ピアリングゾーンの作成には、ピアリング先 VPC（DNS プロデューサーネットワーク）を含むプロジェクトで roles/dns.peer のあるアカウントで作成する必要があります。その他詳細なロールと権限については 公式ドキュメント をご参照ください。 Cloud DNS の画面（project-a） 以下の項目を設定します。 項目 設定値 備考 ゾーンのタイプ 非公開 今回は限定公開ゾーンのため ゾーン名 g-gen-local-peering-zone 任意の名前 DNS 名 g-gen.local 今回は project-b で設定した g-gen.local オプション DNS ピアリング ネットワーク vpc-a ゾーンを使用する VPC ピアリングプロジェクト project-b ピアリング先のプロジェクトを選択 ピアリングネットワーク vpc-b ピアリング先の VPC DNS ゾーンの作成画面（project-a） 以下のようにピアリングゾーンが作成されます。 DNS ゾーンの画面（project-a） 名前解決の確認 DNS ピアリングの設定が完了したので、インスタンスから先程は名前解決ができなかった www.g-gen.local の名前解決の確認をします。 インスタンスの名前解決画面（project-a） 無事、今回設定した A レコードの 1.1.1.1 が返ってくるようになりました。 G-gen 編集部 (記事一覧) 株式会社G-genは、サーバーワークスグループとして「クラウドで、世界を、もっと、はたらきやすく」をビジョンに掲げ、クラウドの導入から最適化までを支援している Google Cloud 専業のクラウドインテグレーターです。

G-gen の杉村です。Compute Engine で起動した Linux VM に SSH ログインするにはいくつかの方法があり、それぞれネットワーク的な考慮点が異なるため、整理しました。 Compute Engine VM への SSH 接続について コンソールの SSH ボタン 概要 インターフェイス 要件 ネットワーク 認証・認可 OS ログイン機能 gcloud コマンド 概要 インターフェイス 要件 ネットワーク 認証・認可 SSH ターミナルソフトウェア 概要 インターフェイス 要件 ネットワーク 認証・認可 Identity-Aware Proxy（IAP） 概要 インターフェイス 要件 ネットワーク 認証・認可 Compute Engine VM への SSH 接続について Compute Engine で Linux インスタンスを起動した際、SSH ログインするにはいくつかの方法があります。 No タイトル インターフェイス 1 コンソールの SSH ボタン Web ブラウザ 2 gcloud コマンド PC のターミナル 3 SSH ターミナルソフト SSH ターミナルソフト 4 Identity-Aware Proxy（IAP） 上記のいずれか それぞれの方法において、ログインのために必要な IAM や VPC ファイアウォールの設定が異なります。当記事では「ネットワーク」「認証・認可」の観点で整理しました。 コンソールの SSH ボタン 概要 Google Cloud コンソールの VM 一覧から SSH ボタンを押下してログインします。 最もシンプルで簡単に Linux VM へログインする方法です。 SSH ボタン 参考 : ブラウザからの SSH インターフェイス Web ブラウザの新規ウインドウが開き、SSH ターミナルとして利用できます。 ショートカットキーの利用やファイルのアップロードやダウンロード、フォントの変更なども利用でき、多くのケースで不便を感じません。 Web ブラウザの SSH インターフェイス なおこの方法でのログインを試みた際、Identity-Aware Proxy（IAP）を利用できる条件が満たされていると、自動的に IAP 経由でアクセスされます。 要件 ネットワーク この方式でログインする際、VM から見た接続元 IP アドレスは、Google のパブリック IP アドレスになります。そのため VPC ネットワークのファイアウォールにて、22/TCP を、以下のいずれかの接続元から許可する必要があります。 0.0.0.0/0（ログインしている Google アカウントが IAP 権限を持って いない 場合) 35.235.240.0/20（ログインしている Google アカウントが IAP 権限を持って いる 場合） 基本的には、 0.0.0.0/0 から該当インスタンスへの 22/TCP を VPC ファイアウォールルールで許可する必要があります。これは、VM への SSH トラフィックが、Google のパブリック IP アドレスから発信されるためです。 しかし、Google の接続元 IP アドレスは JSON フォーマットで公開されており、これを自動的・定期的に取得してファイアウォールに反映する仕組みを構築すれば、IP アドレスの追加や変動に対応することができます。 参考 : ブラウザでの SSH 参考 : Google の IP アドレスの範囲を取得する また 35.235.240.0/20 からの接続がファイアウォールで許可されており、かつログインしている Google アカウントが、IAP で保護された トンネル ユーザー（ roles/iap.tunnelResourceAccessor ）などの IAP 利用権限を持っている場合、自動的に IAP 経由での接続となります。その場合、VM から見た接続元 IP は 35.235.240.0/20 の IP アドレス範囲になります。 認証・認可 Google Cloud コンソールへのログインに利用している Google アカウントが、該当インスタンスに対して適切な IAM 権限を持っていれば、SSH 鍵を管理することなく、Google アカウントの認証でログイン可能です。 公開鍵・秘密鍵のキーペアが自動的に作成された後、公開鍵が VM に登録され、OS ユーザーも自動的に作成されます。作成されるユーザー名は Google アカウント名の@マークの前になります。（ただし、後述の OS ログイン 機能を使う場合は、ユーザー名が異なります）。 必要な IAM 権限は以下のとおりです。 compute.instances.use 権限等（Compute インスタンス管理者 (v1)（ roles/compute.instanceAdmin.v1 ）ロールの付与が推奨） VM にサービスアカウントがアタッチされている場合は、サービスアカウントまたはプロジェクトに対する iam.serviceAccounts.actAs 権限（サービス アカウント ユーザー（ roles/iam.serviceAccountUser ）ロール等が推奨) OS ログイン機能を利用する場合は、OS ログインに必要な IAM ロール（ roles/compute.osAdminLogin または roles/compute.osLogin ） このように、多少複雑です。プロジェクトのオーナー権限があれば問題なくログインできますが、例えば、Compute 管理者（ roles/compute.admin ）ロールのみを持っている人がこの方法でログインしようとした際、 予期しないエラーにより、VM インスタンスに接続できません。数分待ってからもう一度お試しください。 等のエラーメッセージが表示されることがあります。これは、IAM 権限が不足していることを示しており、サービス アカウント ユーザー（ roles/iam.serviceAccountUser ）ロール等を付与することで解決する場合があります。 エラー時に表示される「トラブルシューティング」ボタンを押下すると、不足している IAM 権限などが示されます。 接続できませんでした OS ログイン機能 OS ログイン （OS Login）機能とは、Compute Engine VM への SSH ログイン時の認証を、Google Cloud の IAM で管理するための仕組みです。 VM のゲスト OS 上にログインユーザーを作成しなくても、適切な IAM 権限を持っていれば、VM に SSH ログインできるようになります。 詳細は、以下の記事を参照してください。 blog.g-gen.co.jp gcloud コマンド 概要 PC 等で実行する gcloud コマンド（別名 Google Cloud CLI）を使って、Compute Engine VM にログインすることができます。 コマンドラインは gcloud compute ssh ${INSTANCE_NAME} --zone=${ZONE} です。 参考 : Linux VM への接続 インターフェイス gcloud コマンドがインストール済みであれば、Mac や Windows の通常のターミナルで操作できます。 使い慣れた自分の PC のターミナルから SSH 接続することができます。 参考 : gcloud CLI をインストールする 要件 ネットワーク VM から見た接続元 IP アドレスは、操作している PC 環境のパブリック IP アドレスとなります。そのため、VPC ファイアウォールで、PC が稼働している環境のパブリック IP アドレスからの 22/TCP を許可します。 認証・認可 公開鍵・秘密鍵を用意しなくても、Google アカウントによる IAM 認証で SSH ログインすることができます。 必要な IAM 権限は、前述の「コンソールの SSH ボタン」と同様です。 VM に作成されるユーザー名は、実行環境のローカルユーザー名となります。ただし、前述の OS ログイン機能を使う場合は異なり、 <アカウント名>_<ドメイン名> になります。 例 : tom@example.com → tom_example_com SSH ターミナルソフトウェア 概要 Tera Term や PuTTY といった、使い慣れた SSH ターミナルソフトウェアから、VM へログインすることができます。 インターフェイス Tera Term、PuTTY、Linux の SSH コマンド等です。 要件 ネットワーク VM から見た接続元は、操作している PC 環境のパブリック IP アドレスとなります。VPC ファイアウォールで、この接続元からの 22/TCP を許可する必要があります。 認証・認可 IAM ではなく、SSH キーペアによる公開鍵認証となります。 VM に公開鍵を追加する方法は、以下の公式ドキュメントを参照してください。以下の方法に沿って、インスタンスメタデータに SSH 公開鍵を追加することで、手元の秘密鍵でログインすることができます。 参考 : VM に SSH 認証鍵を追加する 一度ログインできるようになった後は、通常の Linux サーバーのように home ディレクトリの authorized_keys に公開鍵を直接追加することもできます。 Identity-Aware Proxy（IAP） 概要 Identity-Aware Proxy（IAP）は、Google Cloud が提供するフルマネージドのプロキシサービスであり、SSH ログイン時に使用できます。 VM へのログインにおいては、フルマネージドの踏み台サーバがポートフォワードをしてくれるイメージを持つとよいでしょう。 IAP による SSH ログインの詳細は、以下の記事でも解説しています。 blog.g-gen.co.jp インターフェイス 当記事で紹介した「コンソールの SSH ボタン」「gcloud コマンド」「SSH ターミナルソフトウェア」 のどれかと組み合わせて利用するため、いずれかのインターフェイスを選ぶことができます。 要件 ネットワーク VM から見た接続元 IP アドレスは、IAP のパブリック IP アドレス（ 35.235.240.0/20 ）になります。VPC のファイアウォールにて、 35.235.240.0/20 からの 22/TCP を許可します。 認証・認可 Google アカウントがプロジェクトレベルで、IAP で保護されたトンネル ユーザー（ roles/iap.tunnelResourceAccessor ）ロールを付与されている必要があります。 ただし、これはあくまで IAP を使ってトンネルを確率するための権限です。ログインに使う方法（「コンソールの SSH ボタン」「gcloud コマンド」「SSH ターミナルソフトウェア」）ごとの認証・認可の条件も、併せて満たす必要があります。 IAP による SSH ログインの詳細は、以下の記事でも解説しています。 blog.g-gen.co.jp 杉村 勇馬 (記事一覧) 執行役員 CTO / クラウドソリューション部 部長 元警察官という経歴を持つ現 IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 12資格、Google Cloud認定資格11資格。X (旧 Twitter) では Google Cloud や AWS のアップデート情報をつぶやいています。 Follow @y_sugi_it

G-gen の杉村です。 Cloud Functions で動作する Python プログラムから Google Calendar API を呼び出す方法をご紹介します。 検証内容 プログラムの内容 Google API への認証 検証の流れ Google Calendar API 有効化 サービスアカウント作成・設定 サービスアカウント作成 サービスアカウントへ IAM 権限付与 コマンドライン ソースコードの解説 ソースコード パッケージのインポート 認証情報取得 サービスオブジェクト作成 API 呼び出し BigQuery への書き込み Python 環境の準備 Cloud Functions のデプロイ 動作確認 ローカル環境でのテスト ローカル環境での Functions のテスト サービスアカウントのキーのダウンロード functions-framework インストール 仮想 Cloud Functions 実行 リクエスト 検証内容 プログラムの内容 Cloud Functions で動作する Python プログラムから Google Calendar API を呼び出す際の認証について検証しました。 今回は単純化のため、以下のようなプログラムとしています。 Google Calendar API をコールして日本の祝日一覧を取得 取得した祝日一覧を BigQuery テーブルに INSERT 実際のユースケースでは Google Calendar から従業員の予定を取得して BigQuery に投入し、分析するなどの用途が考えられます。 Google API への認証 今回検証したかった内容は Google Calendar を始めとする、 Google API への認証です。 Google Calendar や Gmail は Google Cloud 製品ではなく Google 製品です。そのため Cloud IAM を使った認証・認可がサポートされていません。 API キーによる認証、OAuth 2.0 による認証、サービスアカウントによる認証がサポートされています。 Cloud Functions など Google Cloud 上の実行環境で動作するプログラムではサービスアカウントを用いた認証が最もセキュア・低工数であると考えられるため、この方法を検証します。 検証の流れ 検証の全体の流れは以下のとおりです。 準備 Google Cloud プロジェクトにおいて Google Calendar API を有効化 サービスアカウントを作成 サービスアカウントに BigQuery データ編集者 ログ書き込み ロールを付与 (※) Python プログラムを Cloud Functions (2nd gen) にデプロイ (Functions にはサービスアカウントをアタッチ) (※) BigQuery データ編集者 は BigQuery テーブルへのデータ書き込みため、 ログ書き込み は Cloud Logging へのログ出力のため 処理の流れ google-auth ライブラリでサービスアカウントの認証情報を取得 google-api-python-client ライブラリでサービスインスタンス生成 Google Calendar API をコールして日本の祝日一覧を取得 google-cloud-bigquery ライブラリで祝日一覧を BigQuery テーブルに INSERT 注目すべきは、サービスアカウントを作成すれば、IAM 権限を付与しなくても同じプロジェクトで有効化された Google Calendar API にアクセスできるという点です。 ここからは、各手順を説明していきます。 Google Calendar API 有効化 まずはじめに Google Cloud コンソール > API とサービス > 有効な API とサービス の画面 ( リンク ) から Google Calendar API を有効化します。 同画面では多数の API のリストが表示されますが、テキストボックスでフィルタをかけることができます。 calendar と入力するとサジェストされるはずです。 もしくは以下のコマンドでも API を有効化できます。 gcloud services enable calendar-json.googleapis.com サービスアカウント作成・設定 サービスアカウント作成 Google Cloud コンソール > IAM と管理 > サービス アカウント の画面 ( リンク ) からサービスアカウントを作成します。自分のプロジェクトが正しく選択されていることを確認してください。 サービスアカウントはプロジェクトに所属するリソースです。 Google Calendar API を有効化したのと同じプロジェクトに、サービスアカウントを作成する必要があります。 今回は表示名を get-holidays として作成します。 サービスアカウント ID は get-holidays@${PROJECT}.iam.gserviceaccount.com となります (${PROJECT} はプロジェクト ID です) 。 サービスアカウントへ IAM 権限付与 次にこのサービスアカウントに IAM 権限を付与します。 Google Calendar API をコールするには IAM 権限は必要ありませんが、今回は BigQuery にデータを書き込んだり、Cloud Logging にログ出力するために IAM 権限が必要です。 今回はプロジェクトレベルでの権限付与とします。 Google Cloud コンソール > IAM と管理 > IAM の画面 ( リンク ) に遷移します。繰り返しになりますが自分のプロジェクトが正しく選択されていることを確認してください。 先程作成したサービスアカウントに BigQuery データ編集者 ログ書き込み の IAM ロールを付与します。 コマンドライン 前述の「サービスアカウント作成」と「IAM 権限付与」の作業は以下のコマンドでも実施できます。 PROJECT = " ＜プロジェクト ID に置き換えてください＞ " ACCOUNT_NAME = " get-holidays " gcloud iam service-accounts create ${ACCOUNT_NAME} --display-name= " ${ACCOUNT_NAME} " gcloud projects add-iam-policy-binding ${PROJECT} --member= " serviceAccount: ${ACCOUNT_NAME} @ ${PROJECT} .iam.gserviceaccount.com " --role= " roles/logging.logWriter " gcloud projects add-iam-policy-binding ${PROJECT} --member= " serviceAccount: ${ACCOUNT_NAME} @ ${PROJECT} .iam.gserviceaccount.com " --role= " roles/bigquery.dataEditor " ソースコードの解説 ソースコード 以下のソースコードを使います。 今回は Cloud Functions の HTTP 関数 を想定して用意しました。 #!/usr/bin/env python import datetime import logging from flask import abort import google.auth from googleapiclient.discovery import build import google.cloud.bigquery import google.cloud.logging # ロギング設定 logging.basicConfig( format = "[%(asctime)s][%(levelname)s] %(message)s" ) logger = logging.getLogger() # Cloud Logging への連携 logging_client = google.cloud.logging.Client() logging_client.setup_logging() logger.setLevel(logging.INFO) # BigQuery Data Transfer Service のクライアント生成 client = google.cloud.bigquery.Client() def get_holidays (dataset, table, year): """ 特定年の祝日一覧の取得とテーブルへの書き込み """ logger.info(f "Getting holidays for year: {year}" ) # 実行環境のデフォルトクレデンシャル = Cloud Functions にアタッチされているサービスアカウントを取得 credentials, project = google.auth.default() # サービスを生成 service = build( 'calendar' , 'v3' , credentials=credentials, cache_discovery= False ) # Google Calendar API 呼び出し result = service.events().list( calendarId= 'japanese__ja@holiday.calendar.google.com' , timeMin= str (year) + '-01-01T00:00:00.000000Z' , timeMax= str (year) + '-12-31T23:59:59.999999Z' , singleEvents= True , orderBy= 'startTime' ).execute() holiday_info = result.get( 'items' , []) # INSERT するリスト作成 holidays = [] for holiday in holiday_info: name = holiday[ 'summary' ] date = holiday[ 'start' ][ 'date' ] holidays.append([name, date]) # スキーマ定義 schema = [ google.cloud.bigquery.SchemaField( "name" , "STRING" , "REQUIRED" , "祝日の名称" ), google.cloud.bigquery.SchemaField( "date" , "DATE" , "REQUIRED" , "祝日の日付" ) ] # テーブルの定義 table_id = f "{project}.{dataset}.{table}" table = google.cloud.bigquery.Table(table_id, schema=schema) # テーブルにINSERT client.insert_rows(table=table, rows=holidays) return None def main (request): # リクエストからパラメータを取得 request_dict = request.get_json() logger.info(request_dict) # パラメータチェック if ( 'dataset' in request_dict): dataset = request_dict[ 'dataset' ] else : error_message = "Parameter dataset is missing." logger.error(error_message) return abort( 400 ) if ( 'table' in request_dict): table = request_dict[ 'table' ] else : error_message = "Parameter table is missing." logger.error(error_message) return abort( 400 ) # メイン処理 try : # 現在の西暦を取得 this_year = datetime.date.today().year # Google Calendar から祝日を取得して BigQuery に書き込み get_holidays(dataset, table, this_year) except Exception as e: logger.error(e) return abort( 500 ) return "OK" このソースコードの認証に関わる部分をご説明します。 パッケージのインポート #!/usr/bin/env python import datetime import logging from flask import abort import google.auth from googleapiclient.discovery import build import google.cloud.bigquery import google.cloud.logging 必要なパッケージのインポートを行います。 Cloud Functions では必要なパッケージを requirements.txt に記載してデプロイパッケージに含めることで自動的に環境がビルドされます。 requirements.txt の作成を含めた Python の環境構築手順は後述します。 import google.auth と from googleapiclient.discovery import build が認証に関わるライブラリです。 認証情報取得 get_holidays 関数で Google Calendar API を呼び出しています。 # 実行環境のデフォルトクレデンシャル = Cloud Functions にアタッチされているサービスアカウントを取得 credentials, project = google.auth.default() google-auth は Google API の認証のためのライブラリです。 default() 関数により実行環境のデフォルトクレデンシャル = 今回は Cloud Functions にアタッチされているサービスアカウントの認証情報を取得します。この書き方では credentials 変数にはライブラリ独自の Credentials 型で認証情報が代入され project 変数には str 型で実行環境のデフォルトプロジェクトのプロジェクト ID が代入されます ( 参考 )。 なおかつては oauth2client と言う名称のライブラリが存在しましたがこちらは deprecated (廃止予定・非推奨) となり現在は google-auth が推奨です。 サービスオブジェクト作成 Google API Python Client の build() によりサービスオブジェクトを生成します。Google の API を呼ぶためのインターフェイスを生成するイメージです。 # サービスを生成 service = build( 'calendar' , 'v3' , credentials=credentials, cache_discovery= False ) cache_discovery=False は oauth2client のバージョン 4 以前でサポートされていた機能を無効化するための記述です。これが無いと、以下のようなログメッセージが出力されます (実動作には影響ありません) 。 file_cache is only supported with oauth2client<4.0.0 API 呼び出し # Google Calendar API 呼び出し result = service.events().list( calendarId= 'japanese__ja@holiday.calendar.google.com' , timeMin= str (year) + '-01-01T00:00:00.000000Z' , timeMax= str (year) + '-12-31T23:59:59.999999Z' , singleEvents= True , orderBy= 'startTime' ).execute() execute() で実際に API を呼び出しています。 japanese__ja@holiday.calendar.google.com は日本の祝日を保持しているカレンダーリソースで、 Google Calendar がデフォルトで持っています。 BigQuery への書き込み BigQuery Python Client の insert_rows() でテーブルにデータを INSERT します。 # INSERT するリスト作成 holidays = [] for holiday in holiday_info: name = holiday[ 'summary' ] date = holiday[ 'start' ][ 'date' ] holidays.append([name, date]) 入力する値は [ ["カラムAの値1", "カラムBの値1"], ["カラムAの値2", "カラムBの値2"], ...] のように二次元配列で渡すため、このように整形しています。 以下で実際に API を実行し、テーブルにデータを挿入します。 client.insert_rows(table=table, rows=holidays) Python 環境の準備 ソースコードの解説はここまでです。 ここからは、ローカルで Python 環境を準備する方法を説明します。 必要に応じ以下のように venv 環境を作成し activate します。 python -m venv venv source venv/bin/activate 今回のプログラムで使うパッケージをインストールし requirements.txt を作成します。 pip install google-auth google-api-python-client google-cloud-logging google-cloud-bigquery pip freeze > requirements.txt なおソースコード中で flask のモジュールを import していますが Cloud Functions の python 実行環境には Flask パッケージが予め含まれているため、明示的に pip install したり requirements.txt に含める必要はありません。 Cloud Functions のデプロイ 以下のコマンドで Cloud Functions をデプロイします。 ソースコードと requirements.txt が存在するディレクトリでコマンド実行してください。またデプロイのパラメータは適宜設定ください。 PROJECT = " ＜プロジェクト ID に置き換え＞ " ACCOUNT_NAME = " get-holidays " FUNCTION = " get-holidays " gcloud functions deploy ${FUNCTION} \ --quiet --gen2 \ --project = ${PROJECT} \ --region = asia-northeast1 \ --runtime = python39 \ --service-account = ${ACCOUNT_NAME} @ ${PROJECT} .iam.gserviceaccount.com \ --entry-point main \ --trigger-http 動作確認 デプロイが成功すると、標準出力にエンドポイント URL が表示されます。Google Cloud コンソールの Cloud Functions 画面から確認することもできますし、以下のコマンドで取得することもできます。 FUNCTION = " get-holidays " URL = `gcloud functions describe ${FUNCTION} --region=asia-northeast1 --gen2 --format= " value(serviceConfig.uri) " ` echo ${URL} 以下の curl コマンドで function の動作確認をします。 INSERT 先のデータセットとテーブルは予め作成しておき、コマンド内の文字列を置き換えてください。 curl -X POST \ -H " Authorization: bearer $( gcloud auth print-identity-token ) " \ -H " Content-Type: application/json " \ -d ' {"dataset": "＜データセット名に置き換え＞", "table": "＜テーブル名に置き換え＞"} ' \ ${URL} なお当 function は呼び出し時に IAM 認証を必要とする設定になっていますので Authorization ヘッダを付与しています。 $(gcloud auth print-identity-token) によりローカル環境に設定されている Google アカウント権限でトークンを取得しています。 実行できたら、以下のように BigQuery テーブルにデータが INSERT されたことを確認します。 BigQuery テーブルにデータが挿入された ローカル環境でのテスト ローカル環境での Functions のテスト Cloud Functions のデプロイには 2 分程度の時間がかかります。コード修正後に動作確認したいとき、いちいちデプロイしていたのでは時間がかかりすぎてしまいます。 functions-framework というライブラリを使うことで、ローカル PC 環境で Cloud Functions を動作させ、テストすることができます。 ここからは、その手順をご紹介します。 サービスアカウントのキーのダウンロード まずローカルの仮想的な Functions から実際に Google Cloud API をコールする際の認証のため、サービスアカウントのキーをダウンロードします。 Google Cloud コンソール > IAM と管理 > サービス アカウント の画面 ( リンク ) から今回作成した get-holidays サービスアカウントを選択し、詳細画面へ遷移します。 キー というタブから「鍵を追加」を押下して「新しい鍵を作成」を選択します。 JSON 形式で鍵を「作成」し、ダウンロードします。 今回はローカルのソースコードと同じディレクトリに test-cred.json として保存します。 このファイルが漏洩すると、サービスアカウントが持つ権限で好きに Google Cloud 環境を操作できてしまうことになるので、十分お気をつけください。 functions-framework インストール functions-framework を使うことでローカル環境で HTTP 関数をテストすることができます。 pip でパッケージをインストールします。手順は以下を参考にしてください。 blog.g-gen.co.jp 仮想 Cloud Functions 実行 ソースコードと同じディレクトリで以下を実行してください。 GOOGLE_APPLICATION_CREDENTIALS = " ./test-cred.json " functions-framework --target main --debug これでダウンロードしたサービスアカウントキーを実行環境のデフォルト認証情報として設定したうえで仮想的な Cloud Functions を起動できます。仮想的な Functions は 8080/tcp ポートで待ち受けします。 なお本来、ローカルの仮想 function から Google Cloud API を呼ぶだけであれば Google アカウントの権限で一度 gcloud auth application-default login ( 参考 ) を実行すればキーのダウンロードや環境変数での指定は不要です。 しかし今回は Google Calendar API の呼び出しがあり、これが上記コマンドによる認証情報の設定 (Google アカウントによるアプリケーションデフォルトクレデンシャル設定) に対応していないため、本来はできれば避けるべきですがキーのダウンロード・指定を行いました。 リクエスト 以下の curl リクエストで実際に動作させることができます。データセット名とテーブル名は実際のものに置き換えてください。 curl localhost:8080 -X POST -H " Content-Type: application/json " -d ' {"dataset": "testdataset", "table": "holidays"} ' 杉村 勇馬 (記事一覧) 執行役員 CTO / クラウドソリューション部 部長 元警察官という経歴を持つ現 IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 12資格、Google Cloud認定資格11資格。Twitter では Google Cloud や AWS のアップデート情報をつぶやいています。 Follow @y_sugi_it

G-gen の杉村です。Google Cloud の鍵管理サービスである Cloud KMS （Cloud Key Management Service）を徹底解説します。 Cloud KMS とは Cloud KMS の料金 デフォルト暗号化と CMEK デフォルトの暗号化 顧客管理の鍵（CMEK） 透過的な暗号化 Key と Key ring Key (キー、鍵) Key とは 鍵の目的 Key のバージョン 保護レベル (ストレージ) Key ring (キーリング) リソースの削除 鍵のローテーション・バージョン・状態 ローテーション バージョン バージョンの無効化と破棄 状態 Autokey Autokey とは 仕組み 有効化 Autokey の強制 鍵の権限管理 Key ring と Key の IAM ポリシー 誰が権限を必要とするか 職掌分散 (Separation of duties) 独自の鍵と外部の鍵 鍵のインポート 外部の鍵の利用 暗号化の手法と技術 エンベロープ暗号化 アルゴリズム Cloud KMS リソースの整合性 Cloud KMS とは Cloud KMS は Google Cloud（旧称 GCP）の鍵管理サービスです。正式名称は Cloud Key Management Service ですが、KMS と略されることがほとんどです。 Google Cloud で秘密鍵を作成・保管・管理でき、鍵は各種 Google Cloud サービスのストレージを暗号化すること等に用いることができます。例として Cloud Storage バケットや、Compute Engine の永続ディスク、BigQuery のデータセットなどが暗号化の対象です。 Google Cloud サービスに保存されるデータは デフォルトで暗号化されており 、このときは Google 側で自動的に鍵が管理・ローテーションされるため、ユーザー側で意識する必要はありません。これを「デフォルトの保存データの暗号化」といいます。 参考 : デフォルトの保存データの暗号化 しかし非常に強固なセキュリティが求められる場合や、情報セキュリティ監査上の理由等において、ユーザー側で独自に鍵を管理してこれを用いて暗号化したい場合があります。このときに、暗号鍵として Cloud KMS の鍵を利用することができます。 Cloud KMS には、ユーザー側で生成した鍵をアップロードして保管することもできますし、Cloud KMS で独自の鍵を生成させることもできます。さらに Cloud HSM と呼ばれるフルマネージドの HSM（Hardware Security Module）を用いて鍵の生成・ホスティングを行わせることもできます。 参考 : Cloud Key Management Service の概要 Cloud KMS の料金 Cloud KMS の料金は KMS が保持する鍵のバージョンの数と、鍵に対するオペレーションの回数で決まります。 例としてアクティブな対称鍵のバージョン 1 個につき、月額 $0.06 です（2024年9月現在。保護レベル SOFTWARE の場合）。料金は日割りされます。 オペレーションに対しては、暗号化/復号オペレーション 10,000 回につき $0.03 です。 最新の正確な料金や計算例は以下のドキュメントをご参照ください。 参考 : Cloud Key Management Service の料金 デフォルト暗号化と CMEK デフォルトの暗号化 Cloud KMS を利用する必要があるかどうかを検討するには「デフォルトの暗号化」と「CMEK（customer-managed encryption keys）」という言葉を理解する必要があります。 まず、Google Cloud サービスのストレージは全て、 デフォルトの暗号化 という機能で暗号化されています。Compute Engine のディスクや Cloud Storage のバケット、BigQuery のデータセットなどは、我々が何も指定しなくても AES-256 方式で暗号化されています。暗号化鍵は Google によって管理・監査・ローテーションされています。 これによりデータはハードウェアの物理的な盗難や Google の内部犯によるアクセスなどから保護されます。またこれらの管理方式は第三者機関による監査を受けています。 つまり、何もしなくても Google Cloud のストレージ上のデータは高度なセキュリティにより保護されていることになります。 より詳細な情報は以下の公式ホワイトペーパーをご参照ください。 参考 : デフォルトの保存データの暗号化 顧客管理の鍵（CMEK） 一方で Google Cloud サービスの中には、データをデフォルトの暗号化ではなく、 顧客管理の鍵 （CMEK = customer-managed encryption keys）で暗号化するよう選択できるものもあります。Compute Engine の永続ディスクや Cloud Storage のバケット、BigQuery のデータセットなどは、リソース作成時にデフォルト暗号化か CMEK 暗号化を選択できるようになっています。 CMEK による暗号化を選択すると、Cloud KMS でユーザー自身が管理する鍵でデータを暗号化することができます。 ただし CMEK を選択することが、必ずしもセキュリティを高めることを意味するわけではありません。デフォルトの暗号化は第三者機関による監査を受けており、十分に安全です。CMEK を選択する必要があるのは、以下のような特殊なセキュリティ要件が存在しているときのみです。 暗号化鍵の存在する国等のロケーションが管理できる必要がある 鍵のローテーションや無効化などの管理がユーザー側で行う必要がある 独自の鍵管理システムで生成・管理する暗号鍵を使う必要がある ほとんどのケースでは上記のような厳密な鍵管理は必要ありません。かなり高度なセキュリティが求めらていたり、第三者監査の要件として上記のような厳密な制御が求められる場合に、CMEK を利用します。 透過的な暗号化 デフォルトの暗号化も CMEK（customer-managed encryption keys）による暗号化も、いずれもストレージの 透過的な暗号化 です。 透過的な暗号化では、ユーザーは暗号化を意識することはありません。ユーザーの知らないところで「勝手に暗号化されている」のが透過的な暗号化です。 例えばユーザーが暗号化された Cloud Storage バケットにオブジェクトをアップロードすると、Cloud Storage のサービス側で自動的にデータが暗号化されて格納されます。データの読み取り時も同様に、ユーザーがデータにアクセスすると Cloud Storage のサービス側で自動的にデータが復号されユーザーに渡されます。 KMS の鍵は Google Cloud リソースであるため IAM 権限を適用可能ですが、透過的な暗号化においては、ユーザーは鍵へのアクセス権を必要としません。透過的なアクセスにおいて KMS 鍵へのアクセス権限が必要なのは、サービスエージェント（Google Cloud サービスがデフォルトで持つ特殊なサービスアカウント）です。 透過的な暗号化の仕組み (Cloud Storage) このように、透過的な暗号化はユーザーには全く意識されません（これが「透過的」という言葉の意味です）。ここから、データの透過的暗号化はアクセス制御観点でのセキュリティの向上には寄与しないことが分かります。データの透過的暗号化が対処できる脅威はあくまで「 物理ストレージ機器の盗難 」「 内部犯によるストレージ機器への物理的アクセス 」等です。 Key と Key ring Key (キー、鍵) Key とは Key (キー、鍵) はその名の通り、Cloud KMS で管理される鍵そのものです。 Key は必ず Key ring (キーリング) に所属しています。Key ring は特定のロケーション (リージョン) に所属するので、Key も必然的に特定のロケーションに存在するリソースです。 鍵は無効化したり、破棄したりすることができます。 鍵の目的 Key は作成時に 目的 (Purpose) を指定します。目的は以下の 4 つから選択します。目的は一度選択すると、変更できません。 対称暗号化 (Symmetric encryption) 非対称署名 (Asymmetric signing) 非対称暗号化 (Asymmetric encryption) MAC 署名 (MAC signing) 上記のうち 1. と 4. は 対称鍵 であり、2. と 3. は 非対称鍵 (秘密鍵と公開鍵のキーペア) です。 非対称鍵では、公開鍵のみをダウンロードすることができます。一方で対称鍵は 一切ダウンロードすることはできません 。KMS の鍵は、KMS 内部でのみ保持・管理・利用されます。 Compute Engine、Cloud Storage、BigQuery などのストレージの CMEK 暗号化に使うのは 1. 対称暗号化鍵です。 対称鍵は、いわゆる共通鍵暗号化に用いられる鍵で、生成される秘密鍵が暗号化と復号の両方に使われます。 非対称鍵は公開鍵・秘密鍵のペアで暗号化・復号を行う鍵です。 公開鍵暗号化 (非対称暗号化とも) と呼ばれる手法の暗号化や、署名に用いられます。 「共通鍵暗」「公開鍵暗号」「電子署名」といったワードは Google Cloud やクラウド特有のものではなく、IT 知識として一般的なものですので、各種 Web サイトをご参照ください。 MAC 署名の鍵は HMAC 署名を行うための鍵です。HMAC は Hash Based Message Authentication Code の略でメッセージ認証符号 (MAC) の一つです。システム間メッセージの改ざん検出やなりすまり防止のために使われます。KMS の MAC 署名目的の鍵を使った署名と検証は 対称鍵を用いて 行われます。 Key のバージョン Key には複数の バージョン を持たせることができます。またバージョンの一つを プライマリのバージョン (メインのバージョンとも呼称) として指定できます。 鍵の利用時に明示的に指定しない場合、プライマリのバージョンが用いられます。ただし非対称鍵にはプライマリバージョンが無く、常にバージョンを指定する必要があります。 また鍵のバージョンは「有効」「無効」「破棄の予定」「破棄」という状態を持っており、バージョンごとに無効化したり破棄したりすることができます。 保護レベル (ストレージ) 鍵は 保護レベル という属性を持ち、これにより鍵を保存するストレージが決まります。 SOFTWARE HSM EXTERNAL EXTERNAL_VPC 最も使われるケースが多いのが SOFTWARE で、Google Cloud の強固なセキュリティの元に管理されます。 HSM はその名の通りフルマネージドの HSM (Hardware Security Module) によって管理されます。料金は SOFTWARE よりも割高です。 EXTERNAL と EXTERNAL_VPC は、KMS ではない外部の鍵管理システムで管理されている鍵を KMS を経由して利用するための保護レベルです。ユーザーの独自の鍵管理システムに KMS 経由でアクセスし、Google Cloud サービスのストレージ暗号化等に用いることができます。この仕組みを利用するために External key manager (EKM) という仕組みを利用します。 Key ring (キーリング) Key ring (キーリング) はその名の通り、鍵をグルーピングするリソースです。Key ring は特定のロケーション (リージョン) に所属します。Key は作成すると存在した時間だけ料金が発生しますが Key ring には料金が発生しません。 なお「 ロケーション (リージョン) 」と表現していますが、ロケーションとリージョンは厳密には異なります。リージョンという言葉は asia-northeast1 (東京) や asia-northeast2 (大阪) など、特定のリージョンを指します。一方でロケーションという言葉は global や asia (アジア)、us (米国) といったマルチリージョン、また各リージョンの中にあるゾーンなども含めた、より広い概念です。 Key ring は作成するロケーションを指定できますが、asia-northeast1 (東京) など特定の単一リージョンを選ぶこともできますし、global や asia (アジア) などのマルチリージョンとして作成することもできます。 そして Cloud Storage バケットや Compute Engine 永続ディスクの暗号化に使える Key は、同じロケーションに存在する必要があります。asia-northeast1 (東京) のバケットであれば Key も asia-northeast1 (東京) に存在する必要がありますし、 asia マルチリージョンのバケットは asia マルチリージョンの Key でしか暗号化できません。このため、Key ring と Key を作成するロケーションは重要です。 リソースの削除 Key や Key のバージョン、また Key ring を一度作成すると 削除はできません 。 Key ring には費用が発生しないため、実質的な問題はありません。 また Key のバージョンは「破棄」することはできます。破棄したバージョンには料金が発生しません。Key のバージョンを全て削除すれば、Key に料金はかかりません。なお「無効」「破棄の予定」の状態のバージョンには料金が発生することにご注意ください。 これらのリソースは一度作成すると一意の ID が割当てられ、それが永続的に続くとお考えください。 鍵のローテーション・バージョン・状態 ローテーション Cloud KMS では対称鍵のみ、自動ローテーションを設定できます。また、API により手動ローテーションをオンデマンド実行することも可能です。 ローテーションされると、Key の新しいバージョンが生成され、バージョン番号が 1 増えます。 自動ローテーションの頻度は Key の作成時に指定できるほか、後から変更することも可能です。自動ローテーションの頻度は 1 日～36,500 日の間で指定することが可能で、デフォルトでは 90 日です。 非対称鍵の場合は、手動ローテーションで新しい秘密鍵を作る場合、公開鍵を配布しなおす必要があります。 バージョン Key には前述の通りバージョンが存在します。Key を新規作成するとバージョンは 1 から始まり、ローテーションするごとに数字が 1 つずつ増えます。 Key のバージョンには一意の ID が割り振られます。 バージョンの無効化と破棄 Key のバージョンは個別に無効化したり、破棄したりすることができます。 重要なポイントとして あるバージョンの Key で暗号化したデータを復号できるのは、そのバージョンだけである という点を理解してください。以下に例を示します。 ある Cloud Storage バケットが、ある Key で暗号化されているとします。あるときオブジェクト A がアップロードされました。このとき Key のプライマリバージョンは 1 だったとします。オブジェクト A はバージョン 1 の Key で暗号化されることになります。 その後のある日、キーがローテーションされ、プライマリバージョンは 2 になりました。この段階ではもちろん、ユーザーは引き続きバージョン 1 で暗号化されたオブジェクト A にアクセスできます。バージョン 1 の Key が有効状態だからです。 あるとき Key のバージョン 1 を何らかの理由で無効化したとします。このときユーザーがこのオブジェクト A にアクセスしようとすると Unable to decrypt with Cloud KMS のエラーが返ります。オブジェクト A を暗号化したバージョン 1 の Key が無効化されているため、Cloud Storage がオブジェクト A を復号できなくなったからです。 状態 Key のバージョンは「有効 ( ENABLED )」「無効 ( DISABLED )」「破棄の予定 ( DESTROY_SCHEDULED )」「破棄 ( DESTROYED )」の 4 つの状態のいずれかを持ちます。 有効 ( ENABLED ) はバージョンが使用可能な状態であることを示します。 無効 ( DISABLED ) はバージョンが明示的に無効化してあり、使用不可の状態です。再度、有効状態に戻すことが可能です。 破棄の予定 ( DESTROY_SCHEDULED ) はバージョンの破棄が指示されており、指定された日時で削除される予定であることを意味します。この状態のバージョンを利用することはできません。この状態のバージョンは「復元」することができます。 この「破棄の予定」という猶予期間はデフォルトでは 24 時間です。期間は Key の作成時にのみ設定でき、あとから変更することはできません。最小は 24 時間で、最大 120 日間です。 Autokey Autokey とは Autokey は、Cloud KMS 鍵の作成、割り当て、ローテーションを自動化する仕組みです。Autokey を有効化することで、Key ring や Key などが必要になった際に、これらが自動的に生成されるようになります。 Terraform との連携も考慮されており、鍵の管理工数を低減することができます。 参考 : Autokey の概要 仕組み Autokey は、 プロジェクト単位 、または フォルダ単位 で有効化します。 ある Google Cloud プロジェクトで Autokey を有効化すると、そのプロジェクト内のリソースのデータを、自動生成した暗号鍵で暗号化できるようになります。2026年2月現在、プロジェクト単位での Autokey 有効化は Preview 段階です。 あるフォルダで Autokey を有効化すると、そのフォルダ配下の Google Cloud プロジェクトで Autokey が使用可能になります。フォルダ単位での有効の場合、暗号鍵は 鍵プロジェクト （key project）と呼ばれる、Autokey の鍵を保存する専用のプロジェクトに集約されます。 Autokey が有効になっているプロジェクトで Cloud Storage バケット、Compute Engine の永続ディスク、BigQuery テーブル、Secret Manager のシークレット、Cloud SQL インスタンス、Spanner インスタンスなど、Autokey に対応しているリソースを作成する際に、Autokey 鍵の作成をリクエストできます。 リクエストが発生すると、Autokey は自動的に、Key ring、Key、サービスアカウント、サービスアカウントへの暗号化と復号の権限付与などが行われます。リソースを作成するユーザーが、これらの作業を手動で行う必要はありません。 有効化 プロジェクト単位で Autokey を有効化するには、 autokeyConfig という API オブジェクトを作成します。2026年2月現在、プロジェクト単位での Autokey 有効化は Preview 段階であり、Web API への直接リクエストしか、有効化の方法が用意されていません。 参考 : Enable Cloud KMS Autokey - Enable Autokey for delegated key management フォルダ単位で Autokey を有効化する際は、鍵を保管するための鍵プロジェクトを Autokey 専用に作成することが推奨されます。その後、対象のフォルダで Autokey を有効化します。このとき、鍵プロジェクトを指定します。フォルダでの有効化は、Google Cloud コンソールから行うことができます。 参考 : Enable Cloud KMS Autokey - Set up Autokey for centralized key management なお、Autokey の有効化は、Terraform で記述することも可能です。 参考 : Enable Cloud KMS Autokey - Enable Autokey using Terraform Autokey の強制 Autokey を有効化したうえで、CMEK の組織ポリシー（ constraints/gcp.restrictNonCmekServices ）や使用する鍵を制限する組織ポリシー（ constraints/gcp.restrictCmekCryptoKeyProjects ）を有効化することで、Autokey の使用を強制することも可能です。 詳細な手順は以下を参照してください。 参考 : Enable Cloud KMS Autokey 鍵の権限管理 Key ring と Key の IAM ポリシー KMS の Key ring と Key には IAM ポリシーを付与でき、鍵へのアクセスを制御することができます。 IAM ポリシーの意味については 当社記事 をご参照ください。これ以降の記述は IAM ポリシーや IAM ロールの意味を理解している前提で記載いたします。特に間違いが起きやすいポイントとして Google Cloud の「IAM ポリシー」「IAM ロール」は AWS の「IAM ポリシー」「IAM ロール」とは意味が異なる点にご留意ください。 Key ring に付与した IAM 権限は配下の Key にも継承されます。ただし Key の各バージョンに個別の IAM ポリシーはありません。つまり権限管理の最小単位は Key となります。 誰が権限を必要とするか 鍵へのアクセス権限は誰が必要とするかを考えます。大まかに以下の2通りです。 鍵の管理 (作成、破棄、ローテーション、無効化、有効化等） 鍵を使った暗号化・復号 前者の「管理」は、Google Cloud の管理者やセキュリティ担当者が権限を持つべきです。 クラウド KMS 管理者 (roles/cloudkms.admin) ロールなどをプロジェクト単位、もしくは Key ring / Key 単位で持つことができます。 後者の暗号化・復号権限については、特に CMEK によるストレージ暗号化で考える場面が出てきます。CMEK によるストレージ暗号化は透過的な暗号化であるため、鍵へのアクセス権限を必要とするのは Google Cloud サービス そのものです。正確に言うと Google Cloud サービスは サービス エージェント と呼ばれる特殊なサービスアカウントを持っています。 Comute Engine や Cloud Storage ではプロジェクトに一つ、サービスエージェントがデフォルトで用意されており、他の Google Cloud サービスの API 呼び出しはこのサービスエージェントによって行われています。このサービスエージェントが裏で KMS を使った暗号化・復号、Pub/Sub への通知などを行っているのです。 例として Cloud Storage のサービスエージェントは service-${プロジェクト番号}@gs-project-accounts.iam.gserviceaccount.com という名称で、最初から存在しており、コンソール画面や gcloud コマンドで確認することができます。 Cloud Storage のサービスエージェント 作成したばかりの鍵に権限変更も加えていない状態で Cloud Storage バケットの CMEK 暗号化を設定しようとすると、コンソール画面で以下のように促されます (以下は Cloud Storage バケットの作成画面です) 。 権限追加を促される 上記はプロジェクトの Cloud Storage サービスエージェントに該当の Key に対する cloudkms.cryptoKeyEncrypterDecrypter ロールを与えるように促すメッセージです。この権限を付与することで、Cloud Storage は Key にアクセスし、暗号化・復号を行うことができます。 なお上記ではサービスエージェントによる Key の利用の例を記載しましたが、それ以外にも KMS 鍵を署名作成などの目的で明示的に利用する場合には、利用するクライアント側で Cloud KMS 暗号鍵の署名者 (roles/cloudkms.signer) などの権限が必要です。 Cloud KMS 関連の定義済みロールについては、以下のドキュメントに網羅されています。 Cloud KMS のロール 職掌分散 (Separation of duties) IT 一般のセキュリティの考え方に 最小権限の原則 と呼ばれるものがあります。個人に業務上必要となる最小の権限だけを与えることを原則とすることでリスクを低減する考え方です。 Cloud KMS でも企業や組織において鍵へのアクセス権限や管理権限を分散し最小限にすることでリスクを下げることがベストプラクティスとされており、これは 職掌分散 (Separation of duties) と呼ばれています。 この考えに基づき、大規模利用においては Cloud KMS の鍵を独自の Google Cloud プロジェクトに集約させることが推奨されています。 KMS 専用プロジェクトにはオーナー (Owner) のロールを付与しない 代わりに組織レベルの組織の管理者 (roles/resourcemanager.organizationAdmin) が鍵の権限を管理する 組織の管理者は鍵自体への利用権限を持たないが鍵の IAM ポリシーを操作する権限を持つため「管理」と「利用」を分離できる 独自の鍵と外部の鍵 鍵のインポート KMS には既存の鍵をインポートすることができます。インポートした鍵は Cloud HSM Key もしくはソフトウェア Key としてインポートされます。 インポートできる鍵には鍵の種類・目的別に要件があるため ドキュメント をご参照ください。 鍵をインポートする前に Key ring と Key を作成しておきます。インポート後の鍵は、その Key の新しいバージョンとしてインポートされます。 外部の鍵の利用 Cloud External Key Manager (Cloud EKM、外部鍵マネージャー) を用いると Cloud KMS から Fortanix や Futurex といったサードパーティ製の鍵管理システムに接続し、外部鍵管理システムの鍵を KMS 鍵のように利用することができます。 外部鍵管理システムとの接続は「インターネット経由」「 VPC 経由 」を選択することができます。 EKM で取り込んだ外部鍵は Compute Engine や Cloud Storage、BigQuery で CMEK 暗号化に利用することができます。 Cloud EKM 経由で外部鍵管理システムの鍵を利用できる 暗号化の手法と技術 エンベロープ暗号化 エンベロープ暗号化 という技術があります。これは Cloud KMS による暗号化で使われている技術であり、AWS の KMS 等でも使われています。透過的暗号化においてはユーザーの意識しないところで行われているため、知らなくても業務に支障はありません。 エンベロープ暗号化ではデータを暗号化する鍵そのもの (Data Encryption Key = DEK) とその DEK を暗号化する別の鍵 (Key Encryption Key = KEK) の二段階を用います。 都度生成する DEK でデータを暗号化し、DEK 自体は KMS で生成・管理する KEK で暗号化したうえでデータと一緒に保管します。データを利用するときは KEK で DEK を復号し、復号された DEK でデータを復号します。KEK は KMS の外に出ることはなく、セキュアに管理されます。 文字での解説には限界があるため、図による解説があるドキュメントをいくつかご紹介します。 以下は Google Cloud の公式ドキュメントです。 エンベロープ暗号化 以下は AWS Encryption SDK の公式ドキュメントです。エンベロープ暗号化について図解しています。 AWS Encryption SDK の概念 - エンベロープ暗号化 アルゴリズム 選択できる鍵の暗号化アルゴリズムは、鍵の目的によって異なります。 目的が対称暗号化 / 復号 (Symmetric encrypt/decrypt) の対称鍵の場合、 GOOGLE_SYMMETRIC_ENCRYPTION アルゴリズムが利用され、 Galois Counter Mode (GCM) / AES-256 鍵となります。 目的が非対称署名 (Asymmetric signing) の非対称鍵の場合、楕円曲線署名 / RSA 署名アルゴリズムのうち複数の中から選択することができます。また非対称鍵の目的が非対称暗号化 / 復号 (Asymmetric encrypt/decrypt) の場合も、RSA アルゴリズムの中から選択できます。 詳細は以下のドキュメントをご参照ください。 鍵の目的とアルゴリズム Cloud KMS リソースの整合性 Cloud KMS リソース (Key や Key ring) は、作成・削除・無効化などのオペレーションに対して、リソースごとに 異なる整合性 を持っています。 KMS リソースに対するオペレーションには 強整合性 と 結果整合性 の 2 種類があります。強整合性オペレーションは実行後に直ちに適用されます。結果整合性のオペレーションは通常は 1 分以内に Google Cloud 内に伝播されますが、最大で 3 時間かかるとされています。 オペレーションごとの整合性は以下のとおりです。 オペレーション名 整合性 Key ring の作成 強整合性 Key の作成 強整合性 Key のバージョンの有効化 強整合性 Key のバージョンの無効化 結果整合性 Key のプライマリ (メイン) バージョンの変更 結果整合性 IAM 権限の変更 結果整合性 (通常は数秒) 注目すべき点は、鍵バージョンの無効化や IAM アクセスの変更が結果整合性である点です。鍵を使えなくするためにバージョンを無効化しても、最大で 3 時間、鍵が使える状態になってしまう可能性があります。また IAM 権限の削除も、通常は数秒で反映されますが、1 時間程度かかる場合もあります。 杉村 勇馬 (記事一覧) 執行役員 CTO 元警察官という経歴を持つ IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 認定資格および Google Cloud 認定資格はすべて取得。X（旧 Twitter）では Google Cloud や Google Workspace のアップデート情報をつぶやいています。 Follow @y_sugi_it

G-gen 杉村です。Google Cloud の無償 BI ツール「データポータル（英名 Data Studio、旧称 Looker Studio）」の有償版である データポータル Pro について解説します。 概要 データポータル Pro とは 名称の変遷 機能 利用開始方法 サブスクリプション 利用開始手順 注意点とトラブルシューティング Gemini in データポータル アセット ワークスペース ワークスペースとは 自分のスペース（My workspace） チームワークスペース（Team workspace） 権限管理 概要 データポータルの権限管理 チームワークスペース用のロール アセット用のロール IAM 権限管理 IAM 権限とデータポータル権限の使い分け 退職者対応 強化されたメール配信機能 概要 データポータル Pro とは データポータル Pro （英名 Data Studio Pro、旧称 Looker Studio Pro）とは、Google Cloud の無償 BI ツールである データポータル （英名 Data Studio、旧称 Looker Studio）の有償版です。 データポータル Pro では無償版と比較してエンタープライズ向け機能が強化されており、また Google Cloud のカスタマーケア（技術サポート）の対象となります。また SLA（99.9%の可用性）の対象となるなど、組織での大規模利用に適したものとなっています。 参考 : データポータル Pro について 名称の変遷 データポータルは以前、Looker Studio と呼ばれていました。しかし、さらにそれ以前は現在と同様、「英名: Data Studio / 和名: データポータル」という名称でした。 2022年10月の Google Cloud Next '22 でデータポータルは「Looker Studio」に名前が変更され、Looker ブランドに統一されました。この変更により Looker と Looker Studio の2つの製品が存在する状態になり、混乱を呼びました。 しかし再度、2026年4月に「英名: Data Studio / 和名: データポータル」に戻りました。 日本では商標の関係で「Data Studio」という名称が使えないため「データポータル」と表記されています。 機能 データポータル Pro では、無償版のデータポータルにはない、以下のような追加の機能が利用できます。 機能名 説明 Gemini in データポータル 生成 AI モデル Gemini による補助機能。 ・Google スライドへのエクスポート ・計算フィールドの生成 チームワークスペース ・共同編集するための箱のこと ・ここにアセット (レポートとデータソースを指す) を入れることで、ワークスペースに対する権限を持つメンバー間で共同編集できるようになる ・チームワークスペースへの閲覧権限付与も可能 管理者権限 によるアセット管理 (IAM) ・データポータル Pro と紐づけた Google Cloud プロジェクトに IAM 権限を付与することで、管理者が全てのチームワークスペース内のアセットを見通すことができるようになる 強化された メール配信機能 無償版より強化されたレポート配信機能。 ・即時配信 ・Google チャットや Slack への配信 ・同一レポートへの複数スケジュール作成 ・受信者に応じたフィルタなど 退職者対応 ・データポータル Pro を有効化していると、アセットは組織によって管理されるようになり、作成者のアカウントが削除されてもアセットは削除されない ・一方の無償版データポータルではアセットのオーナーは個人アカウントのため、退職等でアカウントが削除される前にオーナーを移行する等の作業が必要 サポート ・公式サポート（Google Cloud カスタマーケア）のサポート対象 参考 : データポータル Pro コンテンツについて 利用開始方法 サブスクリプション データポータル Pro の利用には、ライセンス (サブスクリプション) を追加で購入する必要があります。購入方法は二種類あります。 ユーザ単位の有効化 月間アクティブユーザー（MAU）サブスクリプション 前者の「ユーザ単位の有効化」は、データポータルのコンソール画面から実行できます。1ユーザあたり月額 $9 の料金が発生します（2025年12月現在）。 後者の「月間アクティブユーザー（MAU）サブスクリプション」は、Google Workspace（Cloud Identity）組織全体で有効化されます。MAU（Monthly Active User。月内で1度でも、データポータル Pro を利用した人がカウントされる）あたりの月額費用がかかります。費用や有効化の方法は、Google Cloud や販売パートナーの営業担当者にお問い合わせください。 参考 : Looker Studio の料金 参考 : データポータル Pro サブスクリプションの概要 なお Looker を利用中の場合、Looker のユーザーライセンス1つごとに、データポータル Pro ライセンスが1つ、無料で付帯します。 参考 : Complimentary Looker Studio Pro licenses offer details 利用開始手順 データポータルのコンソール画面、または Google Cloud のコンソール画面から、データポータル Pro を有効化できます。有効化する際に、課金対象となる Google Cloud 請求先アカウントや、紐づけ先の Google Cloud プロジェクトを選択します。これによりデータポータルはデータポータル Pro にアップグレードされます。 詳細な手順は、以下をご参照ください。 参考 : Pro の新しいサブスクリプションを開始する 注意点とトラブルシューティング データポータル Pro を有効化して Google Cloud プロジェクトと紐づける際、操作者は以下の IAM ロールを持っている必要があります。 紐付けるプロジェクトに対するオーナー（ roles/owner ）もしくは Looker Studio Pro マネージャー（ roles/lookerstudio.proManager ）ロール 権限が足りないと、ひも付け時に「組織のプロジェクトを更新できませんでした。」といったエラーが出る場合があります。 Gemini in データポータル データポータル Pro では、 Gemini in データポータル 機能により、可視化にあたって生成 AI の補助を受けることができます。 参考 : Gemini in データポータルの概要 Gemini in データポータルには、以下のような機能があります。 数式フィールド（calculated fields）を自然言語の指示により作成 データポータルのコンテンツを Google スライドにエクスポート アセット データポータルにおける アセット とは レポート と データソース を指す概念です。 レポート とは、データポータルで実装されるダッシュボードです。 データソース とは、レポートから参照される BigQuery 等のデータベースやスプレッドシートなど、データ保有元との接続設定を指します。一度データソースを作ると、別のレポートでもそのデータソースを再利用できます。 参考 : アセット 参考 : レポート 参考 : データソース ワークスペース ワークスペースとは ワークスペース とは、アセットを共同編集するために入れておく「箱」のような概念です。 自分のワークスペース （My workspace）と チームワークスペース （Team workspace）の2種類があります。 自分のスペース（My workspace） 前者の「 自分のワークスペース 」は自分専用の編集スペースであり、無償版のデータポータルで「自分がオーナー（Owned by me）」として表示されるアセットと同様です。他人から閲覧したり編集したりするには、アセット一つ一つに「閲覧者」や「編集者」ロールを付与する必要があります。またここに入っているアセットは、作成者が「オーナー」となります。 チームワークスペース（Team workspace） 後者の「 チームワークスペース 」は共同編集用の編集スペースであり、これがデータポータル Pro の最大の特徴です。ここに入れたアセットは、チームワークスペース自体に権限を持っている人（アカウント）であれば、共同で編集することができます。 チームワークスペースに付与できるのはどのような権限なのかは、後述します。 参考 : チーム ワークスペースについて 権限管理 概要 データポータル Pro の権限管理には大きく分けて2つの軸があります。1つは データポータルの権限管理 で、もう1つは IAM の権限管理 です。 以下にそれぞれを説明し、最後にそれらの使い分けについて解説します。 データポータルの権限管理 チームワークスペース用のロール データポータル上では、チームワークスペースやアセットにそれぞれ権限を付与できます。 各チームワークスペースに付与できるロールは、以下のとおりです。なおロールの日本語名は Web コンソール画面の表記を元にしており、ドキュメント上のものと異なる場合があります。 ロール名 説明 閲覧者 ワークスペース内のアセットを閲覧（フォルダ・ゴミ箱含む） 投稿者 ワークスペース内のアセットを閲覧・編集、アセットの新規作成、アセットにロール追加など コンテンツ管理者 投稿者の権限に加え、ワークスペースに他の投稿者を追加・削除できる マネージャー コンテンツマネージャの権限に加え、他のコンテンツマネージャを追加したり、ロール変更、アセットを他のワークスペースに移動できる等 参考 : ロールと権限 - チーム ワークスペースのロール アセット用のロール 一方で各アセットに付与できるロールは以下のとおりです。これらは基本ロールとも呼ばれます。 ロール名 説明 閲覧者 閲覧のみ（レポートやデータソースのスキーマ） 編集者 編集できる。またアセットの権限を変更できる オーナー 編集者の権限に加え、アセットを削除したり、他の誰かをオーナーにできる なお「自分のワークスペース」内のアセットは、作成者が最初のオーナーになる。チームワークスペースに所属しているアセットには「オーナー」が存在しない アセットには、閲覧者または編集者ロールを付与することができます。例えばあるレポートにおいて「〇〇部署の Google グループには閲覧者ロールを付与」「レポートを管理する XX 部署のグループには編集者ロールを付与」のように権限を分けられます。 オーナーだけは特殊なロールで、アセットがマイスペースにあるときに、作成者が自動的に「オーナー」になります。 参考 : ロールと権限 - 基本ロール IAM 権限管理 IAM 権限管理は、どちらかというとデータポータル Pro の利用者を横断で管理するような管理者向けの権限設定に用います。 利用開始時にデータポータル Pro と紐づけた Google Cloud プロジェクトに、プロジェクトレベルの IAM 権限を付与することで、権限を管理します。 例として、あるアカウントに対して、データポータル管理者（ roles/datastudio.admin ）ロールを Google Cloud プロジェクトレベルで付与すると、その人はデータポータル内の全てのワークスペースの編集・読取、および全てのアセットの編集・読取ができるようになります。 このように、付与する IAM ロールごとに付与される権限が異なります。以下に例を示します。なお表中のロールの日本語名は Web コンソール画面の表記を元にしており、ドキュメントの記載と異なる場合があります。 ロール名（日本語名） ロール ID 説明 データポータル管理者 roles/datastudio.admin ワークスペース・レポートに対する全権限 データポータル ワークスペース コンテンツ マネージャー roles/datastudio.contentManager ワークスペースに対する閲覧・アセット作成等と、アセットに対する閲覧・更新等 データポータル アセット編集者 roles/datastudio.editor アセットに対する閲覧・更新等。ただしワークスペースの閲覧・編集権限は無し データポータル アセット閲覧者 roles/datastudio.viewer アセットに対する閲覧。ただしワークスペースの閲覧・編集権限は無し 参考 : Data Studio roles and permissions 参考 : データポータル Pro の月間アクティブ ユーザー サブスクリプションを Google Cloud プロジェクトにリンクする IAM 権限とデータポータル権限の使い分け 以上のことから、データポータル Pro 側の権限管理と IAM（Google Cloud）側の権限管理は、以下のような使い分けが想定されます。 データポータル Pro 側の権限管理 : ワークスペース単位またはアセット単位で、 編集権限や閲覧権限を管理 する IAM 権限 (Google Cloud) : 組織全体でワークスペースを管理したり統制を効かせるための、 管理者特権を管理 する 退職者対応 レポート作成者の Google アカウントが削除された場合で、かつ削除時に「データのオーナー権限を移行しない」を選択した場合、アセットは以下のような挙動となります。 作成者の「自分のワークスペース」に入っていたアセット アセットのオーナーは「削除されたユーザー」となります。Google Cloud プロジェクトへの IAM 権限を持っている人には「共有アイテム」として見えます。編集権限があれば、チームワークスペースに移動することができます。 作成者の「チームワークスペース」に入っていたアセット アセット作成者の Google アカウントが削除されても、アセットは引き続きチームワークスペースに所属します。 強化されたメール配信機能 データポータル Pro では、無償版と比べてメール配信機能が強化されています。 無償版データポータルでも定期的にレポートの内容をメールで配信することができますが、Pro では無償版と比較して以下の違いがあります。 メールの即時配信（Send now オプション） Google チャットへの配信 Slack への配信 1つのレポートの複数のスケジュールを作成 メール受信者に応じてレポートをフィルタする レポートのプレビューをメールに埋め込み 以下の公式ドキュメントも参照してください。 参考 : レポートの自動配信をスケジュール設定する 参考 : Slack でレポートを共有、スケジュール設定する 杉村 勇馬 (記事一覧) 執行役員 CTO 元警察官という経歴を持つ IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 認定資格および Google Cloud 認定資格はすべて取得。X（旧 Twitter）では Google Cloud や Google Workspace のアップデート情報をつぶやいています。 Follow @y_sugi_it

Google Cloud (旧称 GCP) の仮想サーバーサービスである Compute Engine では Windows Server を起動することができます。 Windows Server の VM で、ライセンス認証に関するエラーが出たときの対処方法をご紹介します。 事象 考えられる原因 対処方法 1. ルートを確認する 2. アクセス要件を解決する 3. ファイアウォールルールの追加 4. ライセンス認証の強制 参考ドキュメント 事象 Compute Engine で起動する Window Server の VM において、コンピュータのプロパティの画面等でライセンス認証が失敗している旨のメッセージが出力されることがあります。 「 Windows はライセンス認証されていません 」 「 組織のライセンス認証サーバーに接続できないため、このデバイスの Windows をライセンス認証できません。組織のネットワークに接続していることを確認して、もう一度やり直してください。ライセンス認証できない場合は、組織のサポート担当者にお問い合わせください。エラーコード: 0xC004F074 」 「 ライセンス認証に問題がある場合は、トラブルシューティングを選択して問題の解決を試みてください。 」 Windows はライセンス認証されていません 考えられる原因 該当の VM と Google Cloud の持つ Windows Key Management Service (KMS) サーバーの間の通信ができていない ことが原因と考えられます。 Google Cloud の KMS サーバーは kms.windows.googlecloud.com (35.190.247.13) に存在します。このサーバーと Windows Server VM が TCP 1688 番ポートにて通信できる必要があります。 この通信が失敗する原因として VPC ファイアウォールやルートの問題、または VM が外部 IP アドレスを持っていないなどの理由が挙げられます。 参考 : kms.windows.googlecloud.com へのアクセスを構成する 対処方法 1. ルートを確認する VPC のルート設定として、デフォルトゲートウェイ (0.0.0.0/0) が Default Internet Gateway へ向いているか、個別ルールで 35.190.247.13/32 のネクストホップが Default Internet Gateway へ向いている必要があります。 2. アクセス要件を解決する VM が kms.windows.googlecloud.com (35.190.247.13) へ到達するには、以下のいずれかの方法である必要があります。 外部 IP アドレスを持っている サブネットで 限定公開の Google アクセス が有効である 重要なことに、 KMS へは Cloud NAT 経由では到達できない 仕様となっています (Compute Engine インスタンスの IP アドレス以外からのリクエストは拒否されるためと 説明されています ) 。そのため VM に外部 IP アドレスを持たせるか、サブネットで「限定公開の Google アクセス」が有効である必要があるのです。 3. ファイアウォールルールの追加 VPC のファイアウォールルールでも 35.190.247.13/32 への 1688/tcp における 下り 通信が許可されている必要があります。 デフォルトでは「暗黙の下り許可」ルールが効いているため許可されていますが、厳密なファイアウォールルールを適用している場合は、この通信を明示的・優先的に許可するルールが必要です。 4. ライセンス認証の強制 上記まで実施すれば、 KMS への通信は確保されます。上記がクリアされているのに認証が行われない場合、 VM 上で以下の作業を実施することでライセンス認証を強制させます。 コマンドプロンプトを「管理者として実行」する 下記コマンドを実行して、KMS サーバーへの接続が完了しているかをテストする powershell.exe Test-NetConnection 35.190.247.13 -Port 1688 想定結果 TcpTestSucceeded : True 上記コマンドが成功した場合、以下の下記コマンドを実行する (ライセンスの現在の状態を確認 / KMS のサーバー IP アドレスを設定 / ライセンス認証を強制) cscript \windows\system32\slmgr.vbs /dlv cscript \windows\system32\slmgr.vbs /skms 35.190.247.13:1688 cscript \windows\system32\slmgr.vbs /ato 参考ドキュメント 参考 : Windows VM のトラブルシューティング 杉村 勇馬 (記事一覧) 執行役員 CTO / クラウドソリューション部 部長 元警察官という経歴を持つ現 IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 12資格、Google Cloud認定資格11資格。Twitter では Google Cloud や AWS のアップデート情報をつぶやいています。 Follow @y_sugi_it

G-gen ビジネス推進部の菊池です。 当社の働き方を紹介することで、みなさんの業務効率・コミュニケーション円滑化の一助になれば幸いです。 当社は社員全員が勤務地に縛られることなく、フルリモートで勤務しています。 フルリモート勤務を可能としているのが、GoogleのコラボレーションツールであるGoogle Workspaceです。 Google Workspaceを活用することにより”協業型”の働き方を実践し、フルリモートの環境下においても常に繋がりを持ちながら業務を遂行しています。 当記事ではGoogle Meetをはじめ、Google Workspaceの各種ツールを用いて当社が実践しているWeb会議の準備や進め方から議事録の共有に至るまでをご紹介します。 Web会議の準備 Web会議の進め方 Web会議終了後 Web会議の準備 Googleカレンダーをクリックし、会議の予定を入力します。 タイトルに［社内］［社外］を入力するとスケジュールの判別がしやすくなります。 「会議メモを作成」をクリックすると会議内容を反映したメモが添付されます。 ・タイトル　ex.［社内］営業会議 ・日時 ・ゲストを追加 ・会議メモを作成 なお、社外とweb会議を行う際は、以下の手順で簡単に会議用URLの送付が出来ます。 ・「会議情報をコピー」をクリック ・メール本文にコピー＆ペーストでURLを記載する 会議の準備は以上で完了です。 Web会議の進め方 先程カレンダーに添付した「会議メモ」に会議の参加者全員でリアルタイムに書き込みます。Web会議中の発言者は議事録を書くことが難しいため、発言者以外のメンバーにて共同で議事録を編集します。 Web会議終了後 Web会議終了後は作成した議事録をお知らせしたいメンバーに共有します。 例えば欠席してしまったメンバーに共有することで簡単に情報共有が可能です。 議事録を開き、「共有」ボタンをクリックし、共有したいメンバーを追加します。 Googleドキュメントにはメンション機能があり、ドキュメント内で「@ + ユーザー名」で特定のユーザーへコメントすることができます。 メンション機能を利用することで、わざわざメールやチャットなどを使って連絡する必要がなく、業務効率化とコミュニケーション円滑化に繋がります。 菊池 勇一 (記事一覧) ビジネス推進部 2022年5月にG-gen にジョイン。 勢いとスピード感を求めて大手製造業の販売会社からGoogle Cloudの営業にキャリアチェンジ！小さい脳みそをフル回転させながら日々勉強中。

G-gen の佐々木です。当記事では、Google Cloud (旧称 GCP) のサーバーレスコンテナサービスである Cloud Run について、Cloud Run サービスからインターネット接続を行う際に Public IP アドレスを固定する方法を解説します。 使用するサービス・仕組み Cloud Run サーバーレス VPC アクセス 構成図 Cloud Run サービスのデプロイ アプリケーションを作成する main.py requirements.txt Dockerfile コンテナイメージを Artifact Registry に格納する リポジトリを作成する コンテナイメージをビルドしてリポジトリに格納する ビルドしたイメージを使用して Cloud Run サービスをデプロイする インターネット接続に動的 IP アドレスが使用されることを確認する 静的 IP アドレスを使用したインターネット接続 サーバーレス VPC アクセスコネクタを作成する Cloud NAT を設定するための Cloud Router を作成する 静的 IP アドレスを使用する Cloud NAT を設定する コネクタを使用するように Cloud Run サービスを設定する インターネット接続に静的 IP アドレスが使用されることを確認する 使用するサービス・仕組み Cloud Run Cloud Run はサーバーレスな環境でコンテナを実行できるサービスです。 サービスの全体像については以下の記事で解説していますので、ご一読ください。 blog.g-gen.co.jp サーバーレス VPC アクセス サーバーレス VPC アクセス は Cloud Run や Cloud Functions などのサーバーレス実行環境から VPC 内リソースにアクセスするための仕組みです。 サーバーレス VPC アクセスを設定すると、VPC 内に コネクタ が作成され、サーバーレス実行環境からの通信を VPC にルーティングすることができます。 構成図 Cloud Run サービスでは、 コンテナからインターネット通信を行う際、動的 IP アドレスプールを使用するのがデフォルトの動作 となっています。 したがって、接続先となる外部エンドポイントで IP アドレスベースのファイアウォールが設定されているなど、静的 IP アドレスが必要となるケースでは、デフォルトの設定では上手くいきません。 そこで、サーバーレス VPC アクセスを使用して Cloud Run サービスを VPC に接続し、静的 IP アドレスを使用する Cloud NAT を経由してインターネット通信を行うように設定します。 サーバレス VPC アクセスコネクタ と Cloud NAT を経由したインターネット接続 Cloud Run サービスのデプロイ アプリケーションを作成する Cloud Run ドキュメントの クイックスタート をベースとし、アプリケーションを実行するコンテナがインターネット接続に使用した IP アドレスを確認できるようにコードを書き換えます。 IP アドレスの確認には DynDNS を使用します。 http://checkip.dyndns.com/ に対して HTTP リクエストを送信することで、現在使用している IP アドレスの情報が返ってきます。 main.py DynDNS に HTTP リクエストを送信し、レスポンスをブラウザ上に表示するようにします。 import requests from flask import Flask app = Flask(__name__) # DynDNS の URL url = 'http://checkip.dyndns.com/' @ app.route ( '/' ) def ip_check (): # HTTP リクエストを送信 res = requests.get(url) # レスポンスをブラウザ上に表示 return res.text if __name__ == '__main__' : app.run(debug= True , host= '0.0.0.0' , port= 8080 ) requirements.txt クイックスタートの requirements.txt に requests パッケージを追記します。 Flask==2.1.0 gunicorn==20.1.0 requests==2.28.1 Dockerfile クイックスタートの Dockerfile をそのまま使用します。 FROM python:3.10-slim ENV PYTHONUNBUFFERED True ENV APP_HOME /app WORKDIR $APP_HOME COPY . ./ RUN pip install --no-cache-dir -r requirements.txt CMD exec gunicorn --bind :$PORT --workers 1 --threads 8 --timeout 0 main:app コンテナイメージを Artifact Registry に格納する Cloud Run サービスに使用するコンテナイメージをビルドします。 当記事では Cloud Build を使用してイメージをビルドし、Artifact Registry に格納します。 リポジトリを作成する まず、 Artifact Registry のリポジトリを作成します。 $ gcloud artifacts repositories create {リポジトリ名} --repository-format=docker --location={ロケーション} # 実行例 $ gcloud artifacts repositories create myrepository --repository-format=docker --location=asia-northeast1 コンテナイメージをビルドしてリポジトリに格納する Cloud Build を使用してコンテナイメージをビルドし、先ほど作成したリポジトリに push します。 $ gcloud builds submit --tag {ロケーション}-docker.pkg.dev/{プロジェクトID}/{リポジトリ名}/{イメージ名} # 実行例 $ gcloud builds submit --tag asia-northeast1-docker.pkg.dev/myproject/myrepository/myimage ビルドしたイメージを使用して Cloud Run サービスをデプロイする まずはコンテナイメージをそのまま Cloud Run にデプロイしていきます。 Artifact Registry に格納したコンテナイメージから Cloud Run にデプロイする を選択します。 Artifact Registry から Cloud Run サービスをデプロイ 任意の サービス名 、 リージョン を設定します。 サービス名とリージョンを設定する 今回はサービスの呼び出し元は特に考慮しないので、 Ingress 項目の「すべてのトラフィックを許可する」、 認証 項目の「未認証の呼び出しを許可」にチェックを入れ、Cloud Run サービスを作成します。 Ingress と 認証の設定 インターネット接続に動的 IP アドレスが使用されることを確認する サービスのデプロイが完了したら、サービスの詳細画面にある Cloud Run サービスの URL をクリックします。 Cloud Run サービスの URL アプリケーションが実行され、実行基盤となったコンテナがインターネット通信に使用している IP アドレスがブラウザ上に表示されます。 コンテナがインターネット接続に使用している IP アドレスが表示される その後、起動したコンテナが削除されるまでしばらく待ちます。 コンテナ インスタンス数 のメトリクスで active と idle の値が 0 になってから、もう一度サービスの URL にアクセスします。 コンテナ インスタンス数の active と idle の値が 0 になるまで待つ 先ほどとは異なるコンテナ上でアプリケーションが実行され、ブラウザには別の IP アドレスが表示されます。 このように、デフォルトの設定では、コンテナは動的 IP アドレスプールを使用してインターネット通信を行います。 コンテナが新たに起動するため、別の IP アドレスが使用される 静的 IP アドレスを使用したインターネット接続 サーバーレス VPC アクセスコネクタを作成する VPC にサーバーレス VPC アクセスコネクタを作成していきます。 VPC ネットワーク のコンソールからコネクタの作成画面に進みます。 VPC ネットワークのコンソールからコネクタを作成する ネットワーク に使用する VPC を設定し、 サブネット で「カスタム IP 範囲」を選択します。 IP 範囲 に VPC で使用されていない /28 の IP 範囲を入力し、コネクタを作成します。 サーバーレス VPC アクセス コネクタの作成 「スケーリング設定を表示」を開くと、コネクタインスタンスの最小/最大数の設定や、インスタンスが使用するマシンタイプ（f1-micro/e2-micro/e2-standard-4）を設定することができます。 最小インスタンス数は 2~9、最大インスタンス数は 3~10 の値を設定することができますが、 コネクタインスタンスが一度スケールアウトするとスケールインすることができない 仕様のため、最大インスタンス数は慎重に設定しましょう。 サーバーレスVPCアクセスコネクタのスケーリング設定 Cloud NAT を設定するための Cloud Router を作成する Cloud NAT は VPC 、リージョン、そして Cloud Router に関連付けられるため、VPC に対して Cloud Router を作成します。 ハイブリッド接続 のコンソールから Cloud Router を作成していきます。 ハイブリッド接続のコンソールから Cloud Router を作成する 名前 、 ネットワーク 、 リージョン を設定し、それ以外の項目はデフォルトのまま作成します。 Cloud Router の作成 静的 IP アドレスを使用する Cloud NAT を設定する ネットワーク サービス のコンソールから Cloud NAT を作成していきます。 ネットワーク サービスのコンソールから Cloud NAT を作成する 先ほど作成した Cloud Router を設定し、 Cloud NAT IP アドレス 項目で「手動」を選択して、「IP アドレスを作成」をクリックします。 Cloud NAT の作成 予約する静的 IP アドレスの名前を入力し、「予約」をクリックします。 静的 IP アドレスの予約 予約した静的 IP アドレスが CLoud NAT に設定されるので、「作成」をクリックします。 予約した静的 IP アドレスが設定される コネクタを使用するように Cloud Run サービスを設定する Cloud Run サービスの詳細画面から 新しいリビジョンの編集とデプロイ を選択し、サーバーレス VPC アクセス コネクタを使用するようにサービスを設定します。 Cloud Run サービスを編集する 編集画面の 接続 タブにある VPC 項目で コネクタを作成した VPC を選択し、「すべてのトラフィックを VPC コネクタ経由でルーティングする」にチェックを入れます。 サーバーレス VPC アクセス コネクタの設定 「デプロイ」を選択し、Cloud Run サービスを更新します。 インターネット接続に静的 IP アドレスが使用されることを確認する Cloud Run サービスの URL をクリックし、アプリケーションを実行します。 ここまでの設定により、コンテナ は VPC にある Cloud NAT を経由してインターネットアクセスを行うため、ブラウザに表示される IP アドレスが Cloud NAT に設定した静的 IP アドレスになっています。 Cloud NAT の静的 IP アドレスが表示される Cloud NAT の静的 IP アドレス 佐々木 駿太 (記事一覧) G-gen最北端、北海道在住のクラウドソリューション部エンジニア 2022年6月にG-genにジョイン。Google Cloud Partner Top Engineer 2024に選出。好きなGoogle CloudプロダクトはCloud Run。 趣味はコーヒー、小説（SF、ミステリ）、カラオケなど。 Follow @sasashun0805

G-gen の杉村です。 Google Cloud（旧称 GCP）の、 タグ （Tags）と ラベル （Labels）の違いについて解説します。 タグとラベル タグとラベルの概要 利用例 タグとラベルの違い 比較表 リソースとしての扱い IAM や組織ポリシーでの利用 IAM 組織ポリシー 課金管理 課金明細への反映 課金情報の BigQuery エクスポート タグの使い方 タグキー・バリューの作成 リソースへの紐づけ フォルダ・プロジェクト 個別リソース プロジェクトセレクターに環境名を表示 トラブルシュート ラベルの使い方 ラベルの付与 ラベルによるフィルタ タグとラベル タグとラベルの概要 Google Cloud（旧称 GCP）には、 タグ （Tags）と ラベル （Labels）という、よく似ているもののまったく異なる概念が存在します。 参考 : タグの概要 参考 : ラベルを使用してリソースにコンテキストを追加する - 概要 タグとラベルは、どちらもキー・バリューの文字列のペアであり、Google Cloud リソースに紐づけることができるという性質を持ちます。しかし、この2つは まったく別の機能 です。タグとラベルの違いは、端的に述べると以下のとおりです。 タグは 権限管理 のための機能 ラベルは リソース整理 や 課金の整理 のための機能 利用例 タグの利用例は、以下です。 本番環境フォルダには environment: prod タグを付与する 検証環境フォルダには environment: test タグを付与する IAM 許可ポリシーの条件（conditions）にタグを条件として追加して、環境を操作できるアカウントを制限する 一方で、ラベルの利用例は以下のようなものです。 gcloud コマンドで VM インスタンスを一覧表示（list）する際に、ラベルを指定してフィルタする。これにより、特定サブシステムの VM だけを抽出する タグとラベルの違い 比較表 タグトラベルの性質の違いを一覧にすると、以下のとおりです。 参考 : タグとラベル タグ ラベル リソース構造 キー、バリュー、バインディング（紐づけ）はそれ自体がリソース ラベル自体はリソースでなく、リソースのメタデータ 定義 組織またはプロジェクトでリソースとして作成 各リソースのメタデータとして定義 アクセス制御 タグ管理用の IAM 権限が存在 付与対象リソースごとの IAM 権限 事前定義 キーとバリューを事前定義する 事前定義なし 継承 Google Cloud 階層の子リソースに継承される 子リソースに継承されない 文字長 256文字以下 63文字以下 IAM ポリシー IAM ポリシーの条件 (Condition) として利用可能 IAM ポリシーから利用不可 組織ポリシー 組織ポリシーの条件付き制約として利用可能 組織ポリシーから利用不可 Billing 連携 ・BigQuery の Cloud Billing データとしてエクスポートされる ・BigQuery の Cloud Billing データとしてエクスポートされる ・Cloud Billing レポートのフィルタリングに使用可 リソースとしての扱い 大きな違いとして、 タグはそれ自体がリソースである 一方で、ラベルはリソースに付与する メタデータである という点です。 タグは組織レベル、またはプロジェクトレベルで、事前にキーとバリューのペアを定義します。定義されているキー、バリューを、リソースに紐づけることができます。また、紐づけ設定はバインディングというリソースとして実体があります。 ラベルは、リソースのメタデータとして付与するので、それ自体はリソースではありません。 また、タグには継承の概念があります。例えばフォルダにタグを紐づけると、配下のプロジェクトにも引き継がれます。 IAM や組織ポリシーでの利用 IAM タグは、主に権限管理のために用いられます。 IAM 許可ポリシーのロールバインディングには、条件（Condition）を記載することができ、例えば「◯時〜◯時の間だけ権限が有効」など条件をつけることができます。ロールバインディングの条件として「〇〇というタグがリソースに付与されていること」のように設定が可能です。 参考 : タグと条件付きアクセス 参考 : Google CloudのIAMを徹底解説！ - G-gen Tech Blog - IAM ポリシーの構造 例えば本番プロジェクトが格納されているフォルダに environment : prod タグを、開発用プロジェクトが入っているフォルダに environment : test タグを付与します。ロールバインディングの条件に「 environment : test タグ」を指定すれば「この Google グループは environment : test タグのついたプロジェクトにだけ権限が有効である」のように制限することが可能です。 組織ポリシー タグは、組織のポリシーの条件としても利用できます。 特定タグのついたプロジェクトにのみポリシーを適用する、といった条件付けが可能です。 参考 : 組織のポリシーを解説 - G-gen Tech Blog 参考 : 組織のポリシーをタグで制御してみた - G-gen Tech Blog 参考 : タグを使用した組織のポリシーの設定 課金管理 課金明細への反映 ラベルは、課金管理のために用いることができます。 請求先アカウントの課金レポート画面で、リソースに付与されたラベルによって「何にいくら利用料金がかかっているのか」を明細表示することができます。 請求先アカウントのレポート画面 例えば owner : xxx のようにオーナー部署のラベルを付与しておけば、利用料金を社内請求するときに利用できます。 なおラベル情報が課金に反映されるのは、 ラベルを付与した時より後の課金のみ です。ラベル付与前の課金情報にまで遡って反映されることはありませんので、ご注意ください。 参考 : Cloud Billing の概要 - ラベル 課金情報の BigQuery エクスポート 請求先アカウントの課金明細は BigQuery にエクスポートすることができます。エクスポート内容には、ラベル情報が含まれます。BigQuery を用いて SQL により詳細に課金情報の分析を行う際に、ラベルを活用できます。 参考 : Cloud Billing データのエクスポート クエリの例 - ラベルを使用したクエリの例 なお2022年10月のアップデートにより、タグの情報も BigQuery エクスポートに含まれるようになりました。ただし、リソースレベルで反映されるのは Compute Engine VM、AlloyDB クラスタ、Cloud Run サービスなど、サポートされているリソースの課金のみです。またタグを付与したり、削除したりしてから BigQuery エクスポートに反映されるまで、最大1時間程度かかります。 参考 : 標準データのエクスポートの構造 - タグについて タグの使い方 タグキー・バリューの作成 基本的なタグの使い方をご紹介します。 タグを使うにはまず、タグキーとタグバリューを、 組織 または プロジェクト で予め作成しておく必要があります。 タグを作成するには、組織またはプロジェクトレベルで、タグ管理者（ roles/resourcemanager.tagAdmin ）ロールが必要です。 コンソールの場合 まずは、Google Cloud コンソールの左上にあるプロジェクトセレクタで、タグを作成したい組織またはプロジェクトを選択してください。 その後、 Google Cloud コンソール ＞ IAM と管理 ＞ タグ から + 作成 を押下することで、キー・バリューを定義できます。定義すると、キーとバリューにはそれぞれ一意となる ID が払い出されます。 タグキー・バリュー作成画面 コマンドラインの場合 gcloud コマンドラインでは、 gcloud resource-manager tags keys create と gcloud resource-manager tags values create を用います。 キーを作成する際、 parent には、タグを作成する組織またはプロジェクトを指定します。組織の場合、 organizations/${組織 ID} のような形式にします。 gcloud resource-manager tags keys create test-tag-key \ --parent = organizations/ 1234567890 \ --description =" This is my description " バリューを作成する際、 parent には、 tagKes/ で始まる先ほど作成したキーの ID を指定します。 gcloud resource-manager tags values create test-value1 \ --parent = tagKeys/ 123456789012 \ --description =" This is for test. " 参考 : gcloud resource-manager tags keys create 参考 : gcloud resource-manager tags values create リソースへの紐づけ フォルダ・プロジェクト タグをフォルダやプロジェクトに紐づけるには、 Google Cloud コンソール ＞ Manage Resources（リソースの管理） でリソースツリーを表示させます。 コンソールの場合 Google Cloud コンソールの「リソースの管理」画面へ遷移します。対象のフォルダやプロジェクトを選択して画面上部に表示される「タグ」ボタンを押下します。付与するタグキー・バリューを追加して、保存します。 対象リソース選択 タグ付与画面 コマンドラインの場合 タグとリソースを紐づけるには、 gcloud resource-manager tags bindings create コマンドラインも使用できます。このコマンドラインを見ると、タグのバインディング（紐づけ）自体も Resource Manager API のリソースであるということが分かります。 紐づける対象リソースは parent に指定します。このとき、対象リソースは 完全なリソース名 で指定します。 gcloud resource-manager tags bindings create \ --tag-value = tagValues/ 123456789012 \ --parent = //cloudresourcemanager.googleapis.com/projects/my-project 参考 : gcloud resource-manager tags bindings create 参考 : 完全なリソース名 個別リソース また、プロジェクト配下の個別のリソースにも、対応しているサービスであればタグを付与できます。例として、Compute Engine VM は、コンソールでのタグ紐づけできるほか、コマンドラインでも可能です。 参考 : タグをサポートするサービス コンソールの場合 インスタンスへのタグ紐づけ画面 コマンドラインの場合 基本はプロジェクトのときと同様ですが、インスタンスはゾーン（ロケーション）の概念があるリソースのため、ロケーションを明示的に指定します。 gcloud resource-manager tags bindings create \ --tag-value = tagValues/ 123456789012 \ --parent = //compute.googleapis.com/projects/my-project/zones/asia-northeast1-c/instances/my-instance \ --location = asia-northeast1-c プロジェクトセレクターに環境名を表示 プロジェクトや、その上位層のフォルダや組織に特定のタグキーと値を紐づけることで、Google Cloud コンソールのプロジェクトセレクターに環境名を表示させることができます。 これは、環境の取り違えなどの抑止に役立ちます。 プロジェクトセレクターに環境名を表示 まず environment という名称のタグキーを作ります。そのキーに dev という値をつけてプロジェクトに紐づけると、上記のスクリーンショットのように Dev と表示されます。他にも、以下の表のとおりの値を付与することで、プロジェクトセレクターに環境名が表示されます。 表示 タグ値 Prod Prod, prod, Production, production Dev Dev, dev, Development, development Test Test, test, Testing, testing, QA, qa, Quality assurance, quality assurance Staging Staging, staging, Stage, stage 組織やフォルダに environment タグを紐づけることで、下位のすべてのプロジェクトに継承させることもできます。 参考 : Create projects - Designate project environments with tags トラブルシュート タグの紐づけを行おうとした際に、以下のようなメッセージが出る場合があります。 ERROR: (gcloud.resource-manager.tags.bindings.create) PERMISSION_DENIED: The caller does not have permission このエラーメッセージは、IAM 権限が不足していることを意味します。タグ作成時に必要なタグ管理者（ roles/resourcemanager.tagAdmin ）ロールは、紐づけを行う権限を持っていません。紐づけを行う（バインディングを作成する）には、タグユーザー（ roles/resourcemanager.tagUser ）ロールが必要です。 タグ紐づけの作成には resourcemanager.tagValueBindings.create 権限が必要なほか、Compute Engine VM に対しては、 compute.instances.createTagBinding のように、各 API リソースごとにタグバインディングを作成するための権限が必要です。タグユーザー（ roles/resourcemanager.tagUser ）ロールには、多くのリソースに対する *.createTagBinding が含まれています。 参考 : IAM basic and predefined roles reference - Tag User (roles/resourcemanager.tagUser) ラベルの使い方 ラベルの付与 ラベルは、事前定義が必要ありません。 付与の方法はリソースごとに異なります。例として Compute Engine VM の場合、新規 VM 作成時に付与したり、VM の編集により付与できます。 コンソールの場合 ラベルの付与画面 コマンドラインの場合 VM へのラベル付与の場合は、 gcloud compute instances add-labels を使います。コマンドラインを見て分かるように、ラベルそれ自体はリソースではありません。ラベルは VM リソースに付与するメタデータですので、ラベルの付与は、リソースに対する編集操作になります。 gcloud compute instances add-labels my-instance \ --zone = asia-northeast1-c \ --labels = my-test-label = value-01 参考 : gcloud compute instances add-labels そのため、ラベルの付与に必要な IAM ロールは、Compute 管理者（ roles/compute.admin ）等、VM を編集できる IAM ロールです。 ラベルによるフィルタ Compute Engine を例に取ると、特定の値のラベルがついた VM のみをフィルタする、といった使い方ができます。 コンソール画面であれば、VM 一覧画面のテキストボックスに条件を指定できます。 コンソール画面でのフィルタ コマンドラインであれば、フィルタ条件を --filter オプションで指定します。 gcloud compute instances list --filter =" labels.my-test-label:value-01 " 参考 : gcloud topic filters 杉村 勇馬 (記事一覧) 執行役員 CTO 元警察官という経歴を持つ IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 認定資格および Google Cloud 認定資格はすべて取得。X（旧 Twitter）では Google Cloud や Google Workspace のアップデート情報をつぶやいています。 Follow @y_sugi_it

G-genの大津です。本記事では Google Cloud (旧称 GCP) における Cloud Interconnect の特徴やメリット、接続方法についてご紹介します。 Cloud Interconnect とは Cloud Interconnect を使うメリット 公共のインターネットを通過しない 接続帯域を柔軟に調整できる 下り（外向き）料金が割安 Dedicated Interconnect Dedicated Interconnect とは 4つの料金軸 Partner Interconnect Partner Interconnect とは ユースケース レイヤ２接続とレイヤ３接続 3つの料金軸 接続手順（Partner Interconnect） VLAN アタッチメントと Cloud Router の作成 サービスプロバイダからのリクエストを承諾 接続を有効にする BGP セッションの構成 Partner Interconnect の接続が確立する Cloud Interconnect のトラブルシューティング Cloud Interconnect とは Cloud Interconnect とは、自社の拠点やデータセンターなどのオンプレミスネットワークと、Google Cloud の Virtual Private Cloud（VPC）ネットワークを、 専用線もしくは閉域網で接続するサービス です。 参考 : Cloud Interconnect の概要 自社拠点等から Google Cloud 環境にプライベート IP アドレスで接続するには、IPsec プロトコルでの VPN を実現する Cloud VPN か、当記事で紹介する Cloud Interconnect のいずれかを選択することになります。Cloud Interconnect は、公衆インターネットを利用する Cloud VPN よりも、低レイテンシであったり、帯域が安定する可能性があります。 Cloud VPN については以下の記事をご参照ください。 blog.g-gen.co.jp Cloud Interconnect には、 Dedicated Interconnect と Partner Interconnect の2種類の接続方法があります。 参考 : 主な用語 - Cloud Interconnect の要素 Cloud Interconnect を使うメリット 公共のインターネットを通過しない Cloud Interconnect は公共のインターネットを経由せずに、オンプレミスネットワークと VPC ネットワークを接続できます。 Cloud Interconnect を用いると、トラフィックは専用線または閉域網ネットワークを持つネットワークサービスプロバイダを通過します。そのため、公共のインターネットの輻輳の影響を受けることなく、安定した通信を実現できます。 接続帯域を柔軟に調整できる Cloud Interconnect では、接続帯域を必要とするサービスの要件に応じて柔軟に選ぶことができます。 Dedicated Interconnect の場合、1回線あたり 10 Gbps または100 Gbps のイーサネット接続 Partner Interconnect の場合、VLANアタッチメントあたり 50 Mbps～50 Gbps の範囲で設定可能。ただしサービスプロバイダから提供されるサービスによっては使用できない帯域がある。 下り（外向き）料金が割安 Cloud Interconnect を介した VPC ネットワークからの下り（Google Cloudから見て外向き）トラフィック料金は、インターネットを経由した VPC ネットワーク下り料金と比べて、割安になっています。 Dedicated Interconnect の場合、アジア地域で $0.042/GB Partner Interconnect の場合、アジア地域で $0.042/GB 通常のVirtual Private Cloud（VPC）からの下り料金は、アジア地域で $0.12/GB Dedicated Interconnect Dedicated Interconnect とは Dedicated Interconnect は、オンプレミスネットワークと VPC ネットワーク間を、 専用線で直接接続 します。 Google が指定するコロケーション施設に設置するお客様ルータと、Google ピアリングエッジを 光ファイバーケーブルで接続する構成 です。 参考 : Dedicated Interconnect の概要 10 Gbps 以上の帯域が必要なデータ転送を利用するようなユースケースに適しており、公共のインターネット上でのデータ転送するよりもコスト効率面で優れています。 コロケーション施設には、以下の技術要件を満たしているルータを設置する必要があります。 10 Gbps 回線、シングルモード ファイバー、10GBASE-LR（1310 nm）、100 Gbps 回線、シングルモード ファイバー、100GBASE-LR4 IPv4 リンクのローカル アドレス指定 LACP（単一回線を使用している場合も必要） EBGP-4 マルチホップ 802.1Q VLAN 4つの料金軸 Dedicated Interconnect を利用する場合、以下の1～４の料金が必要となります。接続するロケーションや利用帯域などにより、料金は異なります。 Dedicated Interconnect の利用料 VLAN アタッチメントの料金 相互接続を介した VPC ネットワークからの下り（外向き）トラフィック 接続するデータセンターの構内配線の料金 1～3の料金について、各リソース（Interconnect 接続または VLAN アタッチメント）の時間単位の料金は、リソースを所有するプロジェクトに課金されます。4はユーザーが契約するコロケーション施設から請求されます。 参考 : Cloud Interconnect の料金 - Dedicated Interconnect Partner Interconnect Partner Interconnect とは Partner Interconnect は、 サービスプロバイダーのネットワークを利用 して、オンプレミスネットワークと Google Cloud の Virtual Private Cloud（VPC）を接続するサービスです。 参考 : Partner Interconnect の概要 日本では、アット東京、Equinix、インターネット イニシアティブ（IIJ）など、多くのネットワークプロバイダーが Partner Interconnect に対応しています。 参考 : サポートされているサービス プロバイダ ユースケース すでに利用中にサービス プロバイダーの追加契約で対応可能な場合 Google が指定するコロケーション施設にルータを用意できない 常時 10 Gbps の広帯域での直接接続する必要がない レイヤ２接続とレイヤ３接続 Partner Interconnect には、レイヤ2接続とレイヤ3接続が選択できます。ネットワークサービスプロバイダーによって、サポートしている接続方法が異なります。 2つの接続方法の違いは、Google Cloud の Cloud Router の対向ルーターとなる、BGP ピアの接続先です。 レイヤ2接続：お客様のオンプレミス拠点のルーター レイヤ3接続：ネットワークサービスプロバイダーのルーター 3つの料金軸 Partner Interconnect では、以下の1～3の料金が発生します。 VLAN アタッチメントの料金 相互接続を介した VPC ネットワークからの下り（外向き）トラフィック サービスプロバイダーの接続料金 1、2の料金について、各リソース（Interconnect 接続または VLAN アタッチメント）の時間単位の料金は、リソースを所有するプロジェクトに課金されます。3はユーザーが契約するサービスプロバイダーから請求されます。 この他に必要となる費用として、契約したサービスプロバイダーの閉域網サービスや、専用線サービス等の料金が必要となる場合があります。 参考 : Cloud Interconnect の料金 - Partner Interconnect 接続手順（Partner Interconnect） 利用頻度の高い Partner Interconnect を利用して、ユーザーのオンプレミスネットワークと、Google Cloud の VPC ネットワークを接続する手順を紹介します。 VLAN アタッチメントと Cloud Router の作成 Google Cloud メニューの「相互接続」＞「相互接続」から、 VLAN アタッチメントを作成します。 はじめに、「Dedicated Interconnect」か「Partner Interconnect 」の選択を行います。 VLAN アタッチメントの作成時に Cloud Router を作成することもできますし、作成済みの Cloud Router を利用することもできます。 正しく VLANアタッチメントと Cloud Router が作成されると、Google Cloud から ペアリングキー が生成されます。 ペアリングキーは、サービス プロバイダが Virtual Private Cloud（VPC）と関連する Cloud Router を識別して接続できるようにするための一意のキーです。 サービスプロバイダは、VLAN アタッチメントの構成を完了するために、このペアリングキーが必要になります。 サービスプロバイダからのリクエストを承諾 サービスプロバイダにペアリングキーの情報を送信し、サービスプロバイダが接続を構成するまで待機します。 この時、Google Cloud 上のステータスは「サービス プロバイダーを待機しています」と表示されています。 サービスプロバイダは、ペアリングキーからサービスプロバイダー側の VLAN アタッチメントを作成します。その後、サービスプロバイダは、Google Cloud へ接続のリクエストを行います。 Google Cloud の Web コンソールにて、サービスプロバイダのリクエストを承諾します。 接続を有効にする サービス プロバイダのリクエストを承諾した後は、VLAN アタッチメントを有効にする必要があります。 VLAN アタッチメントを有効にしてサービス プロバイダとの接続が確立されていることを確認します。この時、Google Cloud 上のステータスは「有効化する必要があります」と表示されています。 BGP セッションの構成 レイヤ2接続の場合、Cloud Router と拠点のルーターとの間で、BGP セッションを確立する必要があります。 Google Cloud コンソールの VLAN ID と BGP ピア IP アドレスを使用して、ルーターを構成します。 レイヤ3接続の場合、この構成は自動化されているので、Google Cloud のWeb コンソールから「BGP を構成する」をクリックします。 この時、Google Cloud 上のステータスは「BGP 構成が必要です」と表示されています。 Partner Interconnect の接続が確立する 以上の手順にて、オンプレミスネットワークと Google Cloud の VPC ネットワーク間が接続されました。 正しく構築が完了すると、Google Cloud 上のステータスは「稼働中」と表示されています。 Cloud Interconnect のトラブルシューティング Cloud Interconnect で発生する可能性がある一般的な問題については、以下の公式ドキュメントを参照してください。 参考 : トラブルシューティング 大津 和幸 (記事一覧) クラウドソリューション部 2022年4月にG-gen にジョイン。 前職まではAWSをはじめインフラ領域全般のなんでも屋。二刀流クラウドエンジニアを目指して、AWSのスキルをGoogle Cloudにマイグレーション中の日々。

G-gen の佐々木です。当記事では、Google Cloud (旧称 GCP) のサーバーレスコンテナサービスである Cloud Run から、マネージドなリレーショナルデータベースサービスの Cloud SQL に安全に接続する方法を紹介します。 使用するサービス Cloud Run Cloud SQL Cloud Run から Cloud SQL に接続する方法 サーバーレス VPC アクセスコネクタ の使用 Cloud SQL Auth Proxy の使用 Cloud SQL の作成と設定 Cloud SQL インスタンスを作成する データベースを作成する ユーザーを作成する Cloud SQL に接続する Cloud Run サービスを作成 Cloud Run サービスに紐付けるサービスアカウントを作成する サンプルアプリケーションを Cloud Run にデプロイする サンプルアプリケーションの Git リポジトリを使用する サンプルアプリのコンテナイメージをビルドする Cloud Run サービスをデプロイする 各種設定値を入力する Cloud SQL の接続情報を環境変数に設定する 接続する Cloud SQL インスタンスを設定する サービスアカウントを設定する サンプルアプリケーションの動作確認 使用するサービス Cloud Run Cloud Run はサーバーレスな環境でコンテナを実行できるサービスです。 詳細については以下の記事で解説していますので、ご一読ください。 blog.g-gen.co.jp Cloud SQL 今回は PostgreSQL データベース のマネージドサービスである Cloud SQL for PostgreSQL を使用します。 Cloud SQL の詳細については以下の記事で解説しています。 blog.g-gen.co.jp Cloud Run から Cloud SQL に接続する方法 Cloud Run でリレーショナルデータベースを使用したい場合、最初に検討することになるのが Cloud SQL です。 Cloud SQL のインスタンスは Google Cloud のマネージド VPC ( サービスプロデューサーネットワーク ) に配置され、Cloud Run から接続する場合は、以下に示す 2 種類の方法のいずれかを使用します。 サーバーレス VPC アクセスコネクタ の使用 プライベート IP を使用して Cloud SQL に接続したい場合、 サーバーレス VPC アクセスコネクタ を使用します。 自身のプロジェクト内にある VPC と Cloud SQL インスタンスが存在するサービスプロデューサーネットワークを プライベートサービスアクセス を使用してピアリング接続し、VPC 内に作成したコネクタを使用して Cloud SQL に接続するように Cloud Run を構成します。 サーバーレス VPC アクセスコネクタを使用した接続 Cloud SQL Auth Proxy の使用 Cloud SQL Auth Proxy というプロキシソフトウェアを使用することで、Cloud SQL インスタンスのパブリック IP を使用しつつ、TLS 暗号化による安全な接続を実現できます。 また、Cloud SQL Auth Proxy を使用した場合、データベースの接続元を IAM で制御することができるため、 Cloud SQL Auth Proxy を使用し、かつ Cloud SQL インスタンスにアクセスする IAM 権限を持っているクライアントに接続元を制限することができます。 Cloud Run では、パブリック IP を使用する Cloud SQL インスタンスに接続する場合、あらかじめ Cloud Run 実行環境にある Cloud SQL Auth Proxy を使用するように構成することができ、UNIX ドメインソケットを使用して高速な通信を行うことができます。 なお、Cloud SQL にパブリック IP を使用したくない場合は、先述のサーバーレス VPC アクセスコネクタと Cloud SQL Auth Proxy を併用することで、プライベート IP を使用したプロキシ経由の接続も可能となっています。 当記事では、パブリック IP アドレスを使用する Cloud SQL に対して、Cloud SQL Auth Proxy 経由の接続を実際に試してみます。 Cloud SQL Auth Proxy を使用した接続 Cloud SQL の作成と設定 Cloud SQL インスタンスを作成する 当記事では PosgreSQL の Cloud SQL インスタンスを使用します。 任意の インスタンス ID 、パスワード、リージョン等を設定し、 パブリック IP を有効化 して作成します。 パブリック IP を有効にして Cloud SQL インスタンスを作成する デフォルトのマシンタイプは 4 vCPU 、メモリ 26 GB となっており、検証目的の場合は少々高めの課金がされてしまうため、必要に応じて調整すると良いでしょう。 データベースを作成する インスタンスが作成されたら、 データベース タブからデータベースを作成していきます。 ここで設定したデータベース名は、後ほど Cloud Run の環境変数に設定します。 データベースの作成① データベースの作成② ユーザーを作成する ユーザー タブからデータベースのユーザーアカウントを作成します。 ここで設定したユーザー名、パスワードも、後ほど Cloud Run の環境変数に設定します。 ユーザーアカウントを追加① ユーザーアカウントを追加② Cloud SQL に接続する Cloud Run サービスを作成 Cloud Run サービスに紐付けるサービスアカウントを作成する Cloud Run から Cloud SQL にアクセスできる権限を持ったサービスアカウントを作成します。 サービスアカウントには以下のロールを付与します。 Cloud SQL クライアント ( Cloud SQL Client ) Cloud Run 用サービスアカウントの作成 サンプルアプリケーションを Cloud Run にデプロイする サンプルアプリケーションの Git リポジトリを使用する Google Cloud によって、Cloud SQL Auth Proxy を使用するように構成された Cloud Run のサンプルアプリケーションが提供されています。 当記事では Python のサンプルアプリケーションを使用します（ GitHub リポジトリ ）。 $ git clone git@github.com:GoogleCloudPlatform/python-docs-samples.git サンプルアプリのコンテナイメージをビルドする python-docs-samples/cloud-sql/postgres/sqlalchemy/ に、Dockerfile を含む、サンプルアプリケーションの各種ファイルが配置されているので、当該ディレクトリに移動します。 $ cd python-docs-samples/cloud-sql/postgres/sqlalchemy/ Cloud Build を使用して、Dockerfile を元に Docker コンテナのイメージをビルドします。 $ gcloud builds submit --tag gcr.io/{コンテナイメージ作成先のプロジェクトID}/{任意の名前} ビルドしたコンテナイメージは、指定したプロジェクトの Container Registry に格納されます。 ビルドしたコンテナイメージ Cloud Run サービスをデプロイする 各種設定値を入力する ビルドしたコンテナイメージから Cloud Run サービスをデプロイしていきます。 コンテナイメージを Cloud Run にデプロイ ビルドしたコンテナイメージが入力されていることを確認し、任意のサービス名とリージョンを設定します。 Cloud Run サービスの作成① 今回は Cloud Run サービスに対するアクセス制御はしないので、 すべてのトラフィックを許可する と 未認証の呼び出しを許可 にチェックを入れます。 Cloud Run サービスの作成② Cloud SQL の接続情報を環境変数に設定する Cloud SQL に接続するための情報を Cloud Run の環境変数として設定します。 サンプルアプリケーションでは、UNIX ソケットを使用する場合、以下のモジュールを使用して接続が行われます。 connect_unix.py （以下抜粋） def connect_unix_socket () -> sqlalchemy.engine.base.Engine: # Note: Saving credentials in environment variables is convenient, but not # secure - consider a more secure solution such as # Cloud Secret Manager (https://cloud.google.com/secret-manager) to help # keep secrets safe. db_user = os.environ[ "DB_USER" ] # e.g. 'my-database-user' db_pass = os.environ[ "DB_PASS" ] # e.g. 'my-database-password' db_name = os.environ[ "DB_NAME" ] # e.g. 'my-database' unix_socket_path = os.environ[ "INSTANCE_UNIX_SOCKET" ] # e.g. '/cloudsql/project:region:instance' pool = sqlalchemy.create_engine( # Equivalent URL: # postgresql+pg8000://<db_user>:<db_pass>@/<db_name> # ?unix_sock=<INSTANCE_UNIX_SOCKET>/.s.PGSQL.5432 # Note: Some drivers require the `unix_sock` query parameter to use a different key. # For example, 'psycopg2' uses the path set to `host` in order to connect successfully. sqlalchemy.engine.url.URL.create( drivername= "postgresql+pg8000" , username=db_user, password=db_pass, database=db_name, query={ "unix_sock" : "{}/.s.PGSQL.5432" .format(unix_socket_path)}, ), # [START_EXCLUDE] # Pool size is the maximum number of permanent connections to keep. pool_size= 5 , # Temporarily exceeds the set pool_size if no connections are available. max_overflow= 2 , # The total number of concurrent connections for your application will be # a total of pool_size and max_overflow. # 'pool_timeout' is the maximum number of seconds to wait when retrieving a # new connection from the pool. After the specified amount of time, an # exception will be thrown. pool_timeout= 30 , # 30 seconds # 'pool_recycle' is the maximum number of seconds a connection can persist. # Connections that live longer than the specified amount of time will be # re-established pool_recycle= 1800 , # 30 minutes # [END_EXCLUDE] ) return pool コンテナ、接続、セキュリティ 項目の コンテナ タブから環境変数を設定することができるので、以下の環境変数に対応する値を Cloud Run サービスに設定していきます。 環境変数名 設定値 INSTANCE_UNIX_SOCKET 作成した Cloud SQL インスタンスの情報を元に、以下の値を設定 /cloudsql/{プロジェクト名}:{リージョン}:{インスタンスの名前} INSTANCE_CONNECTION_NAME Cloud SQL の インスタンス接続名 Google Cloud コンソールの Cloud SQL インスタンス一覧画面から確認可能 DB_NAME Cloud SQL インスタンスに作成したデータベースの名前 DB_USER 作成したデータベースユーザーの名前 DB_PASS 作成したデータベースユーザーのパスワード Cloud SQL のインスタンス接続名 Cloud Run サービスの環境変数を設定 コード内コメントに記載がある通り、データベースの接続情報をよりセキュアに Cloud Run に渡したい場合は、 Secret Manager を使用することもできます。 接続する Cloud SQL インスタンスを設定する コンテナ、接続、セキュリティ 項目の 接続 タブを開き、 Cloud SQL 接続 で環境変数に設定したものと同じ インスタンス接続名 を選択します。 これにより、Cloud Run サービスで Cloud SQL Auth Proxy が有効化され、プロキシを用いたデータベース接続が可能になります。 接続する Cloud SQL インスタンスを設定 サービスアカウントを設定する コンテナ、接続、セキュリティ 項目の セキュリティ タブで Cloud SQL インスタンスへの接続を許可したサービスアカウントを設定します。 サービスアカウントを設定 ここまで設定したら 作成 を押下して Cloud Run サービスを作成します。 サンプルアプリケーションの動作確認 ブラウザから Cloud Run サービスの URL にアクセスし、サンプルアプリケーションを動かしてみます。 ブラウザからサンプルアプリケーションにアクセス 当記事で使用するサンプルアプリケーションでは、 TAB と SPACE のどちらかに投票することで、投票結果がデータベースに記録されるようになっています。 サンプルアプリケーションの画面 投票ボタンを何度か押下します。 投票するたびに数字が加算される データベースに投票結果が保持されているか確認するため、Cloud Run サービスのコンテナがすべて破棄されるのを待ってから、もう一度 URL にアクセスします。 サービスの詳細 の 指標 タブから コンテナ インスタンス数 を確認できます。 active と idle の値が 0 になるまで少し待ちます。 コンテナ インスタンス数が 0 になったことを確認 2 つの値が 0 になったら、もう一度サービスの URL にアクセスします。 このとき、先程とは別のコンテナが起動されますが、投票結果はデータベース側で保持されているため、投票後と同じ投票数が画面に表示されます。 佐々木 駿太 (記事一覧) G-gen最北端、北海道在住のクラウドソリューション部エンジニア 2022年6月にG-genにジョイン。Google Cloud Partner Top Engineer 2025 Fellowに選出。好きなGoogle CloudプロダクトはCloud Run。 趣味はコーヒー、小説（SF、ミステリ）、カラオケなど。 Follow @sasashun0805

G-gen の杉村です。Infrastructure as Code (IaC) を実現する Terraform を Google Cloud (旧称 GCP) で使ってみました。 Terraform とは 使ってみる Cloud Shell Terraform コマンドの確認 ファイル作成 エディタでの編集 Terraform 初期化 確認コマンド 適用 環境の削除 Cloud Storage に状態 (state) を保存する 前提知識 状態 (state) とは 状態 (state) の共有 バケットの作成 バックエンド構成の作成 再 init 応用 Terraform とは Terraform は Infrastructure as Code (IaC) を実現するオープンソース (Mozilla Public License v2.0) のツールです。 Google Cloud (旧称 GCP) のほか Amazon Web Services (AWS) や Microsoft Azure にも対応しており、 IaC ツールとして根強い人気を誇ります。 Terraform では独自フォーマットの設定ファイルでリソースを記述し、コマンドラインツールで操作します。また状態 (state) がファイルとして保存され、実環境と設定ファイルの差分が把握されます。 設定ファイルでクラウドインフラを管理できるため、 IT インフラのバージョン管理や CI/CD (継続的インテグレーション / 継続的デリバリ) を可能にします。 Google Cloud では公式の IaC ツールとして Cloud Deployment Manager が存在しているものの、事実上 Terraform が Google Cloud の IaC ツールとして定着しています。 使ってみる Cloud Shell Google Cloud の Web コンソールには Cloud Shell が備わっており、ローカル PC にツールをインストールしたり作業用の VM を起動しなくてもブラウザ上で Linux ベースの作業スペースを使うことができます。 Google Cloud コンソール にログインし、右上の四角いアイコンをクリックします (マウスオーバーすると Cloud Shell をアクティブにする と表示されます) 。 Cloud Shell を起動 始めて起動する場合は 1 分程度待つ必要があるかもしれませんが、2回目以降は数秒程度になります。しばらくすると黒いターミナル画面が出てきます。 以下スクリーンショットの赤枠部分をドラッグして上下に動かすと、ターミナル画面のサイズを変えることができます。 ターミナル画面 Terraform コマンドの確認 実は Cloud Shell にはデフォルトで Terraform がインストール済みです。 terraform --version と入力してエンターを押してみてください。 $ terraform --version Terraform v1. 2 . 8 on linux_amd64 Your version of Terraform is out of date! The latest version is 1 . 2 . 9 . You can update by downloading from https://www.terraform.io/downloads.html もしローカル PC に Terraform をインストールしたい場合、 公式サイト 等をご参照ください。 ファイル作成 フォルダを作ってその中に Terraform 設定ファイルを作成します。 ここでは Cloud Storage バケットを定義するための storage.tf というファイルを作成します。ファイル名は任意です。 mkdir terraform-demo cd terraform-demo touch storage.tf エディタでの編集 なんと Cloud Shell には ブラウザ上で動作するコードエディタまで付属しています。エディタを開くため、以下スクリーンショットの エディタを開く ボタンを押下します。 エディタを開く 左側のファイルエクスプローラから先程の storage.tf を選択し、編集します。 エディタ画面 以下の設定内容を貼り付けて、保存 ( File メニューから Save もしくは Ctrl + S 押下) します。 <任意のリソース名> は任意の名称に置き換えてください。これは Terraform 内でリソースを一意に特定するための識別子です。その左側にある "google_storage_bucket" はこのリソースの種類を表します。 また <バケット名> を世界で一意になるように置き換えてください。これが Cloud Storage バケット名となります。 resource "google_storage_bucket" "<任意のリソース名>" { name = "<バケット名>" location = "asia-northeast1" force_destroy = true uniform_bucket_level_access = true lifecycle_rule { condition { age = 5 } action { type = "Delete" } } } 上記は以下のような Cloud Storage バケットを定義する設定です。 設定名 値 バケット名 <バケット名> ロケーション asia-northeast1 (東京) force_destroy 有効 (バケット削除時にオブジェクトが残っていたら中身を全て削除してからバケット削除) 均一なアクセス制御 有効 ライフサイクル 5 日で削除 リソースタイプごとにパラメータの設定方法が定義されており Terraform の公式リファレンスから確認可能です。 参考 : google_storage_bucket Terraform 初期化 次に、コマンドを実行して Terraform の初期化を行います。エディタの編集部分下部に白いターミナルが表示されていますので、そこからコマンドを実行するか、エディタ上部の ターミナルを開く ボタンを押して先程の黒いターミナルに戻ることもできます。 terraform init コマンドを実行してください。 Terraform has been successfully initialized! と表示されたら成功です。 terraform init の実行 このコマンドを実行すると、カレントディレクトリの配下にある *.tf が自動的に読み込まれ、必要なファイルがセットアップされます。 今回はリソースタイプが google_storage_bucket のリソースが定義されているので、自動的に Google 用の プロバイダ がダウンロードされてセットアップされます。プロバイダとは Terraform 本体とは別個のバイナリであり AWS や Google Cloud など対応するプラットフォームごとに存在しています。 ls -la コマンドを実行すると、以下のように . から始まる隠しファイルが生成されていることが分かります。 $ ls -la total 20 drwxr-xr-x 3 sugimura sugimura 4096 Sep 19 02:04 . drwxr-xr-x 27 sugimura 1001 4096 Sep 19 01:19 .. -rw-r--r-- 1 sugimura sugimura 294 Sep 19 01:02 storage.tf drwxr-xr-x 3 sugimura sugimura 4096 Sep 19 02:04 .terraform -rw-r--r-- 1 sugimura sugimura 1155 Sep 19 02:04 .terraform.lock.hcl 確認コマンド 次は terraform plan コマンドを実行します。カレントディレクトリにある *.tf 設定ファイルが環境にどのような影響を及ぼすかを事前に確かめるためのコマンドです。 $ terraform plan Terraform used the selected providers to generate the following execution plan. Resource actions are indicated with the following symbols: + create Terraform will perform the following actions: # google_storage_bucket.ggen-test-storage will be created + resource " google_storage_bucket " " ggen-test-storage " { + force_destroy = true + id = ( known after apply ) + location = " ASIA-NORTHEAST1 " + name = " ggen-test-storage " + project = ( known after apply ) + self_link = ( known after apply ) + storage_class = " STANDARD " + uniform_bucket_level_access = true + url = ( known after apply ) + lifecycle_rule { + action { + type = " Delete " } + condition { + age = 5 + matches_prefix = [] + matches_storage_class = [] + matches_suffix = [] + with_state = ( known after apply ) } } } Plan: 1 to add, 0 to change, 0 to destroy. ────────────────────────────────────────────────────────────────────────────────────────── Note: You didn ' t use the -out option to save this plan, so Terraform can ' t guarantee to take exactly these actions if you run " terraform apply " now. Plan: 1 to add, 0 to change, 0 to destroy. は環境に新しいリソースが作成されることを意味しています。 実際にリソースを作成したり更新する前に毎回 terraform plan を実行することで、意図しない変更に事前に気がつくことができます。 適用 実際にリソースを作成するため terraform apply を実行します。 実行すると plan を実行したときと同じような環境差分の表示に加えて以下のプロンプトが表示されます。 Do you want to perform these actions? Terraform will perform the actions described above. Only 'yes' will be accepted to approve. Enter a value: yes を入力して Enter を押下すると、実際に環境に適用されます。 Apply complete! Resources: 1 added, 0 changed, 0 destroyed. が表示されれば成功です。 Cloud Storage のコンソール画面で、バケットが作成されたことを確認してください。ライフサイクルポリシーも設定されているはずです。 環境の削除 環境を削除する場合は terraform destroy を実行します。 先程と同じようにプロンプトが表示されますので yes を入力して Enter を押下します。これで環境が削除されます。 Cloud Storage に状態 (state) を保存する 前提知識 状態 (state) とは Terraform の 状態 (state) とは Terraform が把握している実環境の現在の状態です。 Terraform は state をファイルとして保持します。 「状態をファイルとして保持せず、常に実環境を見てくれればいいのに。そうしないとファイルと実環境の差異が生まれてしまうのでは」と考える人もいるかもしれません。しかし「複数リソースの依存関係を保持する」「設定ファイルと実リソースのマッピングを保持する」「毎回実環境を精査すると多数の API コールが走りリソースが多い場合に処理が重すぎる」などの理由で Terraform は state をファイルとして保持しています ( 参考 ) 。 state は tfstate ファイル として保管され、先程の手順で実行するとファイルはローカル (Cloud Shell) に保存されます。もしローカル PC で Terraform を実行したら、ローカル PC に保管されます。 状態 (state) の共有 しかし、これでは複数人で Terraform 設定ファイルを管理する場合に問題が生じます。 誰かのローカルの tfstate ファイルが保存されていたのでは、この人が毎回 terraform plan terraform apply する必要が出てきます。これではチーム開発や CI/CD は実現できません。 これを解決するため tfstate ファイルをリモート管理することができます。 Google Cloud では Cloud Storage バケット に tfstate ファイルを保管し、これを共有することができます。 実際にやってみます。 バケットの作成 tfstate ファイルを保存するためのバケットを手動で作成しておきます。 このバケットを Terraform で作成しても構いません。しかし「 Terraform の管理に使われるファイルを保管するバケットが Terraform で管理されるべきではない」という考え方もできるため、今回は手動で作成することにします。 バックエンド構成の作成 以下のようなファイルを backend.tf として新規作成し、先程作成した storage.tf と同じディレクトリに配置します。 terraform { backend "gcs" { bucket = "ggen-terraform-demo" prefix = "terraform/state" } } 再 init terraform init を実行します。 Terraform has been successfully initialized! という表示が出たら成功です。 バケットの中身を見てみると terraform/state フォルダの中に tfstate ファイルが生成されているはずです。 バケット内の tfstate ファイル これ以降は terraform plan や terraform apply を実行するたびに最新の状態がバケットから取得され、 apply により環境が更新されるとバケット上の tfstate ファイルが更新されます。 これに加えて Terraform 設定ファイルを Git 等でバージョン管理することで、複数人による開発・管理が可能になります。 応用 以下は、Google Cloud が公式に掲載している、Terraform を使用するためのベストプラクティスに関するドキュメントです。 実環境で Terraform を運用していくにあたり、役に立つベストプラクティスが記載されています。 参考 : Terraform を使用するためのベスト プラクティス 杉村 勇馬 (記事一覧) 執行役員 CTO / クラウドソリューション部 部長 元警察官という経歴を持つ現 IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 12資格、Google Cloud認定資格11資格。X (旧 Twitter) では Google Cloud や AWS のアップデート情報をつぶやいています。 Follow @y_sugi_it

今回は、Security Command Center から検出される脅威を Slack に通知したり、特定の検出機能においては自動で修復する仕組みを実装してみたいと思います。 概要 Security Command Centerとは 作成するもの 作成の手順 Pub/Sub トピックを作成 サービスアカウントの作成 Cloud Functions の作成 main.py の内容 requirements.txt の内容 ポリシーの更新手順 ポリシーの更新手順 get_iam_policy set_iam_policy 動作確認 "@gmail.com" に単一のロールを紐づけた時 "@gmail.com" に複数のロールを紐づけた時 検出機能が「NON_ORG_IAM_MEMBER」以外の時 概要 Security Command Centerとは Security Command Center とは、Google Cloud 環境の構成ミス、脆弱性、脅威を特定して、セキュリティ強化・リスク軽減をするためのサービスです。 Security Command Center については、以下の記事で詳しく解説されているため事前にご覧いただけると幸いです。 blog.g-gen.co.jp また筆者の環境は、Security Command Center の スタンダード ティア が組織と組織配下のプロジェクトですべて有効化された状態ですので、まだ有効化されていない方は事前に以下を参考にSecurity Command Center を有効化していただけますと幸いです。 https://cloud.google.com/security-command-center/docs/set-up?hl=ja 作成するもの Security Command Center から検出機能の中で、重要度が「 重大 」または「 高 」のものを対象に Slack に推奨事項（改善策）とともに検出結果を通知します。 上記は、こちらのチュートリアルを参考にしました。 cloud.google.com また、検出機能の中でも 特定の検出機能 が検出された時、 自動で修復する仕組み も実装します。 今回ピックアップした検出機能は、「 NON_ORG_IAM_MEMBER 」です。こちらは、組織内で "@gmail.com" メールアドレスのアカウントに IAM 権限が紐づけられている場合に、リアルタイムに検出されます。 「NON_ORG_IAM_MEMBER」が検出された際は、対象の "@gmail.com" のユーザーに紐づけられたロールを自動で削除して、削除結果を Slack にて報告するスクリプトを記述し、Cloud Functions で実装していきたいと思います。 作成の手順 手順としては、大きく以下の3つとなります。 Pub/Sub トピックを作成 サービスアカウントの作成 Cloud Functions を構成 Pub/Sub トピックを作成 Cloud Shell を起動して、Cloud Pub/Sub トピックを設定していきます。 上記の赤枠をクリックすると Cloud Shell が起動しますので、Cloud Shell ターミナルから以下を実行します。 # 環境変数に Google Cloud プロジェクト を指定 export PROJECT_ID =PROJECT_ID # 環境変数に Google Cloud 組織を指定 export ORG_ID =ORG_ID # gcloud コマンドにプロジェクト ID を設定 gcloud config set project PROJECT_ID # 通知をパブリッシュする Pub/Sub トピックを作成 gcloud pubsub topics create scc-critical-and-high-severity-findings-topic # 環境変数にトピックを指定 export TOPIC =projects/ $PROJECT_ID /topics/scc-critical-and-high-severity-findings-topic # メッセージがトピックにパブリッシュされたときに、 Cloud Functions に通知するサブスクリプションを作成 gcloud pubsub subscriptions create scc-critical-and-high-severity-findings-sub --topic scc-critical-and-high-severity-findings-topic # トピックに通知をパブリッシュするように、Security Command Center を構成 (フィルタ機能を用いて、重要度が「重大」と「高」のアクティブな検出結果に関する通知をパブリッシュ) gcloud scc notifications create scc-critical-and-high-severity-findings-notify --pubsub-topic $TOPIC --organization $ORG_ID --filter " (severity= \" HIGH \" OR severity= \" CRITICAL \" ) AND state= \" ACTIVE \" " サービスアカウントの作成 Cloud Functions に紐づくサービスアカウントを作成していきます。 IAM と管理 ＞ サービスアカウント へ移動 サービスアカウントを作成 をクリック 「Cloud Functions 起動元」と「Pub/Sub サブスクライバー」、「Project IAM 管理者」のロールをアタッチ 完了 をクリック Cloud Functions の作成 Cloud Functions を作成していきます。 Cloud Functions へ移動 関数の作成 をクリック トリガー に「Cloud Pub/Sub」を、トピックに先程作成した「${TOPIC}」を選択 サービスアカウント に先程作成した「${サービスアカウント}」を入力 環境変数に Slack Webhook のURLを入力 Slack Webhook URL の発行手順は こちら を参考にしました。 次へ をクリック ランタイム に Python 3.9 を選択し、エントリポイントを「send_slack_chat_notification」と入力 main.py とrerequirements.txt のファイルをそれぞれ以下のコードに書き換え、[デプロイ]をクリック main.py の内容 import base64 import json import os import slackweb from google.cloud import resourcemanager_v3 from google.iam.v1 import iam_policy_pb2 # type: ignore # 環境変数から SLACK_WEB_HOOK_URL を取得 SLACK_WEB_HOOK_URL = os.environ.get( "SLACK_WEB_HOOK_URL" ) # slack クライアントの初期化 slack = slackweb.Slack(url=SLACK_WEB_HOOK_URL) # ProjectsClient クライアントの初期化 client = resourcemanager_v3.ProjectsClient() def send_slack_chat_notification (event, context): # SCC から受け取ったデータを json 形式で展開 pubsub_message = base64.b64decode(event[ 'data' ]).decode( 'utf-8' ) message_json = json.loads(pubsub_message) finding = message_json[ 'finding' ] # カテゴリー（検出機能）とレコメンド（改善策）を取得 category = finding[ 'category' ] recommendation = finding[ 'sourceProperties' ][ 'Recommendation' ] # 検出機能が「NON_ORG_IAM_MEMBER」の時、"@gmail.com" の対象ユーザーに紐づけられているロールを削除する if category == "NON_ORG_IAM_MEMBER" : # プロジェクトIDとメンバーのメールアドレス、紐づけられたロールの情報を取得 project_id = finding[ 'sourceProperties' ][ 'ResourcePath' ][ 0 ].split( '/' )[ 1 ] member = finding[ 'sourceProperties' ][ 'OffendingIamRolesList' ][ 0 ][ 'member' ] roles = [] for i in range ( len (finding[ 'sourceProperties' ][ 'OffendingIamRolesList' ][ 0 ][ 'roles' ])): roles.append(finding[ 'sourceProperties' ][ 'OffendingIamRolesList' ][ 0 ][ 'roles' ][i]) # 対象メンバー (@gmail.com) が紐付くロールから、対象メンバーを削除する関数を実行 modify_policy_remove_member(project_id, roles, member) # 削除結果を Slack で通知 slack.notify(text=f "【セキュリテクリスク検出】 \n {category} \n 【報告】 \n project_id:{project_id} に@gmailを含むユーザーが追加されたことを検知したため、対象ユーザに付与されたロールを自動的に削除しました \n 【対象ユーザ】 \n {member} \n 【削除したロール】 \n {roles} " ) return else : # 検出機能が「NON_ORG_IAM_MEMBER」以外の時、検出機能とレコメンド（改善策）の情報を Slack で通知 slack.notify(text=f "【セキュリテクリスク検出】 \n {category} \n 【推奨事項】 \n {recommendation}" ) return def modify_policy_remove_member (project_id, roles, member): # プロジェクト内の全てのアクティブなロールを取得 iam_policy = get_iam_policy(project_id) # roles リストにある role の数だけ処理を回す for i in range ( len (roles)): # iam_policy の中のロールと、引数で受け取ったロールが同じ場合、対象の bindings を取得 bindings = next (b for b in iam_policy.bindings if b.role == roles[i]) # bindings の中に、引数で受け取ったメンバー（"@gmail.com"）が含まれる場合、取り除く if bool (bindings.members) and member in bindings.members: bindings.members.remove(member) # 上記で修正したポリシーを、プロジェクトの新ポリシーとして上書きする set_iam_policy(project_id, iam_policy) return def get_iam_policy (project_id): # 対象プロジェクト内の IAM Policy の取得 request = iam_policy_pb2.GetIamPolicyRequest( resource=f "projects/{project_id}" ) iam_policy = client.get_iam_policy(request=request) return iam_policy def set_iam_policy (project_id, iam_policy): # 対象プロジェクト内の IAM Policy を上書き request = iam_policy_pb2.SetIamPolicyRequest( resource=f "projects/{project_id}" , policy=iam_policy, ) response = client.set_iam_policy(request=request) return requirements.txt の内容 slackweb==1.0.5 requests==2.28.1 google - cloud - resource - manager==1.6.1 grpc - google - iam - v1==0.12.4 ポリシーの更新手順 "@gmail.com" の対象ユーザーに紐づけられているロールを削除する仕組みは、以下の流れで行われています。 ポリシーの更新手順 既存のポリシーの取得 （ get_iam_policy ） ポリシーの変更 （ modify_policy_remove_member ） ポリシー全体の書き込み （ set_iam_policy ） 2 ポリシーの変更時に、"@gmail.com" の対象ユーザーに紐づけられているロールを削除しています。 get_iam_policy get_iam_policy で取得できるデータは以下のような形式です。 version: 1 bindings { role: " roles/bigquery.admin " members: " user:hogehoge@gmail.com " members: " user:matayuuu@g-gen.co.jp " } bindings { role: " roles/owner " members: " user:matayuuu@g-gen.co.jp " } ・ ・ ・ etag: " \007\005\351\264\211 C \021\344 " 対象のプロジェクト内でアクティブなロールに紐づくメンバーが bindings として取得できます。 また、 etag はポリシーが更新されるたびに変更されるため、 ポリシーの書き込み時の競合防止 に使われています（ 参考 ）。 set_iam_policy get_iam_policy で取得できるデータの一部を変更して、set_iam_policy でポリシーを更新できます。 仮に、 hogehoge@gmail.com のユーザーから "roles/bigquery.admin" のロールを削除したとすると、以下のようになります。 version: 1 bindings { role: " roles/bigquery.admin " members: " user:matayuuu@g-gen.co.jp " } bindings { role: " roles/owner " members: " user:matayuuu@g-gen.co.jp " } ・ ・ ・ etag: " \007\005\351\264\211 C \021\344 " 上記の状態で、set_iam_policy をすることで、 etag の中身が get_iam_policy で取得したときと同じ であれば新しいポリシーとして上書きが 成功 します。 逆に、etag の中身が get_iam_policy で取得したときと変わっていれば、自分が get_iam_policy した後に 他の誰かがポリシーを変更して上書きしている ため更新が 失敗 となります（競合の発生）。 その場合は、再度 get_iam_policy してから、その内容に変更を加えて set_iam_policy する流れになります。 動作確認 "@gmail.com" に単一のロールを紐づけた時 IAM と管理 ＞ IAM から、"@gmail.com" ユーザーに 任意のロールを紐づけし、自動で紐づけたロールが削除されるか確認します。 保存 をクリックしたタイミングで、Slack に以下の通知が届きました。 "@gmail.com" ユーザーのロールが上手く削除できた際、削除したことを報告する内容が Slack に届きます。 念の為、 IAM と管理 ＞ IAM でも ”@gmail.com" のユーザーにロールが紐付いていないか確認しましたが、問題なく削除されておりました。 "@gmail.com" に複数のロールを紐づけた時 次に、一人のユーザーに対し、一度に複数のロールを紐づけた際の挙動も確認していきたいと思います。 先程と同様、 "@gmail.com" ユーザーに任意のロールを複数紐づけます。 保存 をクリックしたタイミングで、Slack に以下の通知が届きました。 "＠gmail.com" ユーザーからロールが削除できています。 検出機能が「NON_ORG_IAM_MEMBER」以外の時 最後に、検出機能が「NON_ORG_IAM_MEMBER」以外の時の挙動も確認します。 こちらは、 SCC ＞ 検出 から適当な検出機能を選択し、 非アクティブ にした後、再度 有効 にすることで Slack へ通知されるか確認したいと思います。 「OPEN_FIREWALL」を、一度 非アクティブ にした後、再度 有効 にしたタイミングで、Slack に以下の通知が届きました。 「NON_ORG_IAM_MEMBER」以外の時は、セキュリティリスクを検出したことを報告し、推奨事項 (改善案) を通知する文が Slack に届きます。 今回作成した自動修復の仕組みは「 NON_ORG_IAM_MEMBER 」の検出機能のみでしたが、こちらを応用すると組織としてクリティカルな脅威に対して、自動修復する 是正的な統制 も実現できそうですね。 G-gen 編集部 (記事一覧) 株式会社G-genは、サーバーワークスグループとして「クラウドで、世界を、もっと、はたらきやすく」をビジョンに掲げ、クラウドの導入から最適化までを支援している Google Cloud 専業のクラウドインテグレーターです。