Cloud Function から IAM認証で CloudSQL(PostgreSQL) へ接続する

はじめに クラウド環境でのデータベース管理において、セキュリティは日々進化する脅威への対応が求められる重要課題です。特に、以下の課題が顕在化しています: 従来の認証情報(パスワード)の漏洩リスク 認証情報のローテーション管理の煩雑さ アプリケーション展開時の認証情報受け渡しの安全性確保 これらの課題に対し、IAM認証を活用することで、より強固でかつ運用負荷の少ないセキュリティ体制を実現できます。IAM認証のメリットは以下の通りです: 一時的な認証トークンの利用による漏洩リスクの低減 クラウドプロバイダーの統合認証基盤との連携による管理の一元化 きめ細かなアクセス制御とアクセスログの監査対応 本ガイドでは、Cloud FunctionsからCloudSQL(PostgreSQL)へIAM認証で接続する実践的な手順を解説します。この設定により、セキュアかつスケーラブルなデータベースアクセス環境を構築できます。 Cloud Function から CloudSQL(PostgreSQL) へ IAM 認証で接続するために必要な手順 Cloud Function 用 Service Account に必要な権限を付与 PGUSER の作成(IAM認証用) データベースへの権限付与 Cloud Function の実装 Service Account での Cloud Function のデプロイ 具体的な設定手順 1. Cloud Function 用 Service Account に必要な権限を付与 以下の権限が必要: Cloud SQL インスタンス ユーザー Cloud SQL クライアント 今回はコンソールから設定したが、以下のコマンドで設定も可能: gcloud projects add-iam-policy-binding example-project \ --member="serviceAccount:example-function@example-project.iam.gserviceaccount.com" \ --role="roles/cloudsql.instanceUser" gcloud projects add-iam-policy-binding example-project \ --member="serviceAccount:example-function@example-project.iam.gserviceaccount.com" \ --role="roles/cloudsql.client" 2. PGUSER の作成 IAM認証用のユーザーを作成する。...

2025-01-29 ·  2025-01-30 · 3 分 · 515 文字

BigQueryテーブルへのパーティション追加

BigQueryテーブルへのパーティション追加 概要 既存の非パーティションテーブルを直接パーティションテーブルに変更することはできない 新しいパーティションテーブルを作成し、データをコピーする方法で実現可能 手順 新しいパーティションテーブルの作成とデータのコピー CREATE TABLE `project_id.dataset_id.new_partitioned_table` PARTITION BY DATE(timestamp_column) AS SELECT * FROM `project_id.dataset_id.original_table`; 元のテーブルの削除と新テーブルの名前変更 DROP TABLE `project_id.dataset_id.original_table`; ALTER TABLE `project_id.dataset_id.new_partitioned_table` RENAME TO `project_id.dataset_id.original_table`; 注意点 大量データの場合、時間とリソースを要する パーティションキーの列は適切なデータ型である必要がある テーブル設計に影響を与えるため、慎重な計画が必要 メリット クエリパフォーマンスの向上 コスト削減の可能性 その他 時系列パーティショニング以外に、整数範囲パーティショニングも利用可能 整数範囲パーティショニングを使用する場合は、CREATE TABLE文を適宜調整する

2025-01-16 ·  2025-01-30 · 1 分 · 38 文字

Terraform backend を GCS backet に設定する script 書いた

terrarorm init で バケットがなければ作成する バケット名は ${project_id}-${app}-tfstate とする project_id, app は Makefile で指定 terraform コマンドをラップした Makefile app := sample project_id := project-a export init_tfstate_gs: @init_gs_tfstate_if_needed init: init_tfstate_gs @echo "==> Initializing terraform..." @make _tf cmd=init init_if_needed: @if [[ ! -e envs/$(stage)/.terraform ]]; then \ make init; \ fi login: @make _tf cmd=login init_upgrade: @make _tf cmd=init opt="-upgrade=true" init_migrate_state: @make _tf cmd=init opt="-migrate-state" plan: init_if_needed @make _tf cmd=plan apply: init_if_needed @make _tf cmd=apply apply-auto-approve: @make _tf cmd=apply opt=-auto-approve apply-refresh: @make _tf cmd=apply opt=-refresh-only destroy: @make _tf cmd=destroy refresh: @make _tf cmd=refresh show: @make _tf cmd=show output: @make _tf cmd=output opt=-json console: @make _tf cmd=console validate: @make _tf cmd=validate _check_env: @test -e envs/$(stage) || (echo 'No such stage:envs/$(stage) exist....

2024-11-20 ·  2024-11-20 · 2 分 · 237 文字

Terraform で google_api_gateway_api_config に api_config_id を設定すると再作成時に罠がある

まとめ Terraform で google_api_gateway_api_config に api_config_id は設定しない 以下詳細 以下のように api_config_id を設定すると、再作成時にエラーが発生する resource "google_api_gateway_api_config" "default" { project = var.project_id provider = google-beta api = google_api_gateway_api.default.api_id api_config_id = "${var.env}-${var.service}-api-config" openapi_documents { document { path = "openapi.yaml" contents = base64encode(templatefile("${path.module}/openapi.yaml", { title = "${var.env} ${var.service} API" description = "This is the API for ${var.env} ${var.service}" version = "1.0.0" managed_service = google_api_gateway_api.default.managed_service func_url = google_cloud_run_service.default.status[0].url })) } } lifecycle { create_before_destroy = true } } │ Error: Error creating ApiConfig: googleapi: Error 409: Resource 'projects/{project_id}/locations/global/apis/{api_id}/configs/{api_config_name}' already exists │ Details: │ [ │ { │ "@type": "type....

2024-11-15 ·  2024-11-15 · 1 分 · 108 文字

GCP ApiGateway + CloudRun で CORS を設定する

構成 GCP ApiGateway -> CloudRun ApiGateway で OpenAPI yaml を定義している 1. OpenAPI yaml で x-google-endpoints に allowCors: True を設定して、バックエンドでCORSリクエストを処理する x-google-endpoints: - name: ${managed_service} allowCors: True # バックエンドでCORSリクエストを処理する 2. CloudRun で OPTIONS メソッドを設定する // 以下のように cors ミドルウェアを挟む http.HandleFunc("/example", cors(user.Handler)) // 定義はこんな感じ func cors(next http.HandlerFunc) http.HandlerFunc { return func(w http.ResponseWriter, r *http.Request) { if r.Method == "OPTIONS" { slog.Info("==> Reply OPTIONS Request", "status", http.StatusNoContent) w.Header().Set("Access-Control-Allow-Origin", "*") w.Header().Set("Access-Control-Allow-Methods", "GET, POST, PUT, PATCH, DELETE, OPTIONS") w....

2024-11-15 ·  2024-11-15 · 1 分 · 105 文字