GCP の Application Default Credentials を使った認証 - ぽ靴な缶
公式ドキュメントで説明されているけど、同僚に何度か説明する機会があったり、作る必要のないサービスアカウントキーを目にすることも多いのでまとめておく。 認証情報が登場しないアプリケーションコード 例えば以下のコードで Secret Manager に保存したトークンを取得することができる。SecretManagerServiceClient にサービスアカウントキーを渡さずとも動作する。 const {SecretManagerServiceClient} = require('@google-cloud/secret-manager'); const client = new SecretManagerServiceClient(); (async () => { const [secret] = await client.accessSecretVersion({ name: 'proj
GCP の Compute Metadata Credentials について
Google Cloud Platform(以降 GCP) の認証認可については GCP と OAuth2 などの記事があるが、 Compute Metadata credential そのものの解説はあまり十分にされているとは言えないので、今回一つの記事で説明する。 Compute Metadata Credentials と聞いてもピンと来ない人向けに書くと、「Cloud Run や Cloud Functions などの GCP のプロダクトから GCP の API を呼ぶのにサービスアカウントキーが必要ないこと」の裏側がどのように動いているかの話について説明する記事である。 Compute Metadata Credentials とは Compute Metadata Credentials は Google Cloud Platform(以降 GCP) の標準の credent
今日からやれる(ケースもある)BeyondCorp Remote Access - Qiita
2020年4月21日(このpost書いた日)、こちらのニュースでリモートワークを導入する企業向けのソリューションであるBeyondCorp Remote Accessが紹介されました。 Keep your teams working safely with BeyondCorp Remote Access | Google Cloud Blog このpostでは、主に非GCP環境で社内NWに対して業務用のアプリケーションを配信している企業を想定してBeyondCorp Remote Accessを紹介していきます(GCP上でホストされたアプリケーションについてはやるだけ感が強いので) 時間がない人向け 誰がBeyondCorp Remote Accessを採用すべきか かなりざっくりした軸としては「既に何らかのソリューションがあるかどうか」という点が最初にあると思います VPNも何もなく、
GAE 2nd-gen でのサービス間認証
TL;DRGAE 2nd-gen では X-Appengine-Inbound-Appid ヘッダの代わりに、ID Token + Identity-Aware Proxy を使った方式をサービス間認証に使えます。 はじめにGAE でマイクロサービスを構成する場合、各サービス同士を呼び合うときに同一 GAE アプリからのリクエストであるかを確認したい場面があります。シンプルな例だと、サービスがフロントエンドとバックエンドに別れていて、バックエンドはフロントエンドからしか呼び出せないようにしたい場合です。 GAE 1st-gen では X-Appengine-Inbound-Appid ヘッダという魔法のヘッダがありました。このヘッダは URLFetch を使用して別の GAE サービスにアクセスする時に、GCP が自動で呼び出し元の Project ID を入れてくれるヘッダです。そのため
GCP からの HTTP リクエストをセキュアに認証する
はじめにGCP にはあらかじめ HTTP のエンドポイントを登録しておくと、そこに対して HTTP リクエストが送られてくるようなプロダクトがいくつか存在します。 Cloud Pub/SubCloud TasksCloud Schedulerどれも非同期系の処理を行うプロダクトであり、非同期処理を行う Worker を HTTP の Web サーバとして記述できるのが大きなメリットになっています。 しかしそれらの Web サーバはパプリックなエンドポイントとして用意することも多いことから、送られてきた HTTP リクエストが本当に GCP の特定のプロダクトから送られてきたものなのか？という「認証」をどうやるかが長らく問題になっていました。 既存のやり方としては Web サーバの実装方式によっていくつかありますが、 App Engine (1st gen) を使う場合: “login: a
GCP と OAuth2
はじめにGCP のサービスにプログラムからアクセスするためには必ず認証・認可が必要ですが、以下のような様々なコマンドや概念が出てくるので少しとっつきにくい印象があります。 gcloud auth logingcloud auth application-default loginService AccountApplication Default Credentialsこれらの概念は認証・認可のベースとなっている OAuth2 の文脈で眺めてみると全体像が理解しやすくなるので、本記事でまとめてみたいと思います。 GCP での認証・認可GCP の認証・認可は一部(*)を除いて全て OAuth2 ベースでやり取りされています。(* API Key) OAuth2 は三者間の手続きです。 3-Legged OAuth2Client が Resource Owner の代わりに Resource
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
