GSP844

概要

Apigee は API の開発と管理を行うためのプラットフォームです。Apigee では、API へのアクセスを保護し、アクセスのレート制限を行うことができます。また、API データへの内部アクセスを保護するための機能も備わっています。

このラボでは、アクセスに対して OAuth トークンを要求する API を作成します。SpikeArrest ポリシーを使用してアプリケーション別に API 呼び出しのレートを制限し、プライベート変数とデータ マスキングを使用して、API トラフィックをデバッグするユーザーに機密データが表示されないようにします。

目標

このラボでは、次のタスクの実行方法について学びます。

• OAuth トークンを要求して API へのアクセスを保護する
• SpikeArrest ポリシーを使用して、全体的なトラフィック レートとアプリケーション別のレートを制限する
• プライベート変数とデータ マスキングを使用して、API 呼び出しのデバッグ中に機密データを非表示にする
• バックエンドへの呼び出しを指定したリソースに制限する
• データ漏洩を防ぐためにバックエンドのエラー メッセージを書き換える

設定と要件

[ラボを開始] ボタンをクリックする前に

こちらの説明をお読みください。ラボには時間制限があり、一時停止することはできません。タイマーは、Google Cloud のリソースを利用できる時間を示しており、[ラボを開始] をクリックするとスタートします。

このハンズオンラボでは、シミュレーションやデモ環境ではなく実際のクラウド環境を使って、ラボのアクティビティを行います。そのため、ラボの受講中に Google Cloud にログインおよびアクセスするための、新しい一時的な認証情報が提供されます。

このラボを完了するためには、下記が必要です。

• 標準的なインターネット ブラウザ（Chrome を推奨）

注: このラボの実行には、シークレット モード（推奨）またはシークレット ブラウジング ウィンドウを使用してください。これにより、個人アカウントと受講者アカウント間の競合を防ぎ、個人アカウントに追加料金が発生しないようにすることができます。

• ラボを完了するための時間（開始後は一時停止できません）

注: このラボでは、受講者アカウントのみを使用してください。別の Google Cloud アカウントを使用すると、そのアカウントに料金が発生する可能性があります。 注: このラボを実施する際には、新しいシークレット ウィンドウを使用することをおすすめします。

ラボを開始して Google Cloud コンソールにログインする方法

1. [ラボを開始] ボタンをクリックします。ラボの料金をお支払いいただく必要がある場合は、表示されるダイアログでお支払い方法を選択してください。 左側の [ラボの詳細] ペインには、以下が表示されます。

   • [Google Cloud コンソールを開く] ボタン
   • 残り時間
   • このラボで使用する必要がある一時的な認証情報
   • このラボを行うために必要なその他の情報（ある場合）

2. [Google Cloud コンソールを開く] をクリックします（Chrome ブラウザを使用している場合は、右クリックして [シークレット ウィンドウで開く] を選択します）。

   ラボでリソースがスピンアップし、別のタブで [ログイン] ページが表示されます。

   ヒント: タブをそれぞれ別のウィンドウで開き、並べて表示しておきましょう。

   注: [アカウントの選択] ダイアログが表示されたら、[別のアカウントを使用] をクリックします。

3. 必要に応じて、下のユーザー名をコピーして、[ログイン] ダイアログに貼り付けます。

   {{{user_0.username | "Username"}}}

   [ラボの詳細] ペインでもユーザー名を確認できます。

4. [次へ] をクリックします。

5. 以下のパスワードをコピーして、[ようこそ] ダイアログに貼り付けます。

   {{{user_0.password | "Password"}}}

   [ラボの詳細] ペインでもパスワードを確認できます。

6. [次へ] をクリックします。

   重要: ラボで提供された認証情報を使用する必要があります。Google Cloud アカウントの認証情報は使用しないでください。 注: このラボでご自身の Google Cloud アカウントを使用すると、追加料金が発生する場合があります。

7. その後次のように進みます。

   • 利用規約に同意してください。
   • 一時的なアカウントなので、復元オプションや 2 要素認証プロセスは設定しないでください。
   • 無料トライアルには登録しないでください。

その後、このタブで Google Cloud コンソールが開きます。

注: Google Cloud のプロダクトやサービスにアクセスするには、ナビゲーション メニューをクリックするか、[検索] フィールドにサービス名またはプロダクト名を入力します。

Cloud Shell をアクティブにする

Cloud Shell は、開発ツールと一緒に読み込まれる仮想マシンです。5 GB の永続ホーム ディレクトリが用意されており、Google Cloud で稼働します。Cloud Shell を使用すると、コマンドラインで Google Cloud リソースにアクセスできます。

1. Google Cloud コンソールの上部にある「Cloud Shell をアクティブにする」アイコン をクリックします。

2. ウィンドウで次の操作を行います。

   • Cloud Shell 情報ウィンドウで操作を進めます。
   • Cloud Shell が認証情報を使用して Google Cloud API を呼び出すことを承認します。

接続した時点で認証が完了しており、プロジェクトに各自の Project_ID、 が設定されます。出力には、このセッションの PROJECT_ID を宣言する次の行が含まれています。

Your Cloud Platform project in this session is set to {{{project_0.project_id | "PROJECT_ID"}}}

gcloud は Google Cloud のコマンドライン ツールです。このツールは、Cloud Shell にプリインストールされており、タブ補完がサポートされています。

3. （省略可）次のコマンドを使用すると、有効なアカウント名を一覧表示できます。

gcloud auth list

4. [承認] をクリックします。

出力:

ACTIVE: * ACCOUNT: {{{user_0.username | "ACCOUNT"}}} To set the active account, run: $ gcloud config set account `ACCOUNT`

5. （省略可）次のコマンドを使用すると、プロジェクト ID を一覧表示できます。

gcloud config list project

出力:

[core] project = {{{project_0.project_id | "PROJECT_ID"}}} 注: Google Cloud における gcloud ドキュメントの全文については、gcloud CLI の概要ガイドをご覧ください。

Apigee コンソールを開く

Apigee コンソールを開くには、次の手順に沿って操作します。

• Google Cloud コンソールの [検索] フィールドに「Apigee」と入力し、検索結果で [Apigee API Management] をクリックします。

Apigee コンソールが開き、よく使用される場所へのクイックリンクがランディング ページに表示されます。

• ナビゲーション メニュー（）で、[Apigee] の横にある [固定]（）をクリックします。

Apigee がナビゲーション メニューに固定されます。

タスク 1. Apigee API プロキシを使用してバックエンド サービスをプロキシする

このタスクでは、バックエンド サービスのファサードとして機能する Apigee API プロキシを作成します。API プロキシでは、サービス アカウントを使用して、Cloud Run サービスに OpenID Connect ID トークンを提示できるようにします。

simplebank-rest という名前のバックエンド サービスがすでに作成され、Cloud Run にデプロイされています。サービス アカウントもすでに作成されています。

Apigee プロキシを作成する

1. Cloud Shell で、バックエンド サービスの URL を取得するために次のコマンドを実行します。

   gcloud run services describe simplebank-rest --platform managed --region {{{project_0.default_region |REGION}}} --format 'value(status.url)'

   API プロキシを作成する際に使用するため、この URL を保存します。

2. Cloud コンソールで Apigee UI に移動します。

3. 左側のナビゲーション メニューで、[プロキシ開発] > [API プロキシ] を選択します。

4. プロキシ ウィザードを使用して新しいプロキシを作成するには、[+Create] をクリックします。

   バックエンド サービスのリバース プロキシを作成します。この API プロキシは、OpenAPI 仕様を使用して API のスケルトンを作成します。

5. [Proxy template] ボックスの [OpenAPI spec template] で、[Reverse proxy (Most common)] を選択します。

6. OpenAPI ファイルの場合は、ブラウザで URL を開くと、OpenAPI 仕様 YAML ファイルがパソコンにダウンロードされます。

   https://storage.googleapis.com/cloud-training/api-dev-quest/simplebank-backend.yaml

7. [参照] をクリックし、パソコンから [OpenAPI ファイル] を選択して [次へ] をクリックします。

8. [Proxy details] で次のように指定します。

   プロパティ	値
   Proxy name	bank-v1
   Base path	/bank/v1
   Description	SimpleBank read-only API
   Target (Existing API)	バックエンド URL

   注: [Base path] には /bank-v1 ではなく /bank/v1 を使用していることを確認してください。

   ターゲットには、このタスクですでに取得したバックエンド URL を指定する必要があります。ターゲットは、次のようになります。

   https://simplebank-rest-nu7rb74j5a-uw.a.run.app

9. [次へ] をクリックします。

10. [Flows(Optional)] で、すべての GET オペレーションを選択し、[次へ] をクリックします。

11. その他の設定はデフォルトのままにして、[Create] をクリックします。

12. [Develop] タブをクリックします。

    注: フローがプロキシ エンドポイントに追加されています。各フローは、OpenAPI 仕様に記載されているいずれかのオペレーションの、動詞とパスの条件を指定しています。

OpenID Connect の ID トークンを送信するようにターゲットを変更する

バックエンド サービスは認証アクセスを必要とするようにデプロイされているため、有効な OpenID Connect の ID トークンがなければサービスを呼び出すことができません。

HTTPTargetConnection でサービスのバックエンド ターゲットを指定します。

1. プロキシの [Navigator] メニューで、[Target Endpoints] セクションの [PreFlow] をクリックします。

2. 次のコードを探します（URL は異なります）。

   <HTTPTargetConnection> <URL>https://simplebank-rest-zce6j3rjwq-uw.a.run.app</URL> </HTTPTargetConnection> 注: [HTTPTargetConnection] セクションが見つからない場合は、[Proxy Endpoints] セクションではなく [Target Endpoints] セクションの [PreFlow] をクリックしたことを確認してください。

3. URL の下に、次のような Authentication セクションを追加します。

   <Authentication> <GoogleIDToken> <Audience>AUDIENCE</Audience> </GoogleIDToken> </Authentication>

4. AUDIENCE は、HTTPTargetConnection セクションにすでにある URL 値に置き換えます。コードは、URL 要素と Audience 要素の独自の URL を除いて、次のようになります。

   <TargetEndpoint name="default"> <PreFlow name="PreFlow"> <Request/> <Response/> </PreFlow> <Flows/> <PostFlow name="PostFlow"> <Request/> <Response/> </PostFlow> <HTTPTargetConnection> <URL>https://simplebank-rest-zce6j3rjwq-uw.a.run.app</URL> <Authentication> <GoogleIDToken> <Audience>https://simplebank-rest-zce6j3rjwq-uw.a.run.app</Audience> </GoogleIDToken> </Authentication> </HTTPTargetConnection> </TargetEndpoint>

5. [Save] をクリックします。

[進行状況を確認] をクリックして、目標に沿って進んでいることを確認します。 API プロキシを作成する

タスク 2. API プロキシに OAuth を追加する

このタスクでは、OAuthV2 ポリシーを API プロキシに追加します。VerifyJWTAccessToken オペレーションを使用する OAuthV2 ポリシーは、実行時にアクセス トークンの検証を強制的に適用して、有効な OAuth アクセス トークンを持つアプリケーションのみが API にアクセスできるようにします。

OAuthV2 ポリシーでは、opaque トークンと JSON ウェブトークン（JWT）の両方を作成して検証できます。この API プロキシは、アクセス トークンに JWT を使用します。

プロパティ セットに、JWT を作成および検証する際に使用される署名シークレットが格納されます。

プロパティ セットで署名シークレットを作成する

JWT の署名には、ハッシュベースのメッセージ認証コード（HMAC）が使用されます。この種の暗号署名にはシークレットが必要です。

1. プロキシの [Navigator] メニューで、[Resources] の横にある [+] をクリックします。

2. [Resource Type] のプルダウンで [Property Set] を選択します。

3. [Resource Name] に oauth.properties を指定して、[Add] をクリックします。

4. oauth.properties コードペインで、次のプロパティを追加します。

   secret=thisisnotagoodsecret,useabettersecretinproduction

   フロー変数 propertyset.oauth.secret を使用して、コード内でこの値にアクセスできます。

   注: プロパティ セット値は平文で保存されます。本番環境では、暗号化された場所に HMAC シークレットを保存することをおすすめします。また、より安全な（ランダムな）シークレットを使用してください。

AssignMessage ポリシーを追加してプロパティ セット値を取得する

署名シークレットはプライベート変数に入れて OAuth ポリシーに提供する必要がありますが、propertyset.oauth.secret 変数はプライベートではありません。この AssignMessage ポリシーは、プロパティ セット変数からプライベート変数を作成します。

1. プロキシの [Navigator] メニューで、[Proxy Endpoints] セクションの [default] の下にある [PreFlow] をクリックします。

   デフォルトのプロキシ エンドポイントのリクエスト PreFlow が、API プロキシにリクエストが届いたときに最初に実行されるフローです。

   OAuthV2 ポリシーはシークレットを必要とし、API プロキシで非常に早い段階で実行されます。

2. [Flow] ペインで、リクエスト フローの [PreFlow] のすぐ横にある [+] ボタンをクリックします。

3. [Create new Policy] を選択し、[Select policy] プルダウンで [Mediation] セクションの [Assign Message] を選択し、[Display Name] と [Name] を AM-GetSecret に設定します。

4. [Add] をクリックします。ナビゲーション メニューの [Policies] で [AM-GetSecret] をクリックします。

   AssignMessage ポリシー構成が [Code] ペインに表示されます。

5. ポリシー構成を次のように変更します。

   <AssignMessage name="AM-GetSecret"> <AssignVariable> <Name>private.secretkey</Name> <Ref>propertyset.oauth.secret</Ref> </AssignVariable> <IgnoreUnresolvedVariables>false</IgnoreUnresolvedVariables> </AssignMessage>

   AssignVariable 設定により、propertyset.oauth.secret 変数が private.secretkey 変数にコピーされます。

   propertyset.oauth.secret が解決できない場合は、IgnoreUnresolvedVariables 設定により AssignMessage ポリシーからエラーが生成されます。

OAuthV2 ポリシーを追加してトークンを検証する

1. プロキシの [Navigator] メニューで、[Proxy Endpoints] セクションの [default] の下にある [PreFlow] をクリックします。

   OAuthV2 ポリシーは AssignMessage ポリシーより後に実行する必要があります。

2. [Flow] ペインで、リクエスト フローの [PreFlow] のすぐ横にある [+] ボタンをクリックします。

3. [Create new policy] を選択し、[Select policy] プルダウンで [Security] セクションの [OAuth v2.0] を選択し、[Display Name] と [Name] を OA-VerifyToken に設定します。

4. [Add] をクリックし、ナビゲーター メニューの [Policies] から [OA-VerifyToken] をクリックします。

   OAuthV2 ポリシー構成が [Code] ペインに表示されます。

5. OAuthV2 ポリシー構成を次のように変更します。

   <OAuthV2 name="OA-VerifyToken"> <Operation>VerifyJWTAccessToken</Operation> <Algorithm>HS256</Algorithm> <SecretKey> <Value ref="private.secretkey"/> </SecretKey> </OAuthV2>

   この構成は、JWT アクセス トークンが HS256（HMAC-SHA256）アルゴリズムを使用し、AssignMessage ポリシーで作成されたプライベート変数をシークレット キーとして使用することを指定します。

6. [Save] をクリックします。

[進行状況を確認] をクリックして、目標に沿って進んでいることを確認します。 ポリシーを追加してトークンを検証する

タスク 3. トークンを生成するためのポリシーを追加する

ここではさらに、JWT トークンの作成を許可するために独立したプロキシ エンドポイントを API プロキシに追加します。

トークン オペレーションのために新しいプロキシ エンドポイントを追加する

本番環境では通常、トークンを生成するために別個のプロキシが作成されます。このラボでは、同じ API プロキシ内の別のプロキシ エンドポイントにトークン生成フローを作成します。

1. プロキシの [Navigator] メニューで、[Proxy Endpoints] 行の [+] ボタンをクリックします。

   注: [default] の隣にある [+] ボタンはクリックしないでください。

   新しい JWT の作成時に使用される新しいプロキシ エンドポイントが作成されます。

2. [Name] に「token」と指定し、[Add] をクリックします。

   token という名前の新しいプロキシ エンドポイントが [Code] ペインに表示されます。

3. token フロー構成全体を変更します。元の構成は次のようになっています。

   <ProxyEndpoint name="token"> . . . </ProxyEndpoint>

   これを、次のように変更します。

   <ProxyEndpoint name="token"> <PreFlow name="PreFlow"> <Request/> <Response/> </PreFlow> <PostFlow name="PostFlow"> <Request/> <Response/> </PostFlow> <Flows/> <HTTPProxyConnection> <BasePath>/token</BasePath> </HTTPProxyConnection> <RouteRule name="noTarget"/> </ProxyEndpoint>

4. [Save] をクリックします。

   更新されたこの構成により、次の 2 つの変更が行われます。

   • BasePath が /token に設定されます。これが、トークンの作成時に使用されるベースパスです。
   • RouteRule がターゲット エンドポイントを参照しなくなります。API プロキシは、バックエンド サービスを呼び出さずにトークンを作成します。

トークンの生成フローを作成する

1. プロキシのフローで、[Proxy Endpoints: token] セクションの [/token] のすぐ横にある [+] をクリックします。

2. 新しい条件フローに、次の値を指定します。

   プロパティ	値
   Flow Name	generateToken
   Condition Type	[Custom] を選択

3. [Condition] で、次の値を指定します。

   (proxy.pathsuffix MatchesPath "/") and (request.verb = "POST") and (request.formparam.grant_type = "client_credentials")

   有効なクライアント認証情報トークン リクエストのみが許可されます。

4. [Add] をクリックします。

AssignMessage ポリシーを接続して、プロパティ セット値を取得する

トークンを生成する OAuthV2 ポリシーは、private.secretkey 変数へのアクセスも必要とします。

1. プロキシの [Navigator] メニューで、[Proxy Endpoints] セクションの [token] の下にある [generateToken] をクリックします。

2. [Flow] ペインで、リクエスト フローの [generateToken] の横にある右側の [+] ボタンをクリックします。

3. [Select Policy] で [Select Existing policy] を選択し、[AM-GetSecret] をクリックします。

4. [Add] をクリックします。

   同じ AssignMessage ポリシーがトークン プロキシ エンドポイント PreFlow に接続されます。

トークンを生成するための OAuthV2 ポリシーを追加する

1. プロキシの [Navigator] メニューで、[Proxy Endpoints] セクションの [token] の下にある [generateToken] をクリックします。

2. [Flow] ペインで、リクエスト フローの [generateToken] の横にある右側の [+] ボタンをクリックします。

3. [Select Policy] で [Create new policy] を選択し、[Security] セクションで [OAuth v2.0] を選択した後、[Display Name] と [Name] を OA-GenerateToken に設定します。

4. [Add] をクリックし、[Policies] から [OA-GenerateToken] をクリックします。

   OAuthV2 ポリシー構成が [Code] ペインに表示されます。

5. OAuthV2 ポリシー構成を次のように変更します。

   <OAuthV2 name="OA-GenerateToken"> <Operation>GenerateJWTAccessToken</Operation> <Algorithm>HS256</Algorithm> <SecretKey> <Value ref="private.secretkey"/> </SecretKey> <SupportedGrantTypes> <!-- 基本認証ヘッダーを使用して client_id と client_secret を渡す --> <GrantType>client_credentials</GrantType> </SupportedGrantTypes> <!-- 1,800,000 ミリ秒 = 1,800 秒 = 30 分 --> <ExpiresIn>1800000</ExpiresIn> <GenerateResponse enabled="true"/> <RFCCompliantRequestResponse>true</RFCCompliantRequestResponse> </OAuthV2>

   この構成によって、30 分間で有効期限が切れる JWT OAuth トークンを作成できるようになります。

無効なトークン リクエストに対してエラーを生成する

1. プロキシのフローで、[Proxy Endpoints: token] セクションの [/token] のすぐ横にある [+] をクリックします。

2. 新しい条件フローに、次の値を指定します。

   プロパティ	値
   Flow Name	invalidRequest
   Condition Type	[Custom] を選択
   Condition	DELETETHIS

   無効な generateToken リクエストはすべてこのフローを通過する必要があるため、フローが追加されると条件が削除されます。

3. [Add] をクリックします。

4. invalidRequest フローで、次の行を削除します。

   <Condition>DELETETHIS</Condition>

5. プロキシの [Navigator] メニューで、[Proxy Endpoints] セクションの [token] の下にある [invalidRequest] をクリックします。

6. [Flow] ペインで、リクエスト フローの [invalidRequest] のすぐ横にある [+] ボタンをクリックします。

7. [Create new policy] を選択し、[Mediation] セクションで [Raise Fault] を選択した後、[Display Name] と [Name] を RF-InvalidTokenRequest に設定します。

8. [Add] をクリックし、[Policies] から [RF-InvalidTokenRequest] をクリックします。

   RaiseFault ポリシー構成が [Code] ペインに表示されます。

9. RaiseFault ポリシー構成を次のように変更します。

   <RaiseFault name="RF-InvalidTokenRequest"> <FaultResponse> <Set> <StatusCode>400</StatusCode> <ReasonPhrase>Bad Request</ReasonPhrase> <Payload contentType="application/json">{ "error":"Bad request: use POST /token" }</Payload> </Set> </FaultResponse> <IgnoreUnresolvedVariables>true</IgnoreUnresolvedVariables> </RaiseFault>

   この変更により、リクエストが無効だった場合に 400 Bad Request レスポンスが返されるようになります。

10. [Save] をクリックします。

[進行状況を確認] をクリックして、目標に沿って進んでいることを確認します。 トークンを生成するためのポリシーを追加する

タスク 4. OAuth プロキシをデプロイする

このタスクでは、API プロキシをデプロイして、アクセスの際に OAuth トークンが要求されるようにします。

ランタイム インスタンスが使用可能であることを確認する

1. Cloud Shell で、次のコマンドセットを貼り付けて実行します。

   export INSTANCE_NAME=eval-instance; export ENV_NAME=eval; export PREV_INSTANCE_STATE=; echo "waiting for runtime instance ${INSTANCE_NAME} to be active"; while : ; do export INSTANCE_STATE=$(curl -s -H "Authorization: Bearer $(gcloud auth print-access-token)" -X GET "https://apigee.googleapis.com/v1/organizations/${GOOGLE_CLOUD_PROJECT}/instances/${INSTANCE_NAME}" | jq "select(.state != null) | .state" --raw-output); [[ "${INSTANCE_STATE}" == "${PREV_INSTANCE_STATE}" ]] || (echo; echo "INSTANCE_STATE=${INSTANCE_STATE}"); export PREV_INSTANCE_STATE=${INSTANCE_STATE}; [[ "${INSTANCE_STATE}" != "ACTIVE" ]] || break; echo -n "."; sleep 5; done; echo; echo "instance created, waiting for environment ${ENV_NAME} to be attached to instance"; while : ; do export ATTACHMENT_DONE=$(curl -s -H "Authorization: Bearer $(gcloud auth print-access-token)" -X GET "https://apigee.googleapis.com/v1/organizations/${GOOGLE_CLOUD_PROJECT}/instances/${INSTANCE_NAME}/attachments" | jq "select(.attachments != null) | .attachments[] | select(.environment == \"${ENV_NAME}\") | .environment" --join-output); [[ "${ATTACHMENT_DONE}" != "${ENV_NAME}" ]] || break; echo -n "."; sleep 5; done; echo "***ORG IS READY TO USE***";

   この一連のコマンドでは、Apigee API を使用して、Apigee ランタイム インスタンスが作成されて eval 環境がアタッチされたことを確認します。

2. インスタンスが使用可能になるまで待ちます。

   ***ORG IS READY TO USE*** というテキストが表示されたら、インスタンスは使用可能です。ラボを開始する前にすでに Apigee 組織が作成されていることがあります。その場合はインスタンスが作成されるまで待つ必要はありません。

   組織の準備が整うまで待つ場合は、その間に、OAuth、SpikeArrest ポリシー、データのマスキングと非表示、opaque トークンと JWT の詳細をご覧ください。

API プロキシをデプロイする

1. Cloud コンソールで Apigee に移動します。

2. 左側のナビゲーション メニューで、[プロキシ開発] > [API プロキシ] を選択し、[bank-v1] をクリックします。

3. [Develop] タブをクリックします。

4. [Deploy] をクリックし、[Environment] で [eval] を選択します。

   デプロイの確認を求めるダイアログが表示されます。

5. [Service Account] に、サービス アカウントのメールアドレスを指定します。

   apigee-internal-access@{{{ project_0.project_id | PROJECT }}}.iam.gserviceaccount.com

6. [Deploy]、[Confirm] の順にクリックします。

7. [Overview] タブをクリックして eval のデプロイ ステータスを確認し、プロキシがデプロイされたと示されるまで待ちます。

[進行状況を確認] をクリックして、目標に沿って進んでいることを確認します。 API プロキシをデプロイする

API プロキシをテストする

Apigee 組織の eval 環境は、eval.example.com というホスト名を使用して呼び出すことができます。このホスト名を Apigee ランタイム インスタンスの IP アドレスに解決する DNS エントリは、すでにプロジェクト内に作成されています。この DNS エントリは限定公開ゾーンに作成されているため、内部ネットワーク上でのみ表示されます。

Cloud Shell は内部ネットワークに存在しないため、Cloud Shell コマンドではこの DNS エントリを解決できません。組織内の仮想マシン（VM）であれば限定公開ゾーンの DNS にアクセスでき、apigeex-test-vm という名前の VM が自動的に作成されています。このマシンを使用して API プロキシを呼び出すことができます。

1. Cloud Shell で、テスト VM への SSH 接続を開きます。

   TEST_VM_ZONE=$(gcloud compute instances list --filter="name=('apigeex-test-vm')" --format "value(zone)") gcloud compute ssh apigeex-test-vm --zone=${TEST_VM_ZONE} --force-key-file-overwrite

   承認するよう求められた場合は、[承認] をクリックします。

2. Cloud Shell で確認されるすべての項目について、Enter キーまたは Return キーを押して、デフォルトの入力を指定します。

   プロジェクトのオーナーとしてログインしているため、このマシンへの SSH は許可されます。

   これで、Cloud Shell セッションが VM 内で実行できるようになります。

3. eval 環境にデプロイした bank-v1 API プロキシを呼び出します。

   curl -i -k -X GET "https://eval.example.com/bank/v1/customers"

   -k オプションを指定すると、curl は TLS 証明書の検証をスキップします。このラボの Apigee ランタイムでは、信頼できる認証局（CA）によって作成された証明書ではなく、自己署名証明書を使用します。

   注: 本番環境のユースケースでは、-k オプションを使用して証明書の検証を省略することは避けてください。

   この API は、顧客リストを取得しようとします。次のような 401 Unauthorized レスポンスが表示されます。

   HTTP/2 401 content-type: application/json www-authenticate: Bearer realm="null",error="invalid_token",error_description="oauth.v2.InvalidAccessToken: Invalid access token" x-request-id: 99263881-d0f7-4495-b886-0253f28a2e05 content-length: 101 date: Tue, 11 Jan 2022 18:59:01 GMT via: 1.1 google {"fault":{"faultstring":"Invalid access token","detail":{"errorcode":"oauth.v2.InvalidAccessToken"}}}

   このレスポンスは、アクセス トークンが提供されなかったためにバックエンド サービスへのアクセスが API プロキシによってブロックされたことを示しています。

4. コマンド exit を入力して SSH セッションを終了し、Cloud Shell に戻ります。

タスク 5. API プロダクト、デベロッパー、アプリケーションを追加する

このタスクでは、API へのアクセスを提供する API プロダクトを追加します。また、デベロッパーと、API プロダクトに関連付けるアプリケーションも作成します。

API プロダクトを作成する

1. Cloud コンソールで Apigee に移動します。

2. ナビゲーション メニューで、[配布] > [API プロダクト] を選択します。

3. 新しい API プロダクトを作成するには、[+Create] をクリックします。

4. [Product details] ペインで、以下を指定します。

   プロパティ	値
   Name	bank-readonly
   Display Name	bank (read access)
   Environment	[eval] を選択
   Access	[Public] を選択

   [Automatically approve access requests] は選択したままにします。

5. [Operations] セクションで、[+Add an Operation] をクリックします。

   オペレーションは、API プロダクトに関連付けられているアプリケーションに対してどの API プロキシのどのリクエストを許可するかを指定するために使用されます。

   注: ボタンが [GraphQL Operations] セクションではなく [Operations] セクションにあることを確認します。

6. 以下を指定します。

   プロパティ	値
   API Proxy	bank-v1 API プロキシを選択
   Path	/**
   Methods	GET を選択

   パス式 /\*\* は、ベースパスに一致するすべてのリクエストが許可されることを示します。

   本番環境では、このワイルドカード パス式を使用せずに、許可する各オペレーションを個別に追加することもできます。

7. [Save] をクリックして、オペレーションを保存します。

8. API プロダクトを保存するには、[Products Detail] ページの上部で [Save] をクリックします。

9. [配布] > [API プロダクト] ページに戻ります。

   API プロダクトがリストに表示されます。

アプリ デベロッパーを作成する

アプリを作成する前に、アプリ デベロッパーを作成する必要があります。

1. 左側のナビゲーション メニューで [配布] > [デベロッパー] をクリックします。

2. 新しいアプリ デベロッパーを作成するには、[+Create] をクリックします。

3. 以下を指定します。

   プロパティ	値
   First Name	Joe
   Last Name	Developer
   Username	joe
   Email	joe@example.com

4. [Add] をクリックしてアプリ デベロッパーを作成します。

bank-v1 アクセス権を持つアプリを作成する

1. 左側のナビゲーション メニューで [配布] > [アプリ] をクリックします。

2. 新しいアプリを作成するには、[+Create] をクリックします。

3. [App details] ペインで、以下を指定します。

   プロパティ	値
   Name	readonly-app
   Developer	joe@example.com を選択

4. [Credentials] ペインで、[Add credentials > Add products] をクリックし、プルダウンから [bank (read access)] を選択し、[Add] をクリックして追加します。

5. 右上の [Create] をクリックしてアプリを作成します。

   これで、アプリのキーとシークレットが構成されました。

6. [Key] と [Secret] の隣にある [Show] アイコンをクリックします。

   この API には OAuth アクセス トークンが必要です。キーとシークレットは、アプリに OAuth アクセス トークンの作成を許可する、アプリの認証情報として使用されます。

[進行状況を確認] をクリックして、目標に沿って進んでいることを確認します。 API プロダクトを追加してアプリを作成する

API をテストする

1. Cloud Shell で、テスト VM への SSH 接続を開きます。

   TEST_VM_ZONE=$(gcloud compute instances list --filter="name=('apigeex-test-vm')" --format "value(zone)") gcloud compute ssh apigeex-test-vm --zone=${TEST_VM_ZONE} --force-key-file-overwrite

   承認するよう求められた場合は、[承認] をクリックします。

   これで、Cloud Shell セッションが VM 内で実行されます。

2. アプリケーションのコンシューマ キーとシークレットを取得するには、次のコマンドを実行します。

   export PROJECT_ID=$(gcloud config list --format 'value(core.project)' 2>/dev/null); echo "PROJECT_ID=${PROJECT_ID}" export CONSUMER_KEY=$(curl -s -H "Authorization: Bearer $(gcloud auth print-access-token)" -X GET "https://apigee.googleapis.com/v1/organizations/${PROJECT_ID}/developers/joe@example.com/apps/readonly-app" | jq ".credentials[0].consumerKey" --raw-output); echo "CONSUMER_KEY=${CONSUMER_KEY}" export CONSUMER_SECRET=$(curl -s -H "Authorization: Bearer $(gcloud auth print-access-token)" -X GET "https://apigee.googleapis.com/v1/organizations/${PROJECT_ID}/developers/joe@example.com/apps/readonly-app" | jq ".credentials[0].consumerSecret" --raw-output); echo "CONSUMER_SECRET=${CONSUMER_SECRET}"

   最初のコマンドでは、gcloud 構成を読み取って現在のプロジェクトを取得します。2 番目と 3 番目のコマンドは、Apigee API を使用してコンシューマ キーとシークレットを取得します。ログインしているユーザーのアクセス許可を持つアクセス トークンを送信するため、リクエストは承認されます。

   OAuth クライアント認証情報付与タイプの場合は、アクセス トークンを生成するために、クライアント アプリケーションが Authorization ヘッダーでコンシューマ キーとシークレットを送信する必要があります。

3. JWT アクセス トークンを生成するには、次のコマンドを実行します。

   export TOKEN_RESPONSE=$(curl -k -u "${CONSUMER_KEY}:${CONSUMER_SECRET}" -X POST "https://eval.example.com/token" -H "Content-Type: application/x-www-form-urlencoded" -d "grant_type=client_credentials"); echo ${TOKEN_RESPONSE} export JWT_TOKEN=$(echo ${TOKEN_RESPONSE} | jq ".access_token" --raw-output); echo "JWT_TOKEN=${JWT_TOKEN}"

   最初のコマンドは、トークン エンドポイントを呼び出して、そのレスポンスを保存します。トークンは JSON レスポンスから抽出されて、JWT_TOKEN に保存されます。

4. JWT トークンを使用してリクエストをテストするには、次のコマンドを使用します。

   curl -i -k -H "Authorization: Bearer ${JWT_TOKEN}" -X GET "https://eval.example.com/bank/v1/customers"

   API 呼び出しから顧客のリストが返されます。

   注: 「Your client does not have permission to the requested URL」というレスポンスを受け取った場合は、タスク 1 で Audience を正しく設定したことを確認してください。

5. コマンド exit を入力して SSH セッションを終了し、Cloud Shell に戻ります。

タスク 6. レート制限を追加する

このタスクでは、API プロダクトの割り当て構成を使用する SpikeArrest ポリシーを追加して、API 呼び出しのレートを制限します。

SpikeArrest ポリシーで、許可される最大トラフィック レートを指定することによって、トラフィックの急増から API とバックエンドを保護します。このポリシーによって、処理しきれないほど大量のトラフィックがバックエンドに到達するのを防ぐことができます。

トークン生成のために SpikeArrest ポリシーを追加する

この SpikeArrest ポリシーは、/token API への呼び出しのトラフィックに対する全般的なレート制限を指定します。

1. Cloud コンソールで Apigee に移動します。

2. 左側のナビゲーション メニューで、[プロキシ開発] > [API プロキシ] を選択し、[bank-v1] をクリックします。

3. [Develop] タブをクリックします。

4. プロキシの [Navigator] メニューで、[Proxy Endpoints] セクションの [token] の下にある [PreFlow] をクリックします。

   SpikeArrest ポリシーは、条件フローポリシーより前に実行される必要があります。

5. [Flow] ペインで、リクエスト フローの [PreFlow] のすぐ横にある [+] ボタンをクリックします。

6. [Create new policy] を選択し、[Traffic Management] セクションから [Spike Arrest] を選択した後、[Display Name] と [Name] を SA-LimitTokenRate に設定します。

7. [Add] をクリックし、[Policies] セクションの SA-LimitTokenRate をクリックします。

   SpikeArrest ポリシー構成が [Code] ペインに表示されます。

8. SpikeArrest ポリシー構成を次のように変更します。

   <SpikeArrest name="SA-LimitTokenRate"> <Rate>5pm</Rate> <UseEffectiveCount>false</UseEffectiveCount> </SpikeArrest>

   この構成では、許可されるリクエストの最大レートが 1 分あたり 5 件と指定されています。すべてのトラフィックに、この SpikeArrest ポリシーの制限が適用されます。

   注: 1 分あたり 5 件のリクエストという制限は、テストを円滑に進めるためのものです。このラボで使用している SpikeArrest の制限は、現実のシナリオでは一般に低すぎます。

   UseEffectiveCount が false に設定されているため、SpikeArrest ポリシーでトークン バケット アルゴリズムを使用するように指定されています。トラフィックは、レートをより短い間隔に分割することで平滑化されます。1 分あたり 5 件のリクエストとは、1/5 分あたり 1 件のリクエスト、つまり 12 秒ごとに 1 件のリクエストということです。2 番目のリクエストが前のリクエストから 12 秒経過しないうちに Message Processor に到達した場合、そのリクエストは拒否されることがあります。

API リクエストのために SpikeArrest ポリシーを追加する

この SpikeArrest ポリシーは、/bank/v1 API への呼び出しのトラフィックに対するレート制限を指定します。このレートはアプリケーションごとに適用されます。

1. プロキシの [Navigator] メニューで、[Proxy Endpoints] セクションの [default] の下にある [PreFlow] をクリックします。

   SpikeArrest ポリシーは呼び出しの初期に実行されますが、アプリケーションに応じてレートを制限するために、OAuthV2 VerifyJWTAccessToken ポリシーより後に実行される必要があります。

2. [Flow] ペインで、リクエスト フローの [PreFlow] のすぐ横にある [+] ボタンをクリックします。

3. [Create new policy] を選択し、[Traffic Management] セクションから [Spike Arrest] を選択した後、[Display Name] と [Name] を SA-LimitRateByApp に設定します。

4. [Add] をクリックし、[Policies] セクションの SA-LimitRateByApp をクリックします。

   SpikeArrest ポリシー構成が [Code] ペインに表示されます。

5. SpikeArrest ポリシー構成を次のように変更します。

   <SpikeArrest name="SA-LimitRateByApp"> <Rate>5pm</Rate> <Identifier ref="client_id" /> <UseEffectiveCount>true</UseEffectiveCount> </SpikeArrest>

   前のポリシーと同様に、この構成では、許可されるリクエストの最大レートが 1 分あたり 5 件と指定されています。ただし、このポリシーでは Identifier が指定されているため、SpikeArrest のレートは client_id ごとに個別に維持されます。クライアント ID は OA-VerifyToken ポリシーによって設定され、デベロッパー アプリケーションごとに一意です。

   UseEffectiveCount が true に設定されているため、リージョン内のすべてのトラフィックについてレート数が維持されます。このポリシーは、各期間に受け取ったリクエストのカウンタを保持します。期間は、1 分あたりのリクエスト数のレートを使用している場合、1 分です。レートの計算は、スライディング ウィンドウに基づきます。

   

   上記の例で、1 分あたり 50 件のリクエストというレートを使用しているとします。カウンタは 1 分の期間を使用します。ただし、レートが 1 秒あたりで指定されている場合は、カウンタ期間は 1 秒になります。矢印で示されているように、現時点でこの 1 分の期間のうち 10 秒が経過しているとします。前の 1 分の期間には 48 件のリクエストがあり、現在の期間ではこれまでに 5 件のリクエストがありました。

   新たなリクエストを許可するには、レートが 1 分あたり 50 件未満のリクエストである必要があります。計算されたレートは次のようになります。

   request_rate = (48 × (60-10)/60) + 6 = 46

   現在の期間では 60 秒のうち 10 秒しか経過していないので、残りの 50 秒については前の期間のレートを使用して計算されます。48 の 5/6 は 40 です。リクエストが許可されたとすると、現在の期間のカウントは 5 + 1、つまり 6 になります。リクエスト レートの計算結果は 46 となり、これは 1 分あたり 50 件未満のリクエスト レートなので、リクエストは許可されることがわかります。

6. [Save] > [Save as new revision] を選択します。

7. [Deploy] をクリックし、[Environment] で [eval] を選択します。

8. [Service Account] に、サービス アカウントのメールアドレスを指定します。

apigee-internal-access@{{{ project_0.project_id | PROJECT }}}.iam.gserviceaccount.com

9. [Deploy]、[Confirm] の順にクリックします。
10. [Overview] タブをクリックして eval のデプロイ ステータスを確認し、プロキシがデプロイされたと示されるまで待ちます。

[進行状況を確認] をクリックして、目標に沿って進んでいることを確認します。 SpikeArrest ポリシーを追加する

レート制限をテストする

1. Cloud Shell で、テスト VM への SSH 接続を開きます。

   TEST_VM_ZONE=$(gcloud compute instances list --filter="name=('apigeex-test-vm')" --format "value(zone)") gcloud compute ssh apigeex-test-vm --zone=${TEST_VM_ZONE} --force-key-file-overwrite

   承認するよう求められた場合は、[承認] をクリックします。

   これで、Cloud Shell セッションが VM 内で実行されます。

2. アプリケーションのコンシューマ キーとシークレットを取得するには、次のコマンドを実行します。

   export PROJECT_ID=$(gcloud config list --format 'value(core.project)' 2>/dev/null); echo "PROJECT_ID=${PROJECT_ID}" export CONSUMER_KEY=$(curl -s -H "Authorization: Bearer $(gcloud auth print-access-token)" -X GET "https://apigee.googleapis.com/v1/organizations/${PROJECT_ID}/developers/joe@example.com/apps/readonly-app" | jq ".credentials[0].consumerKey" --raw-output); echo "CONSUMER_KEY=${CONSUMER_KEY}" export CONSUMER_SECRET=$(curl -s -H "Authorization: Bearer $(gcloud auth print-access-token)" -X GET "https://apigee.googleapis.com/v1/organizations/${PROJECT_ID}/developers/joe@example.com/apps/readonly-app" | jq ".credentials[0].consumerSecret" --raw-output); echo "CONSUMER_SECRET=${CONSUMER_SECRET}"

3. 次のコマンドを繰り返し実行して、複数のアクセス トークンを生成します。

   curl -i -k -u "${CONSUMER_KEY}:${CONSUMER_SECRET}" -X POST "https://eval.example.com/token" -H "Content-Type: application/x-www-form-urlencoded" -d "grant_type=client_credentials"

   すぐに、レートを超過したことを示す 429 Too Many Requests レスポンスを受け取ります。このポリシーでは UseEffectiveCount が false なので、トークン バケット アルゴリズムを使用してトラフィックが平滑化されます。5 番目のリクエストの前に、Spike Arrest の違反が発生するでしょう。

4. JWT アクセス トークンを保存するには、次のコマンドを実行します。

   export TOKEN_RESPONSE=$(curl -k -u "${CONSUMER_KEY}:${CONSUMER_SECRET}" -X POST "https://eval.example.com/token" -H "Content-Type: application/x-www-form-urlencoded" -d "grant_type=client_credentials"); echo ${TOKEN_RESPONSE} export JWT_TOKEN=$(echo ${TOKEN_RESPONSE} | jq ".access_token" --raw-output); echo "JWT_TOKEN=${JWT_TOKEN}"

5. API 呼び出しに対して SpikeArrest ポリシーをテストするには、次のコマンドを繰り返し送信します。

   curl -i -k -H "Authorization: Bearer ${JWT_TOKEN}" -X GET "https://eval.example.com/bank/v1/customers"

   UseEffectiveCount が true なので、このポリシーではスライディング ウィンドウ アルゴリズムが使用されます。リクエストがブロックされるまでに、5 件のリクエストに成功するはずです。

6. コマンド exit を入力して SSH セッションを終了し、Cloud Shell に戻ります。

タスク 7. データ マスクを作成する

このタスクでは、データマスクを作成して、デバッグ セッションで特定の項目を非表示にします。

デバッグ セッションを開始する

Debug は、Apigee で動作している API プロキシのトラブルシューティングとモニタリングを行うためのツールです。Debug ツールを使用すると、API 呼び出しの各ステップの詳細を調べることができます。

1. 左側のナビゲーション メニューで、[プロキシ開発] > [API プロキシ] を選択し、[bank-v1] をクリックします。

2. [Debug] タブをクリックします。

3. [Start debug session] ペインで [Start debug session] をクリックし、環境のプルダウンで [eval] 環境を選択します。

4. [Start] をクリックします。

   デバッグ セッションでリクエストのキャプチャが開始されるまで少し時間がかかる場合があります。

   注: 画面の上部に赤い枠線で囲まれた「Error fetching debug transactions」や「List debug session transaction error」といったエラー メッセージが表示された場合でも、デバッグ セッションは正しく動作していることがあります。

   API リクエストを行ってからデバッグ セッションを確認します。

リクエストをデバッグする

1. Cloud Shell で、テスト VM への SSH 接続を開きます。

   TEST_VM_ZONE=$(gcloud compute instances list --filter="name=('apigeex-test-vm')" --format "value(zone)") gcloud compute ssh apigeex-test-vm --zone=${TEST_VM_ZONE} --force-key-file-overwrite

   承認するよう求められた場合は、[承認] をクリックします。

   これで、Cloud Shell セッションが VM 内で実行されます。

2. アプリケーションのトークンを取得するには、次のコマンドを実行します。

   export PROJECT_ID=$(gcloud config list --format 'value(core.project)' 2>/dev/null); echo "PROJECT_ID=${PROJECT_ID}" export CONSUMER_KEY=$(curl -s -H "Authorization: Bearer $(gcloud auth print-access-token)" -X GET "https://apigee.googleapis.com/v1/organizations/${PROJECT_ID}/developers/joe@example.com/apps/readonly-app" | jq ".credentials[0].consumerKey" --raw-output); echo "CONSUMER_KEY=${CONSUMER_KEY}" export CONSUMER_SECRET=$(curl -s -H "Authorization: Bearer $(gcloud auth print-access-token)" -X GET "https://apigee.googleapis.com/v1/organizations/${PROJECT_ID}/developers/joe@example.com/apps/readonly-app" | jq ".credentials[0].consumerSecret" --raw-output); echo "CONSUMER_SECRET=${CONSUMER_SECRET}" export TOKEN_RESPONSE=$(curl -k -u "${CONSUMER_KEY}:${CONSUMER_SECRET}" -X POST "https://eval.example.com/token" -H "Content-Type: application/x-www-form-urlencoded" -d "grant_type=client_credentials"); echo ${TOKEN_RESPONSE} export JWT_TOKEN=$(echo ${TOKEN_RESPONSE} | jq ".access_token" --raw-output); echo "JWT_TOKEN=${JWT_TOKEN}"

3. API に次のリクエストを送信します。

   curl -i -k -H "Authorization: Bearer ${JWT_TOKEN}" -X GET "https://eval.example.com/bank/v1/customers/abe@example.org/accounts"

4. Apigee UI ページに戻ります。

   [Debug] ページには、POST（トークンの生成）と GET（ユーザーのアカウントの取得）の 2 つのリクエストが表示されているはずです。

5. GET リクエストをクリックします。

   GET リクエストの詳細が表示されます。

6. 最初のポリシーをクリックします。これは、propertyset.oauth.secret 変数を private.secretkey 変数にコピーする AM-GetSecret ポリシーです。

   

   デバッグ セッションでは「private」の接頭辞が付いた変数が非表示になるため、[Phase Details] にはプライベート変数が表示されません。ただし、プロパティ セット変数にも同じ機密データが格納されているので、トラフィックをデバッグするユーザーに対してプロパティ セット変数を非表示にすることをおすすめします。

7. バックエンドからのレスポンスをクリックします。これは、工場アイコンの左側にある円で示されています。

   

   レスポンスには、アカウント残高を含むユーザーのアカウント情報が含まれています。

デバッグマスクを作成する

1. 同じブラウザ ウィンドウで新しいタブを開いて、Apigee API リファレンスにアクセスします。

   Apigee API リファレンスには、Apigee の管理や Apigee API の呼び出しに使用できるさまざまな API 呼び出しの詳細が記載されています。このページには、organization.environments API 呼び出しが示されています。

2. ページの下部までスクロールして、[updateDebugmask] をクリックします。

   この API 呼び出しは、環境のデバッグマスクを更新します。

3. [Try this API] ペインの name リクエスト パラメータには、次の値を使用します。

   organizations/{{{ project_0.project_id | PROJECT }}}/environments/eval/debugmask

4. リクエスト本文には、次の本文を入力します。

   { "responseJSONPaths": [ "$[*].balance" ], "variables": [ "propertyset.oauth.secret" ] }

   このペイロードによって propertyset.oauth.secret 変数がマスクされ、さらに、レスポンス ペイロードのオブジェクト配列の各 balance 項目もマスクされます。

5. [Execute] をクリックします。

   アカウントの選択を求めるポップアップ ボックスが表示されたら、受講者アカウントを選択します。

6. [Allow] をクリックして、ページに対して受講者認証情報の使用を許可します。

デバッグマスクをテストする

1. Apigee UI の左側のナビゲーション メニューで [プロキシ開発] > [API プロキシ] を選択し、[bank-v1] をクリックします。

2. [Debug] タブをクリックします。

3. [Start debug session] ペインで、環境のプルダウンから [eval] を選択します。

4. [Start] をクリックします。

5. SSH 接続が閉じている場合は、Cloud Shell でテスト VM への SSH 接続を開きます。

   TEST_VM_ZONE=$(gcloud compute instances list --filter="name=('apigeex-test-vm')" --format "value(zone)") gcloud compute ssh apigeex-test-vm --zone=${TEST_VM_ZONE} --force-key-file-overwrite

6. トークンを取得して、再度 API リクエストを送信します。

   export PROJECT_ID=$(gcloud config list --format 'value(core.project)' 2>/dev/null) export CONSUMER_KEY=$(curl -s -H "Authorization: Bearer $(gcloud auth print-access-token)" -X GET "https://apigee.googleapis.com/v1/organizations/${PROJECT_ID}/developers/joe@example.com/apps/readonly-app" | jq ".credentials[0].consumerKey" --raw-output) export CONSUMER_SECRET=$(curl -s -H "Authorization: Bearer $(gcloud auth print-access-token)" -X GET "https://apigee.googleapis.com/v1/organizations/${PROJECT_ID}/developers/joe@example.com/apps/readonly-app" | jq ".credentials[0].consumerSecret" --raw-output) export TOKEN_RESPONSE=$(curl -k -u "${CONSUMER_KEY}:${CONSUMER_SECRET}" -X POST "https://eval.example.com/token" -H "Content-Type: application/x-www-form-urlencoded" -d "grant_type=client_credentials") export JWT_TOKEN=$(echo ${TOKEN_RESPONSE} | jq ".access_token" --raw-output) curl -i -k -H "Authorization: Bearer ${JWT_TOKEN}" -X GET "https://eval.example.com/bank/v1/customers/abe@example.org/accounts"

7. Apigee UI の [Debug] ページに戻り、GET リクエストをクリックします。

8. AM-GetSecret ポリシーをクリックします。

   propertyset.oauth.secret 変数がマスクされます。

   

9. バックエンド レスポンスの [Proxy Response Flow Started] をクリックします。

   balance 項目がすべてマスクされています。

   

タスク 8. エラー処理を追加する

このタスクでは、特定のバックエンド リソースに対する呼び出しを制限するためのデフォルトの条件フローを作成し、バックエンド エラー メッセージを書き換えます。

API をテストする

1. SSH 接続が閉じている場合は、Cloud Shell でテスト VM への SSH 接続を開きます。

   TEST_VM_ZONE=$(gcloud compute instances list --filter="name=('apigeex-test-vm')" --format "value(zone)") gcloud compute ssh apigeex-test-vm --zone=${TEST_VM_ZONE} --force-key-file-overwrite

2. 「Y」と入力して続行し、ENTER キーを 2 回押してパスフレーズを空白のままにします。

3. トークンを取得して、/users に GET リクエストを送信します。

   export PROJECT_ID=$(gcloud config list --format 'value(core.project)' 2>/dev/null) export CONSUMER_KEY=$(curl -s -H "Authorization: Bearer $(gcloud auth print-access-token)" -X GET "https://apigee.googleapis.com/v1/organizations/${PROJECT_ID}/developers/joe@example.com/apps/readonly-app" | jq ".credentials[0].consumerKey" --raw-output) export CONSUMER_SECRET=$(curl -s -H "Authorization: Bearer $(gcloud auth print-access-token)" -X GET "https://apigee.googleapis.com/v1/organizations/${PROJECT_ID}/developers/joe@example.com/apps/readonly-app" | jq ".credentials[0].consumerSecret" --raw-output) export TOKEN_RESPONSE=$(curl -k -u "${CONSUMER_KEY}:${CONSUMER_SECRET}" -X POST "https://eval.example.com/token" -H "Content-Type: application/x-www-form-urlencoded" -d "grant_type=client_credentials") export JWT_TOKEN=$(echo ${TOKEN_RESPONSE} | jq ".access_token" --raw-output) curl -i -k -H "Authorization: Bearer ${JWT_TOKEN}" -X GET "https://eval.example.com/bank/v1/users"

   バックエンド サービスは GET /users リクエストを認識しないため、次のような 404 レスポンスを返します。

   HTTP/2 404 x-powered-by: Express content-security-policy: default-src 'none' x-content-type-options: nosniff content-type: text/html; charset=utf-8 x-cloud-trace-context: 7e96528757cc5053ba4fc8853037b02d;o=1 date: Wed, 19 Jan 2022 01:49:53 GMT server: Google Frontend content-length: 144 x-request-id: 2d8c8002-3152-4fc2-a60b-1729dd5483d8 via: 1.1 google <!DOCTYPE html> <html lang="en"> <head> <meta charset="utf-8"> <title>Error</title> </head> <body> <pre>Cannot GET /users</pre> </body> </html>

   レスポンスから HTML ペイロードが返されますが、これは RF-InvalidTokenRequest ペイロードの形式と一致していません。また、バックエンド レスポンスには機密データが含まれている可能性があります。このような理由から、バックエンド サービスからのエラー レスポンスを書き換えることがベスト プラクティスです。

404 Not Found エラーを書き換える

障害ルールを使用して、エラーを検出し、エラー メッセージを書き換えることができます。

RaiseFault ポリシーを使用して、新しいレスポンスを設定します。

1. Cloud コンソールで Apigee に移動します。

2. 左側のナビゲーション メニューで、[プロキシ開発] > [API プロキシ] を選択し、[bank-v1] をクリックします。

3. [Develop] タブをクリックします。

4. プロキシの [Navigator] メニューで、[Policies] の横にある [+] をクリックします。

5. [Mediation] セクションで [Raise Fault] を選択した後、[Display Name] と [Name] を RF-404NotFound に設定します。

6. [Create] をクリックします。[Policies] セクションで [RF-404NotFound] をクリックします。

7. RaiseFault ポリシー構成を次のように変更します。

   <RaiseFault name="RF-404NotFound"> <FaultResponse> <Remove> <Headers/> </Remove> <Set> <StatusCode>404</StatusCode> <ReasonPhrase>Not Found</ReasonPhrase> <Headers> <Header name="FaultName">{fault.name}</Header> </Headers> <Payload contentType="application/json">{ "error": "{request.verb} {proxy.pathsuffix} not found" }</Payload> </Set> </FaultResponse> <AssignTo createNew="true" type="response"/> <IgnoreUnresolvedVariables>true</IgnoreUnresolvedVariables> </RaiseFault>

   まず、Remove セクションによって、バックエンド サービスから取得された可能性のあるヘッダーがすべて削除され、次に Set セクションによってレスポンスが作成されます。エラーが発生したときに fault.name 変数の値を表示するために、FaultName ヘッダーが追加されています。fault.name 変数はエラーの名前を指定します。

FaultRule を作成する

1. プロキシの [Navigator] メニューで、[Target Endpoints] セクションの [default] をクリックします。

   デフォルトのターゲット エンドポイントには、404 レスポンスを返すバックエンド ターゲット呼び出しが含まれています。404 はエラーコードとして扱われます。エンドポイントからエラーが返されると、ターゲット エンドポイントに指定された FaultRule を使用して API レスポンスを書き換えることができます。

2. TargetEndpoint 構成の TargetEndpoint タグの直下に、次の FaultRules セクションを追加します。

   <FaultRules> <FaultRule name="404"> <Step> <Name>RF-404NotFound</Name> </Step> <Condition>response.status.code == 404</Condition> </FaultRule> </FaultRules>

   これで、TargetEndpoint の先頭は次のようになります。

   <TargetEndpoint name="default"> <FaultRules> <FaultRule name="404"> <Step> <Name>RF-404NotFound</Name> </Step> <Condition>response.status.code == 404</Condition> </FaultRule> </FaultRules>

3. [Save] > [Save as new revision] を選択します。

4. [Deploy] をクリックし、[Environment] で [eval] を選択します。

5. [Service Account] に、サービス アカウントのメールアドレスを指定します。

   apigee-internal-access@{{{ project_0.project_id | PROJECT }}}.iam.gserviceaccount.com

6. [Deploy]、[Confirm] の順にクリックします。

7. [Overview] タブをクリックして eval のデプロイ ステータスを確認し、プロキシがデプロイされたと示されるまで待ちます。

エンドポイント レスポンスのエラーをテストする

1. SSH 接続が閉じている場合は、Cloud Shell でテスト VM への SSH 接続を開きます。

   TEST_VM_ZONE=$(gcloud compute instances list --filter="name=('apigeex-test-vm')" --format "value(zone)") gcloud compute ssh apigeex-test-vm --zone=${TEST_VM_ZONE} --force-key-file-overwrite

2. トークンを取得して、/users に GET リクエストを送信します。

   export PROJECT_ID=$(gcloud config list --format 'value(core.project)' 2>/dev/null) export CONSUMER_KEY=$(curl -s -H "Authorization: Bearer $(gcloud auth print-access-token)" -X GET "https://apigee.googleapis.com/v1/organizations/${PROJECT_ID}/developers/joe@example.com/apps/readonly-app" | jq ".credentials[0].consumerKey" --raw-output) export CONSUMER_SECRET=$(curl -s -H "Authorization: Bearer $(gcloud auth print-access-token)" -X GET "https://apigee.googleapis.com/v1/organizations/${PROJECT_ID}/developers/joe@example.com/apps/readonly-app" | jq ".credentials[0].consumerSecret" --raw-output) export TOKEN_RESPONSE=$(curl -k -u "${CONSUMER_KEY}:${CONSUMER_SECRET}" -X POST "https://eval.example.com/token" -H "Content-Type: application/x-www-form-urlencoded" -d "grant_type=client_credentials") export JWT_TOKEN=$(echo ${TOKEN_RESPONSE} | jq ".access_token" --raw-output) curl -i -k -H "Authorization: Bearer ${JWT_TOKEN}" -X GET "https://eval.example.com/bank/v1/users"

   レスポンスが書き換えられ、次のようになっています。

   HTTP/2 404 faultname: ErrorResponseCode content-type: application/json x-request-id: 8d9db301-b3c7-4957-816d-93e796306dfb content-length: 39 date: Tue, 18 Jan 2022 06:42:23 GMT via: 1.1 google { "error": "GET /users not found" }

   レスポンスで JSON が使用されるようになっています。faultname ヘッダーの値が ErrorResponseCode であることに注目してください。これは、ターゲットからエラーコードが返されたときに指定される fault.name 変数の値です。バックエンド サービスから 404 レスポンスが返されるとすぐにエラーが生成され、ターゲット エンドポイントの障害ルールが評価されて、404 障害ルールによってレスポンスが書き換えられています。

404 条件フローを追加する

予期しないリクエストが送信されたときに、バックエンドからレスポンスが返されるのを待つ代わりに、プロキシ エンドポイントの条件フローの最後に新しい条件フローを追加して、他の条件フローの条件がいずれも満たされなかった場合にエラーが生成されるようにすることができます。こうすることで、条件フローにリストされているオペレーションのみがバックエンドに渡されるようになります。このパターンを利用して、特定のバックエンド サービス リソースのみにアクセスを許可できます。

1. プロキシの [Navigator] メニューで [Proxy Endpoint: default] に移動し、フロー セクションで [/bank/v1] の横にある [+] をクリックします。

2. 新しい条件フローに、次の値を指定します。

   プロパティ	値
   Flow name	404NotFound
   Condition type	[Custom] を選択
   Condition	DELETETHIS

3. [Add] をクリックします。

4. 404NotFound フローで、次の行を削除します。

   <Condition>DELETETHIS</Condition>

   前の条件フローの条件がいずれも満たされない場合、404NotFound フローが実行されます。

5. プロキシの [Navigator] メニューで、[Proxy Endpoints] セクションの [default] の下にある [404NotFound] をクリックします。

6. [Flow] ペインで、404NotFound リクエスト フローのすぐ横にある [+] ボタンをクリックします。

7. [Select Policy] で [Select existing policy] を選択し、[RF-404NotFound] をクリックします。

8. [Add] をクリックします。

9. [Save] > [Save as new revision] を選択します。

10. [Deploy] をクリックし、[Environment] で [eval] を選択します。

11. [Service Account] に、サービス アカウントのメールアドレスを指定します。

    apigee-internal-access@{{{ project_0.project_id | PROJECT }}}.iam.gserviceaccount.com

12. [Deploy]、[Confirm] の順にクリックします。

13. [Overview] タブをクリックして eval のデプロイ ステータスを確認し、プロキシがデプロイされたと示されるまで待ちます。

[進行状況を確認] をクリックして、目標に沿って進んでいることを確認します。 エラー処理を追加する

404 条件フローをテストする

1. SSH 接続が閉じている場合は、Cloud Shell でテスト VM への SSH 接続を開きます。

   TEST_VM_ZONE=$(gcloud compute instances list --filter="name=('apigeex-test-vm')" --format "value(zone)") gcloud compute ssh apigeex-test-vm --zone=${TEST_VM_ZONE} --force-key-file-overwrite

2. トークンを取得して、/users に GET リクエストを送信します。

   export PROJECT_ID=$(gcloud config list --format 'value(core.project)' 2>/dev/null) export CONSUMER_KEY=$(curl -s -H "Authorization: Bearer $(gcloud auth print-access-token)" -X GET "https://apigee.googleapis.com/v1/organizations/${PROJECT_ID}/developers/joe@example.com/apps/readonly-app" | jq ".credentials[0].consumerKey" --raw-output) export CONSUMER_SECRET=$(curl -s -H "Authorization: Bearer $(gcloud auth print-access-token)" -X GET "https://apigee.googleapis.com/v1/organizations/${PROJECT_ID}/developers/joe@example.com/apps/readonly-app" | jq ".credentials[0].consumerSecret" --raw-output) export TOKEN_RESPONSE=$(curl -k -u "${CONSUMER_KEY}:${CONSUMER_SECRET}" -X POST "https://eval.example.com/token" -H "Content-Type: application/x-www-form-urlencoded" -d "grant_type=client_credentials") export JWT_TOKEN=$(echo ${TOKEN_RESPONSE} | jq ".access_token" --raw-output) curl -i -k -H "Authorization: Bearer ${JWT_TOKEN}" -X GET "https://eval.example.com/bank/v1/users"

   レスポンスが書き換えられ、次のようになっています。

   HTTP/2 404 faultname: RaiseFault content-type: application/json x-request-id: d6bbd48f-65bd-4551-9236-636fad03a609 content-length: 39 date: Tue, 18 Jan 2022 07:07:58 GMT via: 1.1 google alt-svc: h3=":443"; ma=2592000,h3-29=":443"; ma=2592000 { "error": "GET /users not found" }

   faultname ヘッダーの値が RaiseFault になっています。これは、RaiseFault ポリシーによってエラーが生成されたときに使用される fault.name の値です。404NotFound 条件フローの RaiseFault ポリシーによって、レスポンスが生成されました。

お疲れさまでした

このラボでは、JWT OAuth トークンを要求することで API を保護しました。SpikeArrest ポリシーを追加して、トラフィックを制限しました。プライベート変数とデータ マスキングを使用して、デバッグ セッションで機密データを非表示にしました。また、バックエンド エラー メッセージを書き換え、404 条件フローを使用して、バックエンドへの呼び出しを特定のリソースに限定しました。

次のステップと詳細情報

• OAuth
• SpikeArrest ポリシー
• データのマスキングと非表示
• Opaque トークンと JWT
• 障害の処理

マニュアルの最終更新日: 2025 年 1 月 28 日

ラボの最終テスト日: 2025 年 1 月 28 日

Copyright 2025 Google LLC. All rights reserved. Google および Google のロゴは Google LLC の商標です。その他すべての企業名および商品名はそれぞれ各社の商標または登録商標です。