■サービスアカウントの種類
サービスエージェントとは何か - G-gen Tech Blog
サービス アカウントのタイプ | IAM のドキュメント | Google Cloud
■Artifact registry
サービスエージェントとは何か - G-gen Tech Blog
サービス アカウントのタイプ | IAM のドキュメント | Google Cloud
１）ユーザー管理サービス アカウント例
service-account-name@project-id.iam.gserviceaccount.com
プロジェクト名がサブドメインについている
２）デフォルトのサービス アカウント例
project-number-compute@developer.gserviceaccount.com
３）Google マネージド サービス アカウント
３－１）サービス固有のサービス エージェント例
service-PROJECT_NUMBER@gcp-sa-artifactregistry.iam.gserviceaccount.com
３－２）Google API サービス エージェント例
project-number@cloudservices.gserviceaccount.com
３－３）Google 管理のサービス アカウントのロール マネージャー例
service-agent-manager@system.gserviceaccount.com
１は所有プロジェクト名で判断できる、それ以外はdeveloperやgcp-やcloudservicesやsystem
３－１、３－２はSAだがサービスエージェントとも言われる
Service agents | IAM Documentation | Google Cloud１は所有プロジェクト名で判断できる、それ以外はdeveloperやgcp-やcloudservicesやsystem
３－１、３－２はSAだがサービスエージェントとも言われる
■Artifact registry
Artifact registryt APIの有効化
kusoリポジトリ作成 format=docker, mode=standard, region=asia-northeast1
権限を設定（詳しくはマニュアル要確認）
標準リポジトリへの移行 | Artifact Registry のドキュメント | Google Cloud
artifact registry admin
storage.admin
ROUTEボタンのリダイレクトなら付与
権限を設定（詳しくはマニュアル要確認）
標準リポジトリへの移行 | Artifact Registry のドキュメント | Google Cloud
artifact registry admin
storage.admin
ROUTEボタンのリダイレクトなら付与
Cloud buildのサービスアカウントに付与（cloud build > setting）
操作をしようとするとエラーがでるなら下記のように付与
gcloud projects add-iam-policy-binding prj-xxx -member='serviceAccount:service-123456@gcp-sa-artifactregistry.iam.gservice.com' --role='roles/storage.objectViewer'
※事前にgcloud auth loginが必要
gcloud projects add-iam-policy-binding prj-xxx -member='serviceAccount:service-123456@gcp-sa-artifactregistry.iam.gservice.com' --role='roles/storage.objectViewer'
※事前にgcloud auth loginが必要
gcloud config configurations activate gcp-profile
gcloud auth login
gcloud auth configure-docker asia-northeast1-docker.pkg.dev
gcloud builds submit --tag asia-northeast1-docker.pkg.dev/chimpo-prj/kuso/image001
gcloud builds submit --tag LOCATION-docker.pkg.dev/PROJECT-ID/REPOSITORY/IMAGE
リポジトリ単位で権限管理ができる、リージョン選択できレイテンシー有利、CRコストはGCS計上だがAR計上で分かりやすい、新機能はARに実装される
リポジトリ名はハイフンOKだがアンスコNG、CRはイメージ名にアプリ名称を付ける感じであったがARはリポジトリ名にアプリ名称/イメージ名に版名を付ける感じに付与名が増えた
■ARホスト名(マルチリージョン)
us-docker.pkg.dev
europe-docker.pkg.dev
asia-docker.pkg.dev
■ARホスト名(リージョナル)
asia-northeast1-docker.pkg.dev
等々
Container registry は下記であった
gcloud builds submit --tag gcr.io/PROJECT-ID/IMAGE
CRで使用しているgcr.ioは元々米国のホスト、asia.gcr.io等が派生した
■CRホスト名(マルチリージョン)
gcr.io
us.gcr.io
eu.gcr.io
asia.gcr.io
※CRからARの移行でROUTEボタンで有効にすれば、CRへのコマンドはARに転送、コンテナもARにsubmitできる
※CRからARの移行でROUTEボタンで有効にすれば、CRへのコマンドはARに転送、コンテナもARにsubmitできる
※ARにコンテナを最初に置いておきたい場合は gcraneコマンドでコピーできる
↓■GCPディスク容量
コンソールからディスクに入り編集で容量追加
コンソールからディスクに入り編集で容量追加
公開イメージのブートは自動変更される
カスタムイメージや非ブートディスクは手動変更が必要
手動方法は下記参照
/// BANGBOO BLOG /// - Linux cmd
■IAM>PAM
一時付与の権限申請ができる
■ZOZOの新米Google cloud管理者
新米Google Cloud管理者の奮闘記のその後 〜Organizationの秩序を維持する試み〜 - ZOZO TECH BLOG
■データ
次世代データ基盤：データレイクハウスを Google Cloud で実現する (zenn.dev)
■GCPでsudo apt-get updateができないとき
wget https://packages.cloud.google.com/apt/doc/apt-key.gpg
apt-key add apt-key.gpg
■GCEでの通信（GCEのサービスアカウントとホスト上のOSLoginユーザの違い）
■GCEでの通信（GCEのサービスアカウントとホスト上のOSLoginユーザの違い）
Google APIはSAで行く（SAに各権限を付けておく）
ただgcloud compute start-iap-tunel はSAで行くが
サービスアカウントユーザロールで実行者とSAを紐づけて行く？
（サービスアカウントに操作するユーザのserviceAccountUserの権限が必要）
（サービスアカウントに操作するユーザのserviceAccountUserの権限が必要）
その他のhttpsアクセスやls等コマンドはホスト上の実行者で行く
■IAPトンネルで内部IPでも外部に出る設定
#権限
ユーザ利用のGCEのSAのIAPトンネル権限を踏み台IAPにつける
SAに利用ユーザに対するserviceAccountUserの権限を付ける
#権限
ユーザ利用のGCEのSAのIAPトンネル権限を踏み台IAPにつける
SAに利用ユーザに対するserviceAccountUserの権限を付ける
#GCEインスタンスにSSHをし下記を実行
#自分に通信するプロキシ
export http_proxy=http://localhost:3128
export https_proxy=http://localhost:3128
#それを転送する
gcloud compute start-iap-tunnel --zone asia-northeast1-a gce-host-proxy001 3128 --local-host-port=localhost:3128 --project=bangboo-kuso-proxy &
#外部通信
git clone xxx
#止める(止めないと同じホストに繋ぎに行く）
lsof -i 3128
ps ax | grep 3128
ps ax | iap
lsof -i 3128
ps ax | grep 3128
ps ax | iap
ps からの kill -kill <iap ps> でできそうにない
gcloud auth revoke からの gcloud auth login の再ログイン？
export -n http_proxy
export -n http_proxy
■踏み台経由して他のインスタンスに接続
#踏み台に接続
gcloud compute ssh step-fumidai001 --project=bangboo-unco --zone=asia-notrheast2-a --tunnel-through-iap
#リストを出し該当ホストを見つける
gcloud compute instances list
#踏み台から他のへ接続
instance=bangboo-kami
gcloud compute ssh $instance --internal-ip --zone=asia-northeast2-a
#もしGKEなら接続前にstep-fumidai001でクレデンシャルが必要だったり、、、
gcloud container clusters get-credentials main -zone asia-northeast2-a --project bangboo-k8s
■curlで認証を受けながらのURLアクセス
●SAキーをアップロードなら、、
■curlで認証を受けながらのURLアクセス
●gcloud auth loginしていると、、
curl -H "Authorization: Bearer $(gcloud auth print-identity-token)" https://宛先
●SAキーをアップロードなら、、
export GOOGLE_APPLICATION_CREDENTIALS="/home/aho/sa-key.json"
この環境変数はgcloudライブラリ/SDK等が認証情報として参照するようになっている
access_token=$(gcloud auth application-default print-access-token)
curl -H "Authorization: Bearer $access_token" https://kuso.com/api/endpoint
■キー３種
■キー３種
サービスアカウントキー
APIキー
credentials（Oauth clientIDを作成しキー生成）
APIキー
credentials（Oauth clientIDを作成しキー生成）
■Workload identity federation
使うサービスがIdPを持ってWIF対応していればSAキー無く使用できる(GCPの
SAは要る)
●GCP<-AWS,Github,EKS等OpenID connect/SAML2.0
事前設定）GCP SAを作成し権限付与
GCPにWIプールを作成
GCP WIプールで該当IdPを認証、外部アカウントを紐づける
1)UserがIdPにリクエスト
2)IdPがUserを割り当てたIDトークン(JWT)発行
3)IdPがIDトークンをGCPに検証
組織を限定するGCP設定
リポジトリを限定するGCP設定
4)GCPがWIF一時トークンを発行しUserがGCPリソースを使用
Workload Identity Federationを図で理解する - Carpe Diem (hatenablog.com)
●GCP<-GKEクラスタは他の方法もある
●GCP<-GKEクラスタは他の方法もある
●●GKEのSA設定（WIF以外）
1)ノードに紐付いたサービスアカウントを使用する
GKEクラスタ作成時にIAM SAを指定かGCEデフォSAが設定されるのでこれでGCP使用
GKEノードのワークロード全てで同一のSAが使用されPod毎に権限を分けられない
GKEの中身はGCEなのでGCEインスタンスのSAを見る？GCEが無いかも
GKEがAutopilotならWIFが有効でノードSAがGoogleAPI用には使えない？
2)SAのキーを Kubernetes SecretリソースとしてGKEクラスタに登録
IAM SA キーの有効期限が長く、手動でログローテーションが必要な点が懸念
エクスポートした IAM SA の流出リスクがある
GCP SAとキーを作成しキーをマニフェストに設定
●●GKEのためのWIF利用（推奨）
GKE node SA @project.iam.serviceaccount.com を
pool name - namespace の WIプールで
GOP SA の pool-namespace@project.iam.serviceaccount.contに紐づける
コマンドやマニフェストで詳しくはLink先で
ブールを有効化するとノードSAが使えなくなるので注意
コマンドやマニフェストで詳しくはLink先で
ブールを有効化するとノードSAが使えなくなるので注意
■GCEでOSConfigAgent のエラー(apt updateが失敗する、リポジトリが変わった）
sudo apt-allow-releaseinfo-change update
を複数回実行することで新しいリポジトリが追加される
■SAでGoogleドライブにアクセス
OUを使う解決策。Trusted RuleによりGCP サービスアカウントからGoogle Driveへのアク セスを許可する方法です。サービスアカウントのグループがアクセス可能なOUを作りOU内 で専用共有ドライブを作成する。
■IAM>PAM
一時付与の権限申請ができる
■スクリプトによる権限付与
Grant文、BQ、Python 等の方法がある
■ZOZOの新米Google cloud管理者
新米Google Cloud管理者の奮闘記のその後 〜Organizationの秩序を維持する試み〜 - ZOZO TECH BLOG
■データ
次世代データ基盤：データレイクハウスを Google Cloud で実現する (zenn.dev)
- BigQuery Data Transfer Service：
Cloud Storage や Amazon S3、Azure Blob Storage など格納されているデータを BigQuery に転送するマネージド サービスです。主に構造化データや半構造化データをバッチ処理にて BigQuery へ直接転送したい場合に使用します。 - Storage Transfer Service：
Cloud Storage、Amazon S3、Azure Storage、オンプレミス データなどに格納されているオブジェクトやファイルを Cloud Storage へ転送するマネージド サービスです。主にオブジェクトやファイルをバッチ処理にて Cloud Storage へ直接転送したい場合に使用します。 - Datastream：
Oracle、MySQL、PostgreSQL といったデータベースのから BigQuery に対してシームレスにデータを複製できるサーバーレスな変更データ キャプチャ（CDC）サービスです。データベースの内容をリアルタイムに BigQuery へ反映したい場合に使用します。 - Cloud Data Fusion：
フルマネージドのデータ パイプライン構築サービスであり、ノーコード・ローコードで ETL を実装できます。データ転送のみの用途でも使用可能であり、特に プラグイン を使用することで、多種多様なデータソースに対応することが可能です。また、Datastream と同様に Oracle、MySQL、PostgreSQL から BigQuery への CDC 機能も提供されています。 - Dataflow：
Apache Beam のプログラミングモデルを使用して、大規模なデータを処理できるフルマネージドでサーバーレスなデータ処理サービスです。データ転送のみの用途でも使用可能であり、Google 提供テンプレート を使用することで、簡単にデータ転送の仕組みを構築することができます。 - Pub/Sub：
フルマネージドなメッセージキューイングサービスです。Cloud Storage サブスクリプション を使用すると、Pub/Sub メッセージを Cloud Storage に対して書き込むことが可能です。また BigQuery サブスクリプション を使用すると、Pub/Sub メッセージを BigQuery テーブルに直接書き込むことができ、 さらに BigQuery CDC を使用するとテーブルの行単位で UPSERT（UPDATE, INSERT）、DELETE が可能です。 - Database Migration Service：
MySQL や PostgreSQL から Cloud SQL や AlloyDB に対して、マネージド サービスへのリフト アンド シフト移行やマルチクラウドの継続的レプリケーションを行います。オンプレミスや他クラウドからのデータベース移行が必要な場合に使用します。
- BigQuery：
SQL によってデータ変換を行います。ルーティンとして、ストアド プロシージャ や ユーザー定義関数、テーブル関数 、Apache Spark 用ストアド プロシージャ が使用できます。また、リモート関数 を使用すると、Cloud Functions と Cloud Run にデプロイされた関数をクエリから呼び出すことができます。 - Dataflow：
前述の通り、フルマネージドでサーバーレスなデータ処理サービスです。同一コードでバッチとストリーミングの両方に対応できるという特徴があります。また、通常の Dataflow だと水平方向のみの自動スケーリングとなりますが、Dataflow Prime を使用することで、垂直方向へも自動スケーリングが可能です。 - Dataproc：
Hadoop と Spark などのデータ処理ワークロードを実行するためのマネージド サービスです。既存の Hadoop / Spark を移行する場合やプリエンプティブル VM または Spot VM によってコストを抑えたい場合に適しています。 - Dataprep：
分析、レポートなどに使用するデータを視覚的に探索、データクレンジングできるデータサービスです。特にUI操作でデータ探索やデータクレンジングが可能なことが特徴です。 - Cloud Data Fusion：
前述の通り、ノーコード・ローコードで ETL を実装できるフルマネージドのデータ パイプライン構築サービスです。データのコネクションだけでなく、ETL に関する様々な プラグイン が用意されていることが特徴です。
■BigQuery CDC(Change data capture)
upsert/delをBQ storage write APIを利用してリアルタイム反映ができる
すでにDatastream for BQの裏で利用されており、PostgreSQL/MySQL/Oracle等データ同期可
変更データ キャプチャを使用してテーブル更新をストリーミングする | BigQuery | Google CloudPub/Sub の BigQuery Change Data Capture 機能について (zenn.dev)
■Binary authorization
GKEやRunに信頼できるコンテナイメージのみをデプロイするための管理
ポリシーや承認者を設定してOKのもののみ許可する
コンテナ脆弱性スキャン強弱の設定等
■reCaptcha
v1はゆがんだ文字を入力するもの、v2は画像を選択し私はロボットではありませんとチェック、v3はWeb行動履歴等をスコア化して自動的に判定を行う操作不要のもの（GCPコンソールで結果分析もできる）
■BQ DuetAI
BQ studio内にnotebookがありpythonが使える（現在プレビュー
MLモデルを作成し使用できる
クエリで#コメントを書くとSQLを生成したり解説してくれたりする
■Google cloud developer チートシート
Google Cloud Developer Cheat Sheet (googlecloudcheatsheet.withgoogle.com)
システム構成図を書けばTerraformを書いてくれる
■NotebookLM
ASCII.jp：情報整理の決定版「NotebookLM」が最高すぎる。こういうのがほしかったのよ！！ (1/7)
自分専用AIを作る グーグル「NotebookLM」を家電取説・辞書・時刻表で使う - Impress Watch
今さらながらGoogleの「NotebookLM」を触ったら、インターネットサーフィンが普通にそのまま"仕事"になった話 (zenn.dev)
■Google cloud developer チートシート
Google Cloud Developer Cheat Sheet (googlecloudcheatsheet.withgoogle.com)
システム構成図を書けばTerraformを書いてくれる
■NotebookLM
ASCII.jp：情報整理の決定版「NotebookLM」が最高すぎる。こういうのがほしかったのよ！！ (1/7)
自分専用AIを作る グーグル「NotebookLM」を家電取説・辞書・時刻表で使う - Impress Watch
今さらながらGoogleの「NotebookLM」を触ったら、インターネットサーフィンが普通にそのまま"仕事"になった話 (zenn.dev)
