/// BANGBOO BLOG ///

  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21
  • 22
  • 23
  • 24
  • 25
  • 26
  • 27
  • 28
  • 29
  • 30
  • 31

May 20, 2021

GCP
■GCP(Google Cloud Platform)
https://console.developers.google.com/
GCPを活用するスキルを問われる「Associate Cloud Engineer」
インフラストラクチャの知識を問われる「Professional Cloud Architect」
データと機械学習の知識を問われる「Professional Data Engineer」
　マシーンラーニング：教師ありをベースにパターンを線形として認識し相似のパターンを見つける
　ディープラーニング：人間が把握できる次元のデータ構造ではない多次元でパターンを見つける
　　線形検索みたいなもんか

■GCP
https://techblog.gmo-ap.jp/category/gcp/
https://tech.zeals.co.jp/entry/2019/01/08/094054
https://techblog.gmo-ap.jp/category/tensorflow/

情報源
Solution Design Pattern (gc-solution-design-pattern.jp)
google-cloud-jp – Medium
サポートを付けるとGoogleに聞き放題になったりする
　サポートのケースは組織レベルでみると全プロジェクトのケースが見れる

3か月間300 ドル分だけ無料
https://console.cloud.google.com
無料枠
GCE:プリエンプティブル以外の1つの以下のe2-micro VMインスタンスと30GB/月の標準永続ディスク
　オレゴン: us-west1
　アイオワ: us-central1
　サウスカロライナ: us-east1
GCS: 5GB/月のRegional Storage（米国リージョンのみ）

無料だとBigQueryのDML(insert)ができないらしい
予算とアラートを1円で設定（通知チャネルにSMSとメール設定）
　月額のプロダクトを日割レポートで見ると2月の日割りは高く見え、3月は安く見える
　為替の影響は月初から適応されるので円安だと高いよ

辞めるときはプロジェクトをシャットダウン＆請求先アカウントの閉鎖
１）プロジェクトの閉鎖
Google Cloud Console ＞ IAMと管理 ＞ 設定 ＞ シャットダウン
２）請求先アカウントの閉鎖（原因不明だが下記画面が出るときと出ないときがった）
Google Cloud Console ＞ お支払い ＞ (左ナビ)アカウント管理 ＞ 請求先アカウントの閉鎖
※お支払い＞マイプロジェクト＞アクション＞無効や請求先変更ができる

セキュリティは使用GoogleアカウントのSMSによる２段階認証、信用するデバイスの設定があるようだ

　GKE, Cloud SQL, Dataflow等
【GCP入門編・第3回】難しくない！ Google Compute Engine (GCE) でのインスタンス起動方法！ | 株式会社トップゲート (topgate.co.jp)
【GCP入門編・第12回】 BigQuery を使って気軽にビッグデータの解析を行ってみよう！ | 株式会社トップゲート (topgate.co.jp)
【GCP入門編・第25回】 Cloud SQL for MySQL で Master-Slave 構成を組もう！ | 株式会社トップゲート (topgate.co.jp)
【GCP入門編・第29回】Cloud Load Balancing で Web アプリケーションにロードバランサーを設定する | 株式会社トップゲート (topgate.co.jp)
【初心者】GCP Identity-Aware Proxy (IAP), Access Context Managerを使ってみる (WEBサーバへのアクセス制限) - Qiita

■IAM(Identity and Access Management)　
https://cloud.google.com/iam/docs/overview?hl=ja
https://cloud.google.com/iam?hl=ja
IAMベストプラクティス　https://cloud.google.com/iam/docs/using-iam-securely
操作方法　https://cloud.google.com/iam/docs/how-to?hl=ja
ロール　https://cloud.google.com/iam/docs/understanding-roles?hl=ja
https://www.isoroot.jp/blog/1244/
https://medium.com/google-cloud-jp/gcp-iam-beginner-b2e1ef7ad9c2

//IAMの機能（RBAC認可：role based access control）
機械学習を使ったスマート アクセス制御の最適化
デバイスのセキュリティ、IP アドレス、リソースタイプ、日時などの属性に基づいて、リソースに対するきめ細かいアクセス制御ポリシー
権限の認可、解除、委任に関するすべての監査証跡の履歴
ユーザーとグループのプロビジョニングや管理、シングル サインオンの設定、2 要素認証プロセス（2FA）

//IAMポリシー
IDをGroup（●●部）にアサイン
　Members(Group等)にRoles（●●役）をアサイン
　　MembersとはグループやドメインやID(Googleユーザアカウント、サービスアカウント)
　Roles（●●役）にPermissions（権限）を付与

ロールは作成ができ●●世話役みたいな感じか
permissionsは権限で「resourcemanager.projects.get」等でロールに紐づける
　個人や無料アカだと組織がない？→フォルダが作成できない？
　組織がないとグループが作成できない→グループがないとIDにRoleを付与するしか
フォルダは組織ツリー状でリソース管理、組織改編が多いならプロジェクトフォルダでも
　各フォルダに対してそれぞれメールグループを定型(folder-admin/dev/lead/member/parttime/etc)で持たせ
　メールグループへのユーザ出し入れで権限の管理をするのが良さそう
IAMやServceAccountの一覧には出てこないが存在するIDがある、実際に権限を付与できるかで存在確認する(TFで作成の場合？)
ポリシーはMSのGPOみたいものも組み込みで存在する
サービスアカウントはAPI用、人が使うことは基本想定されていない(impersonate等できるが
ユーザが削除になっても権限やリソースは残る？30日位はdeleted:になって消えるのでは
プリンシパルには@gmail.comのGoogleアカウントやWorkspace契約のある組織ドメインのGWSアカウント等があり、独自ドメインでもGWS契約がない場合は@gmailのように登録しGoogleアカウントにして使用する
GCPはGWS gmailメールの変名に追従して権限も付与状態も変化がなく問題がない
　しかしterraformは追従しないためtfファイルでメールを使っている場合は変更する
外部ドメインのユーザの場合はメールグループ単位でのロール付与が効かず個別アカウントで付与する必要がある？あるいは組織ポリシーを開けっ放し？
APIを有効化せんと何もできないが、するロール roles/serviceusage.serviceUsageAdmin

メールグループの権限関係の確認方法
　仕組み：祖->親->子、上の権限は下も持つ
　権限から確認する、所属から確認するの両面で確認
　１）権限を持っている全ての子をリストアップ
　２）所属しているメールグループの全ての親をリストアップ

//画面上部のプルダウンからプロジェクトを選択できない場合
（BQのデータセットにのみ権限がある等）
１）BQの左ペーンでデータセット名を検索し（すべてのプロジェクトを検索するため2回必要）スターを付けて代替とする
２）データセットレベル権限でもURLパラメータ付きだと選択ができる
http://console.cloud.googl.com/bigquery?project=bangboo-kuso-project
３）IAMの画面で何かしらresourcemanager.projects.listを含むロール、つまりBQ data viewerでOKだがプロジェクトレベルの権限を付与しておく（権限付与後にログインしなおしが必要）
※jobuserがないとBQコンソールでプルダウンできない訳ではない（jobuserなしでOK）
※グループメールの深い階層で付与されていても影響はしない

//リソース
階層：Organization > Folders > Project > Resource(Google Cloud services)
割り当て：日や分に対してのデータ量の上限等を設定

必要以上に権限を付与しない
組み込みロールが多い、改変してロールを作るか
権限はサービス名.リソース.動詞という命名規則
プロジェクト名はGCPグローバルで名前空間を共有しており、企業名等でprefixするのがいい
プロジェクト毎にメールグループを設け、権限はメールグループの参加で管理したい

//リージョンとゾーン
リージョン：データセンターの存在場所、ゾーンをいくつか持つ
ゾーン：障害ドメイン区画（単一障害点を避ける形で環境設計したい）
Google Cloud SDKをインストールすればコマンドラインが使える
　BQは同一リージョンでないとJoinができない、ゾーンはマルチで良い
APAC: asia-east(台湾、香港)、asia-northeast(日本、韓国)、asia-south(インド)、asia-southeast(シンガポール、インドネシア)、australia-shoutheast(オーストラリア)
NA: northamerica-northeast(モントリオール、トロント)、us-central(アイオワ等)、us-east(バージニア等)、us-west(ネバダ等)
リージョンとゾーン  |  Compute Engine ドキュメント  |  Google Cloud

//サブネット、Shared VPC
Shared VPCホストプロジェクトに対しサービスプロジェクトを設定しプロジェクト間を共有
サブネットは通常リージョン内？レガシーだと完全に仮想で自由なサブネット？

//Cloud Shell
Google Cloud Shell の 10 の知っておくと便利な Tips | Google Cloud Blog
ファイルのアップロードやダウンロードが可、コードエディタもありブラウザで完結
Webアプリのプレビューも可
　f1-microのGCE一時インスタンスがプロジェクトをまたいだ永続ディスク5GBで起動されている
　gcludやdocker,bash,sh,vim,nano,pip,git,mysql等がプリインスコされている
　　5GBあるのでインスコもできる　sudo apt-get install gawk
　Cloud Shell VM の Zoneを知る：curl metadata/computeMetadata/v1/instance/zone
　Ctrl + b キーを押してから % キーを押すとtmux により ウィンドウが左と右のペインに分割
Cloud shellのグローバルIPを取得できる
　curl http://ifconfig.me/

リスト一覧を出すgcloud cmd
gcloud projects list --filter='bangboo-' --format=json | grep -oP '(?<="name": ")[^"]*'

どのgcloud cmdにも使えるワイルドフラグ
--access-token-file, --account, --billing-project, --configuration, --flags-file, --flatten, --format, --help, --impersonate-service-account(人がcmdを打つ場合でも成りすませる、その人にprjレベルの権限が必要), --log-http(cmdでエラーがでるならコレを、詳細が出る), --project, --quiet, --trace-token, --user-output-enabled, --verbosity

各言語でのSDKを使ったプログラムを実行する際の認証を得るために使います
gcloud auth application-default login
ローカルで以下のようなGCP系CLIを実行する際の認証を得るために使います
gcloud config configurations list
gcloud config configurations create unko-profile
gcloud config set account unko@dot.com
gcloud config set project onara-project
gcloud config configurations activate unko-profile
gcloud auth login

■GCE
　Marketplaceを使えばアプリを数クリックでデプロイできる
　永続ディスク…NWストレージ、SSD永続ディスクも選択できる
　ローカルSSD…高性能、永続ではなく一時的
　非マネージドインスタンスグループ　インスタンスをIGに紐づけるだけ
　ステートレスMIG　自動スケーリング（Webフロントエンド等）
　　スケジュールでもスケーリングできる(cronや予測も)
　ステートフルMIG　設定を保持可（DBやデータ保持必要なstatefulなアプリ等）
　　インスタンス名やIPやディスクやメタを維持する、部分的に外部化ステートレスにして自動化等も
　ゾーンMIG＝シングルゾーン、リージョンMIG＝マルチゾーン(最大3ゾーン)
　プリエンプティブは24時間までだが20%課金だけで安い

インスタンスにサービスアカウントを改めて設定するとGoogleAPIはこれで実行される
　改めて設定しないとデフォルトSA
　操作自体はSSHで入るユーザで操作をする
　　設定はsudoして行うことが多く例えばcronはroot実行になっている
　　SSHで入ったユーザで設定するなら所有者/グループ/他のパーミッションを設定した上で

■マネージドクラウドDB各種
ホワイトペーパーPDF

■Bigquery
/// BANGBOO BLOG /// - BigQuery
/// BANGBOO BLOG /// - GCP ログ調査 Logging/Bigquery information schema

■GCS
　http(s)で公開可（そもそも公開しているがAllUsersやAllAuthenticatedUsersや各ユーザに権限がついていないだけ）
　Nearline…3カ月でアクセス等（全ファイルを1度閲覧）
　Coldline…1.5年でアクセス等長期アーカイブ
　(standard以外は最低保存期間の縛りがあり早期削除でもお金が掛かる)
　Multi-regional 99.95%、Regional 99.9%の可用性
　　BigqueryからGCSにエクスポートできるが1GBまで
料金  |  Cloud Storage  |  Google Cloud
　　5GBまで無料、リージョンで値段が違う、保存/NW/取得/操作で課金
　　nearlineの保存は半額で取得と併せstandardと同じ金額になるが操作費高い
　　coldline/archive storageでも長期保存はせずできれば削除する、できないならポリシーでcold/archiveへ移動
　　　　最低保存期間の縛り(90/365)があり早期削除でも請求、その期間は置いておく
　　autoclassだとニア→コールド→アーカイブといい感じにしてくれるが1000ファイルにつき0.0025追加料金
　　　※128kb以下は適応されずstdで追加料金もかからない
Autoclassが安全便利でファーストチョイス？単価から370kb程度以下で損する
　バケット作成時に設計をしておく（バケット編集でAutoClassが変更できるようになった）
　　ライフサイクルを決めて削除条件も決めておく
　　バケットを細かく分けた方がよいかも（バケット内でフォルダを作るとコマンドが遅く管理が面倒）
　　　ファイルサイズが大きいもの＝AutoClassが良いかも
　　　ファイルサイズが小さいもの＝OLMでライフサイクル設定（クラスと削除）
　ログ保存用途ならColdline/Archive設定＋OLMでの削除設定
gsutil ls -lR gs://aaaa　バケット内の各ファイルのサイズと、最終行でオブジェクト数と合計サイズが分かる（オブジェクト数はフォルダも一つとカウントされる、フォルダはサイズが0）
※GCSの注意点
早期削除料金の発生がリスク
ストレージクラスはファイルごとに設定がある、バケットはデフォルト設定だけ、AutoClassはバケット
オブジェクトライフサイクルマネージメントOLMでストレージクラスの変更すること
早期削除料金は削除、置換、移動、クラス移動でかかるが、OLMのクラス移動ではかからない
OLMの変更はファイル単位で変わりバケット設定をみてもクラスが分からない
手動(gsutilやAPIという意味)で変更するとStd以外は早期削除料金で高額化の恐れ
　ただしOLMは若返りの方向へのストレージクラス変更はできない
　gsutilやAPIでなら若返りストレージの変更ができる
Std以外は保存と閲覧の使用としたい、なぜなら、置換はファイル編集が該当するためファイルサーバとできないから
費用は保存費、オペレーション費、NW費、Std以外は取得費等からなり、費用は利用サイズの影響が大きく、通常は保存より利用の費用が高くなる
早期削除料金はStd以外で削除されたり更新がかかればファイル単位でかかる
早期削除料金は最低保存期間分がかかるがファイル作成日を元に計算されどのストレージであっても日数としてカウントされる
LoggingをBQに吐き出しておけば、利用者やバケット作成者が分かる　protopayload_auditlog.methodName = 'storage.bucket.create'　とかの条件

/// GCSの論理削除によるデータ保護
削除や上書き等でも元に戻せる。ソフトデリート適応期間分の費用/オペA費用が掛かるが
リストアには大量データの場合は数日かかる場合があり保持期間の延長の考慮が必要 (デフォ7daysでは不足するかも)
パケットの削除のやり直しはGoogleに問い合わせが必要
早期削除は物理削除日を元に計算するので論理削除の期間後の日時が使用されるので、7days早めに削除してもいいかも

■GCP Cloud asset inventory
　5週間分の履歴が保管される
　CAI exportにより任意のタイムスタンプでBQあるいはGCSに履歴情報を吐き出す
　　コマンドやライブラリでダンプが可能
　gcloud CLIのgcould asset search-all-resourseコマンドにより設定
　　BQに吐き出し各種状況のチェックやポリシーのチェックに活用

権限の確認もコマンドでできる
　gcloud asset analyze-iam-policy --organization=123456 --identity="user:fack@unko.com"

■Cloud logging
　毎月取込50GBまで無料、取込0.5$/GB+保存0.01$/GB、2種類ありAuditLogで有効無効化
　　管理アクティビティログ　13ヵ月400日デフォ有効（_requiredログバケットは取込もデフォ期間保存も完全無料）
　　データアクセスログ　デフォ無効（有効にしてもデフォ保存期間30日は無料、50GBを超える取込が有料）
　　　※つまり50GBを超えた取込、あるいは保存期間を伸ばした分が有料
　BQ streaming insert0.05$/GB+BQ保存(10G無料)0.02/GB=0.07$/GBでBQ化し保存が得
　　長期保存が必要なものだけエクスポート
　　集約エクスポート
　　ログ取集前にログシンク(取込費がかからない)
　　　サンプル1%等で絞る等
400日の_requiredに入らないものが30日の_defaultに入る
Logルータのシンクでフィルタ、サンプリングしLogバケット/GCS/BQ/Pubsubに転送
　requiredでなくdefaultに入る時にLogルータを設定しフィルタを掛ければ減る
　自動でSAが作られるので作成や権限付与は不要
　　包含フィルタが空なら全ログ
　　クエリsample(insertId, 0.10)で10%のサンプル
Logバケットのdefault30日は変更できる
全ログをBigqueryに入れるには組織プロジェクトで転送を設定すればいい
 クエリ：Loggingをクエリで見る、Logルータのシンクをフィルタ(サンプル)する

■Monitoring
ダッシュボードはサンプルから作ると楽
MQLで改変、クエリを実行するとエラーメッセが出るんで
fetch gae_instance::appengine.googleapis.com/flex/cpu/utilization | { top1, max(val()); bottom 1, min(val()) } | UNION
　MQLは使えなくなりPromQLに変わった

■APIキー
APIキーを発行することで、外部アプリから利用できるようになる。各種使えるが強力なためAPIを絞る等制限を入れた方がよい、アクセス元のIPアドレスやリファラーで縛る等も
API キーを使用して認証する  |  Google Cloud
【要確認】Google Maps Platform APIキーの取得方法と注意点 | ワードプレステーマTCD (tcd-theme.com)

■サービスアカウント
デフォルトでは上限100個
svacキーはPWと同じ、できるだけ発行せず慎重に管理、gitにUP厳禁
svac名や役割を広くしない、強すぎる権限は付与せず最小限の権限で
GCEデフォのsvacは使用しない(Editorを持つから)
　サービスアカウントはサービスを有効化したときに動作用に自動作成されたり、別途手動でも作れる
所属のプロジェクトが削除されると：
　サービスアカウントは削除できなくなり、権限が残るため権限は個別削除が必要になる
　サービスアカウントの権限が残るが、他のプロジェクトで使用できる
　一定期間が経つとサービスアカウントの権限も自動削除される
　＞プロジェクト削除前にサービスアカウントの無効にするのが望ましい
IAMでsvacにロールを付与、IAM>svacでユーザにsvacに対する管理ロールを付与できる
組織ポリシーでsvacキーの使用を特定のプロジェクトに制限した方が良い
できればキーを作成せず他の方法を
　workload identity(gke)、workload identity federation(serverless)
　　SAMLみたいなものでGKE、OpenID、AWS、Azure、ActiveDirectory、GoogleCloudAPIは対応している
　一発使用ならimpersonateで成り済ませば一連のgcloud cmdは実行できる(下記参照)
SAキーの管理方法
　キーの削除、あるいはIAMコンディションにより権限側の変更、あるいはVPCサービスコントロールで制限位しかない
　有効期限の設定は無い、キーローテート機能もなくコマンドで自作するしか（削除と作成をするだけ）
　キーローテートを要求するため、キーは各々で発行してもらう
　　手前でキーを発行した方が、キー削除や追跡ができるがローテートの手間がある、手前だと権限付与も少なくできるが、、


svacキーはRSA鍵ペア、秘密鍵でJWT署名なしトークンを作成（JWT=json web token）
　GCP内ではキーが自動rotateされている
　外部の場合は手動や仕組みでローテーションしたい
　開発環境ではクライアントライブラリとgoogle application credentials環境変数を使い隠匿する
サービス アカウント キーを管理するためのベスト プラクティス  |  IAM のドキュメント  |  Google Cloud
Google Cloud SDKのインストールと認証の設定について - TASK NOTES (task-notes.com)
概要 / アジェンダ - Infra OnAir (cloudonair.withgoogle.com)
秘密鍵さえあれば成り済ませ追跡が困難で誰が利用したか等が分からないのでsvacキーは使いたくない
svacキーは10個作成できる

/// svacキー使用方法
サービスアカウントのキーを作成しローカルに保存
SSHでGCEのVMに内容をコピペしてキーファイルを作成
下記でSAとしてログイン
gcloud auth activate-service-account ketsu@un.com --key-file /home/ketsu/sakey.json
cloud shell terminalでもファイルをアップロードできるのでup後下記でOK
gcloud auth activate-service-account ketsu@un.com --key-file sakey.json
ログオン切替
終わるとき rm sakey.json

shellセッションごとに環境変数でkeyを設定する方法も
認証のスタートガイド  |  Google Cloud

/// サービスアカウントキーを発行せずにサービスアカウント権限を使う
サービスアカウントに直接成り代わって gcloud コマンドを実行する - Qiita
サービス アカウントの権限借用の管理  |  IAM のドキュメント  |  Google Cloud
gceにデフォルトsvacが設定されていれば誰で入ってもauthはsvac？パスはユーザだが
任意のコマンドに--impersonate-service-account=ワイルドフラグを付けるだけ
IAM and Resource Manager API を有効化
サービスアカウントに使いたいロールを付与(roles/accesscontextmanager.policyAdminとか)
自身にroles/iam.serviceAccountTokenCreatorを付与
叩くgcloud info --impersonate-service-account=chinko-compute@developer.gserviceaccount.com
　※tfだとproviderにimpersonate_service_accountを追加する形
設定するにはこれらしい
　gcloud config set auth/impersonate_service_account chinko-compute@developer.gserviceaccount.com
svacを指定するならこれでもいいがKeyがいる
　gcloud auth activate-service-account chinko-compute@developer.gserviceaccount.com --key-file=/himitsu/dame_key.json --project=bangboo-kuso
ログインユーザ確認で要確認
　gcloud auth list
gcloudコマンドのリファレンス

■セック
Google workspace googleアカウント(特定の経路:IP以外は無効）
組織ポリシー(GCP)　Google Cloud 組織ポリシー - Qiita
　serviceuser.services deny compute.googleapis.com デフォルトcomputeなし
　compute.skipDefaultNetworkCreation enforced=true デフォルトcompute nwなし
　compute.vmExternalIpAccess inherit_from_parent=true
　iam.allowedPolicyMemberDomains inherit_from_parent=true 対象組織 外部ユーザ禁止
　　→allusers/allauthuserも影響する(このためGCSもallusersが設定できず公開にはならない)
　iam.allowedPolicyMemberDomains inherit_from_parent=false 対象prj 外部ユーザ許可
　storage.uniformBucketLevelAccess enforced=true GCSアクセス制御を均一
　storage.publicAccessPrevention=true 公開しない(allusersも消える、逆にoffってもallusersも要る)
　sql.restrictAutherizedNetwork enforced=true CloudSQLのネットワーク制限
　compute.restrictLoadBalancerCreationForTypes allow=in:INTERNAL LBは内部だけ許可
　compute.restrictLoadBalancerCreationForTypes allow=all=true 対象prj LB許可
　compute.disableSerialortAccess enforced=true シリアルポートアクセスの制限
　compute.disableSerialortAccess enforced=false 対象prj シリアルポートアクセスの許可
BeyondCorp Enterprise(VPNレス、なお下の各要素はこの為だけということではない)
┣ IAP
┣ IAM
┣ Access Context Manager(VPC Service Controls:IPとかメールドメインとか) 
┗ Endpoint Verification(Chrome機能拡張)
Cloud armor(WAF)、FW
危険な設定はアラートを出したい：security command center、cloud asset inventoryをBQに出し定期スキャン
BigQueryの高額クエリはアラートを出したい

セキュアなBigQueryの運用方法 - Speaker Deck
　IAM condition: 20時以降はアクセスできない等時間やリソースで権限制御
　VPC-ServiceControls: VPC+FWで制限を掛けられなかったIPやIDで制限を掛ける(クレデンシャル漏洩防御)
　　LBのバックエンドをGCSにするとIAPが使えない時も
　　TF)perimeterで境界を設定してaccess leveで超えれるものを定義
　　　危険で user explicit dry run spec = trueでテストしながら falseで本番化
　　　statusが本番用、specがドライラン用で一旦statusを消してテスト
　　　　restricted_services = storage.googleapis.com ならGCS
　　　　resource
　　　　access_level
google_access_context_manager_service_perimeter | Resources | hashicorp/google | Terraform | Terraform Registry

VPCサービスコントロール＋Access context manager
VPC SCで組織で有効にするプロジェクトを指定し、上り(内向き)のソース、ID、プロジェクト、サービスを指定、ACMで許可するアクセス元地域やデバイスを指定(beyond corpかも)
VPC Service Controls の概要  |  Google Cloud
VPC Service Controlsを分かりやすく解説 - G-gen Tech Blog
サービス境界とアクセスレベルで、特定のユーザーやサービスアカウントからしか BigQuery にアクセスできないようにしてみた | DevelopersIO (classmethod.jp)

GCPでセキュリティガードレールを作るための方法と推しテク - Speaker Deck
　サブネット作成の際はセキュリティの観点からフローログを15分で取る
　監査ログを有効に
　ContainerResistryの脆弱性スキャンを有効に
　ログ：データアクセス/ポリシー拒否は30日、管理アクティビティは400日
　　BQにバックアップしたい
　SecurityCommandCenterで脆弱性を検知
Cloud Audit Logging 活用のベスト プラクティス | Google Cloud Blog
　集約エクスポート シンクにより監査ログをBQに貯めたい

■タグとラベル
組織ポリシーはタグでconditionを指定した上で設定できる
タグは権限管理のための機能
タグは事前に組織レベルでタグを作成する、その後にリソースに対しタグ付け
FWで使うのはネットワークタグで種類が違うと思われる
ラベルはリソース整理や課金整理のための機能

■ネットワーク
外部IP
　External IP addressで取得、300円/月位、通常一つは自動で割り当てられる
PoP(Point of presence)
　世界70か所でGCPとエッジ(ネット)接続
NWトポロジーで通信が可視化でき通信コストが分かる
　詳細開くのは片側だけにすると使用帯域が表示される

■課金
BillingのBilling ExportからBigQueryにダンプができる

■サービスイン、導入、廃止
どういうステップかよくわからんが
GA(Generally available)
サービスに関する重要なお知らせ：MSA(Mandatory service announcement)
Deprecated
Decommission

■他
///gcloudをプロキシで使う環境設定とか
https://qiita.com/tora470/items/bc00bef8cba9f9acecc7

///Loadbalancer
　IAPはhttp LB/GCE/AppEngineに
　Internal LBにExternal IPは無理

ついでにIAP tunnel userの権限で踏み台が作れる＋OS Loginで認証強化
　OS LoginはIAPの認証機能でSSH上でGCEインスタンスにログインできる代物
　GCPがSSH keyとIAMをGCEに準備してくれる

ついでにリバースプロキシ（nginxとかで作る）
LBみたいなもんだがプロキシでキャッシュを返す
代理代表サーバとなりWEBサーバ界のFWみたいな役割もできる

///NoSQL
=not only sql、分散kvsだったりの非構造化データ、下記2つのみ提供
　キーを指定してCRUD(追加、取得、更新、削除)
　キーの範囲かキーの前方一致でのスキャン

///bigtable
高スループット低レイテンシー読み書き速く膨大なユーザや数千万件テラ以上で
gmail、GA、マップ等々で使われている

///cloud functions
サーバレスでRESTみたいな形でURLでサーバアプリを実行、Node.js/PHP/Python等のコードが直接コンソールに掛ける
　ブラウザでcloud functionsにアクセスしたら下記が出た
Error: Forbidden Your client does not have permission to get URL/kuso-ketsu from this server
呼び出しの認証  |  Google Cloud Functions に関するドキュメント
curl https://REGION-PROJECT_ID.cloudfunctions.net/FUNCTION_NAME  -H "Authorization: bearer $(gcloud auth print-identity-token)"
↑curlでいいなら、コンソールで[未認証の呼び出しを許可する] 設定 + allusersでも可

///Pub/Sub
パプリッシャーからサブスクライバーにメッセージ転送、順序設定可、大量データを1件ずつとか
publisher -> topic : メッセージ -> push型 subscriber
publisher -> topic : メッセージ -> pull型 subscriber
-> cloud functions/runに連携したり、cloud schedulerから連携をしたり

BQ テーブルにデータをエクスポートする Dataflow ジョブ
GCS でデータをテキスト ファイルまたは Avro ファイルにエクスポートするための Dataflow ジョブ

///シリアルコンソール接続
SSH接続できない！そんな時のシリアルコンソール | apps-gcp.com
突然起動しなくなったWordPressサーバーをなんとか復旧した話 | (tipstock.net)

///gcloud cmd
gcloud organization list　GCP IDやGoogleWorkspace IDが分かる

///Recommender
API の使用 - 推奨事項  |  Recommender のドキュメント  |  Google Cloud

///Googleスプレッドシート+GAS＋BigQuery
GAS:マクロで記録してそれを使いまわす
　GASでBQの制御は難しいかも、更新してもBQのデータが古いままだったりする（appscript.jsonに権限を追記しても）
　　シート経由せずにGASから直にファイルに書き出すとましかも（下記コード参照）
　データを一時でも書込ならスプレッドシートの共有の編集権限とシート保護しない設定が必要と思われ（セキュリティがザルに）
呼び名
　connected sheetでBQのデータをスプシに抽出する
　federated queryはBQに外部ソース（スプシ等）をインポートする

スプシの保護（シートはコピーできザルなのでセキュリティ対策でなくデータ保護）
シートを保護する、非表示にする、編集する - パソコン - ドキュメント エディタ ヘルプ (google.com)
スプシの閲覧共有だけでBQコネクテッドシートのプレビュー/抽出は可能だが、それをvlookup系で他のセルに移せない
組織でコネクテッド シートを使用する - Google Workspace 管理者 ヘルプ
↓
他のブックにすればいいかも
編集共有した別ブックに入力データ（日付やメール）を持たせBQフェデレテッドクエリでBQに準備
閲覧共有した別ブックは参照用にBQコネクテッドシートがある形

■シートを経由しないBQを操作するGAS
const request = {
query: "select * from asoko",
useLegacySql: false
};
let rows = [['c1','c2']]
const result = BigQuery.jobs.query(request, 'kuso-prj');
for(let i=0; i < result.rows.length; i++){
let resultRow = result.rows[1];
let c1 = resultRow.f[0].v;
let c2 = resultRow.f[1].v;
let row = [];
row.push(c1, c2);
rows.push(row);
}
const spreadsheet = SpreadsheetApp.create("file", rows.length, 2);
const range = spreadsheet.getRange("A:B");
range.setValues(rows);
Browser.msgBox("A file is created"+spreadsheet.getUrl(), Browser.Buttons.OK);

GASのGCPプロジェクトは通常はデフォルトがベスト
　GASはOauthのためだけにGCPのプロジェクトを使う
デフォルトプロジェクトから切り替えると戻せない、利点も少しだけ（サイト参照）
appscript.jsonにoauthのスコープを追加しないと十分に機能しない
　GAS で OAuth のスコープが足りなくてやったこと (zenn.dev)
　GoogleAPIのOAuth2.0スコープ  |  Google Identity Platform  |  Google Developers
※エラーの場合
　BQの場合はBQコンソールでクエリ単体で実行しテスト
　loggingを見るともう少し情報がある
　コネクテッドシートならスプシの共有設定とBQの閲覧ロール等が要る、ビューならその先の小孫～最後までのロールまで要る
　　委任を有効にするとスプシ共有だけでBQロールが不要になるが、、
　　コネクテッド シートでアクセス権の委任を使用する - Google ドキュメント エディタ ヘルプ
　oauth自体でこけるとクッキー消去すれば待たずに再確認ができる？
Google Apps Script試行錯誤 Blog: デフォルトのGCPプロジェクトを標準のGCPプロジェクトに切り替えたい (pre-practice.net)
Google Apps ScriptのログをGoogle Cloud Platformで確認する方法 – hidetoshl.com

GASでAdminDirectoryを使う
　gas > サービス > AdminDirectory APIをOn
　gcp該当prj > APIダッシュボード > ライブラリ > Admin SDKを有効
　等でg workspaceのユーザ情報が取れるらしい
　　Google Apps Script試行錯誤 Blog: AdminDirectoryでUsers.listを取得したい (pre-practice.net)
　　GASでAdmin SDKを利用する（Directory編）その１ - Qiita

メールグループは任意にg workspace管理画面で削除が可能
GCP上はDeleted groupとなり1か月程度で削除される（IAMの状態は見れるが使えない）

■アプリ
公開資料 - App Modernization OnAir 〜 モダンなアプリケーション開発とは 〜 (cloudonair.withgoogle.com)
cloud runの設定だけでCDCIできる（第10回

End
twitter
Hatena
Google Buzz
newsing
Yahoo!
Buzzurl
Technorati
del.icio.us
Choix
Iza!
Livedoor Clip
Facebook
Evernote
 

Posted by funa : 09:00 PM | Web | Comment (0) | Trackback (0)


PhotoGallery


TWITTER
Search

Mobile
QR for cellphone  QR for smart phone
For mobile click here
For smart phone click here
Popular Page
#1Web
#2Hiace 200
#3Gadget
#4The beginning of CSSレイアウト
#5Column
#6Web font test
#7Ora Ora Ora Ora Ora
#8Wifi cam
#9みたらし団子
#10Arcade Controller
#11G Suite
#12PC SPEC 2012.8
#13Javascript
#14REMIX DTM DAW - Acid
#15RSS Radio
#16Optimost
#17通話SIM
#18Attachment
#19Summer time blues
#20Enigma
#21Git
#22Warning!! Page Expired.
#23Speaker
#24Darwinian Theory Of Evolution
#25AV首相
#26htaccess mod_rewite
#27/// BANGBOO BLOG /// From 2016-01-01 To 2016-01-31
#28竹書房
#29F☆ck CSS
#30Automobile Inspection
#31No ID
#32Win7 / Win10 Insco
#33Speaker
#34Arcade Controller
#35Agile
#36G Suite
#37Personal Information Privacy Act
#38Europe
#39Warning!! Page Expired.
#40GoogleMap Moblile
#41CSS Selectors
#42MySQL　DB　Database
#43Ant
#44☆od damnit
#45Teeth Teeth
#46Itinerary with a eurail pass
#47PHP Developer
#48Affiliate
#49/// BANGBOO BLOG /// From 2019-01-01 To 2019-01-31
#50/// BANGBOO BLOG /// From 2019-09-01 To 2019-09-30
#51/// BANGBOO BLOG /// On 2020-03-01
#52/// BANGBOO BLOG /// On 2020-04-01
#53Windows env tips
#54恐慌からの脱出方法
#55MARUTAI
#56A Rainbow Between Clouds‏
#57ER
#58PDF in cellphone with microSD
#59DJ
#60ICOCA
#61Departures
#62Update your home page
#63CSS Grid
#64恐慌からの脱出方法
#65ハチロクカフェ
#66/// BANGBOO BLOG /// On 2016-03-31
#67/// BANGBOO BLOG /// From 2017-02-01 To 2017-02-28
#68/// BANGBOO BLOG /// From 2019-07-01 To 2019-07-31
#69/// BANGBOO BLOG /// From 2019-10-01 To 2019-10-31
#70/// BANGBOO BLOG /// On 2020-01-21
#71Bike
#72Where Hiphop lives!!
#73The team that always wins
#74Tora Tora Tora
#75Blog Ping
#76無料ストレージ
#77jQuery - write less, do more.
#78Adobe Premire6.0 (Guru R.I.P.)
#79PC SPEC 2007.7
#80Google Sitemap
#81Information privacy & antispam law
#82Wifi security camera with solar panel & small battery
#83Hope get back to normal
#84Vice versa
#85ハイエースのメンテ
#86Camoufla
#87α7Ⅱ
#88Jack up Hiace
#89Fucking tire
#90Big D
#914 Pole Plug
#925-year-old shit
#93Emancipation Proclamation
#94Windows env tips
#95Meritocracy
#96Focus zone
#97Raspberry Pi
#98Mind Control
#99Interview
#100Branding Excellent
Category
Recent Entry
Trackback
Comment
Archive
<     December 2024     >
Sun Mon Tue Wed Thi Fri Sat
1 2 3 4 5 6 7
8 9 10 11 12 13 14
15 16 17 18 19 20 21
22 23 24 25 26 27 28
29 30 31
Link