はじめに

Kong Gateway 2.8のリリースでシークレットマネジメントのコンセプトを紹介しましたが、最近のKong Gateway 3.0のリリースで、Kongの承認が得られたことを嬉しく思います！つまり、すべての機密情報を管理するために、本番でシークレットマネジメントに頼ることができるのです。

Kong Gatewayは、データベースのパスワードからプラグインで使用するAPIキーまで、多くの秘密情報に依存して動作しています。以前はロールベースアクセスコントロール（RBAC）を使って、管理APIとKong Managerの機密情報へのアクセスを制限することができましたが、それは「オール・オア・ナッシング」アプローチです。コントリビューターはプラグインの設定を管理することもできますし、できないこともあります。もし、秘密の値を見ることなく設定を管理することができたら、素晴らしいことだと思いませんか？

これを可能にするのが、「Secrets Management」です。

対応するVaultは？

今回の発表により、以下のシークレット用データソースを正式にサポートすることになりました：

• 環境変数（OSS）
• HashiCorp Vault（エンタープライズ）
• AWS Secrets Manager（エンタープライズ）
• Google Cloud Secrets Engine (エンタープライズ、ベータ版)

Kongは、上記の各システムをネストしたキーのセットに抽象化します。変わるのは保管庫の識別子（hcv、aws、env）だけです。 例えば、HashiCorp保管庫のPostgresシークレットのパスワードフィールドにアクセスするには、次のように参照することになります：

{vault://hcv/postgres/password}

AWS Secrets Managerに保存されている同じシークレットは、ほとんど同じように見えるでしょう：

{vault://aws/postgres/password}

最後に、env vaultを使ってどのように見えるか見てみましょう：

export POSTGRES='{"username":"user", "password":"pass"}'
{vault://env/postgres/password}

このように、KongはJSONペイロードを設定することで、環境変数を使用しながらネスティングを行うことができます。

“Referenceable “の理解

Kong Gateway のパフォーマンスを維持するため、シークレットを参照するためにボールト参照を使用できるフィールドを制限しています。データ保管庫の値を使用できる場所を理解しやすくするため、プラグインのドキュメントでは、秘密をサポートするフィールドに「参照可能」というタグを付けています。

例として、proxy-cache-advancedのドキュメントを見てみると、config.redis.passwordの記述に以下のようにあります：

つまり、{vault://hcv/redis/password}という値を設定すれば、期待通りに解決されることになります。

Secrets Management による Redis の保護

Secrets Managementについては、これまでにも何度も説明してきましたが、実際に例を見ることで、その意味を理解することができました。Proxy Cache Advancedプラグインを使用して、RedisのパスワードをHashiCorp Vaultに保存する方法を紹介します。

Redisを実行する

今回はRedisを使うので、まずはローカルでサーバーを動かしてみましょう。すでにRedisはインストール済みで、stdinで提供される設定ファイルを使ってサーバーを起動し、サーバーのパスワードを設定します：

echo 'requirepass demo' | redis-server -

HashiCorp Vaultを実行する

次に、秘密を保存するためにVaultサーバーを実行する必要があります。Vaultを起動し、secretという名前の新しいkvストアを作成し、認証用のルートキー（私の場合はhvs.x4abajxI7TWduo0GQMnd5N8Qのようです）を返します。

Vaultができたら、そこに何かデータを保存する必要があります。以下を実行してredisシークレットを作成します：

export VAULT_ADDR="http://localhost:8200"
vault kv put -mount secret redis password=demo

Dockerを使用してKong Gatewayを起動する

Vaultが実行されたら、Kong Gatewayコンテナをローカルで実行する必要があります。これを行うために、私はKongドキュメントのDockerの指示に従いましたが、1つ大きな変更がありました – KONG_VAULT_HCV_の値を追加して、環境変数を使用してHashiCorp vaultを有効にしました：

docker run -d --name kong-gateway \
  --network=kong-net \
…snip…
  -e KONG_LICENSE_DATA \
  -e KONG_VAULTS=bundled \
  -e KONG_VAULT_HCV_PROTOCOL=http \<
  -e KONG_VAULT_HCV_HOST="host.docker.internal" \
  -e KONG_VAULT_HCV_PORT=8200 \
  -e KONG_VAULT_HCV_MOUNT=secret \
  -e KONG_VAULT_HCV_KV=v2 \
  -e KONG_VAULT_HCV_TOKEN="YOUR_TOKEN"  \
…snip…
  kong/kong-gateway:3.0.0

この時点で、シークレットマネジメントを試すのに必要なものはすべて揃っています！

プロキシ キャッシュの高度な使用

今回は、Proxy Caching Advancedプラグインを使用して、Vaultの設定をテストしてみます。プラグインを有効にするには、まず、サービスとルートを作成する必要があります。テストリクエストをmockbin.orgにプロキシしてみましょう：

curl -i -X POST \
  --url http://localhost:8001/services/ \
  --data 'name=example-service' \
  --data 'url=http://mockbin.org'

curl -i http://localhost:8001/services/example-service/routes -d paths="/mock"

proxy-cache-advancedプラグインも設定する必要があります。ほとんどのフィールドでドキュメントにあるデフォルト値を使用していますが、config.redis.passwordを見てみましょう。ここでは、保管庫からの値を参照しています：

curl localhost:8001/services/example-service/plugins \
--data "name=proxy-cache-advanced"  \
--data "config.response_code=200" \
--data "config.request_method=GET" \
--data "config.content_type=application/json; charset=utf-8" \
--data "config.cache_control=false" \
--data "config.strategy=redis" \
--data "config.redis.host=host.docker.internal" \
--data "config.redis.port=6379" \
--data "config.redis.password={vault://hcv/redis/password}"

この時点で、Kong Gatewayのログに注目してください。Vaultが正しく応答していない場合は、ログにエラーが含まれています。以下は、私が間違った設定をした後に受け取ったエラーです。HCV_TOKEN:

unable to resolve reference {vault://hcv/redis/password}

最後に、私たちのルートにリクエストをする時が来ました。初めてリクエストをしたときのレスポンスはmockbin.orgからで、レスポンスのX-Cache-StatusヘッダはMissになるでしょう。

curl -i localhost:8000/mock/request/hello

同じリクエストを再度行うと、X-Cache-StatusヘッダはHitを返します。Redisのキーもチェックすることで、キャッシュが投入されていることを確認することができます：

echo "KEYS *" | redis-cli -a demo

結論

おめでとうございます！あなたは今、Kongで秘密管理の仕組みを学びました。機密情報には理由があり、Kongの保管庫機能を使用することで、詮索好きな人の目から値を遠ざけることができます。

環境、HashiCorp Vault、AWS Secrets Managerのドライバは今日から本番対応ですが、もう一つお伝えしたいことがあります。Google Cloud Secrets Engineのサポートも発表していますので、GCPユーザーの方はご安心ください。

私はこのリリースに興奮していますし、皆さんもそうであることを願っています。もし何か質問があれば、Twitterの@mheapかKong CommunityのSlackで見つけてください。

原文：Secrets Management in Kong is Now GA!
著者：Michael Heap