CloudSQL
MySQL フラグ周り
これらのフラグにデフォルト以外の設定を使用するインスタンスは、Cloud SQL SLA の対象外になります。
えー
CloudSQLProxy のインストール
$ gcloud components install cloud_sql_proxy
$ $(gcloud info --format="value(installation.sdk_root)")/bin/cloud_sql_proxy
Docker で CloudSQL Proxy を立てる
gcr.io/cloudsql-docker/gce-proxy を使う
ただし 1.17 からデフォルトで distroless になったので、環境変数で接続先変える shell script をマウントしたりコピーしたりして起動するのができなくなった、gcr.io/cloudsql-docker/gce-proxy:1.17-alpine などを使う
インスタンスごとに接続できるサービスアカウント
インスタンス単位の制御はまだない
つまり roles/cloudsql.client を持ってたら同プロジェクトに接続することは可能
MySQL レベルの user & password で制御する
サービスアカウントキーではない認証
CloudSQL Proxy はアクセストークンでも認証できる
アクセス トークンを作成し、Cloud SQL Proxy の起動時、コマンドラインでこのアクセス トークンを -token フラグとともに指定します。
作成したやつを -token=<TOKEN> に指定したら認証できた
サービスアカウントキーを作るより有効期限が短いし良いかと思ったけど微妙で
作業者のアカウントは大抵強力
サービスアカウントのトークンを生成するにはサービスアカウントキーが必要そう
For service account, please activate it first:
$ gcloud auth activate-service-account ACCOUNT
role 絞った管理用サービスアカウントで、使う時にキーを発行して終わったら失効させる、あたりがいいかなあ
作業者に、管理用サービスアカウントのアクセストークンを発行できる権限、みたいなのを割り当てられないのかな
サービス アカウント トークン作成者（roles/iam.serviceAccountTokenCreator）: 認証に使用できるように OAuth 2.0 アクセス トークンの作成、JSON Web Token（JWT）への署名、バイナリ blob への署名をサービス アカウントとして行うことをメンバーに許可します
なのでなんかやったらできそう
あるサービスアカウントを利用するには
サービスアカウントユーザー/トークン作成者になって間接的に使う
サービスアカウントのキーを発行して使う
の2つで、大抵後者が紹介される
code:curl
$ curl -X POST \
-H "Authorization: Bearer "$(gcloud auth application-default print-access-token) \
-H "Content-Type: application/json; charset=utf-8" \
で取れる、期限が短いのでよさそうだけど、ロールを作業者に付与するのがちょっとめんどい
メンテナンス不要期間
毎月末を指定したらいいかと思ったけど年に1回使えるスペシャル技のような扱いだった