コンテンツにスキップ
Kong Logo | Kong Docs Logo
  • ドキュメント
    • API仕様を確認する
      View all API Specs すべてのAPI仕様を表示 View all API Specs arrow image
    • ドキュメンテーション
      API Specs
      Kong Gateway
      軽量、高速、柔軟なクラウドネイティブAPIゲートウェイ
      Kong Konnect
      SaaSのエンドツーエンド接続のための単一プラットフォーム
      Kong AI Gateway
      GenAI インフラストラクチャ向けマルチ LLM AI Gateway
      Kong Mesh
      Kuma と Envoy をベースにしたエンタープライズサービスメッシュ
      decK
      Kongの構成を宣言型で管理する上で役立ちます
      Kong Ingress Controller
      Kubernetesクラスタ内で動作し、Kongをプロキシトラフィックに設定する
      Kong Gateway Operator
      YAMLマニフェストを使用してKubernetes上のKongデプロイメントを管理する
      Insomnia
      コラボレーティブAPI開発プラットフォーム
  • Plugin Hub
    • Plugin Hubを探索する
      View all plugins すべてのプラグインを表示 View all plugins arrow image
    • 機能性 すべて表示 View all arrow image
      すべてのプラグインを表示
      AI's icon
      AI
      マルチ LLM AI Gatewayプラグインを使用してAIトラフィックを管理、保護、制御する
      認証's icon
      認証
      認証レイヤーでサービスを保護する
      セキュリティ's icon
      セキュリティ
      追加のセキュリティレイヤーでサービスを保護する
      トラフィック制御's icon
      トラフィック制御
      インバウンドおよびアウトバウンドAPIトラフィックの管理、スロットル、制限
      サーバーレス's icon
      サーバーレス
      他のプラグインと組み合わせてサーバーレス関数を呼び出します
      分析と監視's icon
      分析と監視
      APIとマイクロサービストラフィックを視覚化、検査、監視
      変革's icon
      変革
      Kongでリクエストとレスポンスをその場で変換
      ログ記録's icon
      ログ記録
      インフラストラクチャに最適なトランスポートを使用して、リクエストと応答データをログに記録します
  • サポート
  • コミュニティ
  • Kongアカデミー
デモを見る 無料トライアルを開始
decK
  • Home icon
  • decK
  • Apiops
  • Federated Configuration
report-issue問題を報告する
  • Kong Gateway
  • Kong Konnect
  • Kong Mesh
  • Kong AI Gateway
  • Plugin Hub
  • decK
  • Kong Ingress Controller
  • Kong Gateway Operator
  • Insomnia
  • Kuma

  • ドキュメント投稿ガイドライン
  • Introduction
    • Overview
    • Configuration Options
    • Support Policy
    • Security Policy
  • Changelog
  • Installation
    • Overview
    • Binary
    • Docker
    • GitHub Actions
  • Get Started
  • Managing Kong Gateway
    • Overview
    • Konnect Configuration
    • Configure Authentication
    • Ping
    • Backup
    • Diff
    • Sync
    • Apply
    • Reset
    • Validate
    • RBAC
    • Workspaces
    • Tags
    • De-duplicate Plugin Configuration
    • Object Defaults
    • Sensitive Data
  • decK Files
    • Overview
    • Config Generation
      • openapi2kong
      • kong2kic
      • kong2tf
    • Linting
    • File Manipulation
      • Overview
      • Update Values
      • Plugins
      • Tags
      • Namespace
    • Combining Files
      • Merge
      • Render
    • Validate
    • Convert
  • APIOps
    • Overview
    • Continuous Integration
    • Federated Config
  • Reference
    • Entities
    • FAQ
    • Gateway 3.0 Upgrade
    • Environment Variables
enterprise-switcher-icon 次に切り替える: OSS
On this pageOn this page
  • Federated management example
    • Application team configs
    • Consumer management
    • Platform security
    • Rate Limiting
  • Federated management is easy!

このページは、まだ日本語ではご利用いただけません。翻訳中です。

Federated Configuration

As shown in the APIOps example, decK enables a completely federated API management process.

  • Application teams can work with OpenAPI files as the source of truth
  • If they want to add Kong specific configuration, they can patch it in
  • Platform teams can layer on required policies
  • State files can be linted for unwanted configuration, for example, non-HTTPS routes

Federated management example

AcmeCorp is building their new SaaS platform on top of Kong Gateway. They want application teams to manage their own routing configuration, but also need to ensure that the APIs are secured appropriately.

To meet their needs, they split their configuration into multiple files:

  • team-a.yaml
  • team-b.yaml (all the way to team-z.yaml)
  • consumers.yaml
  • platform-security-plugins.yaml
  • platform-rate-limiting-plugins.yaml

Each of these files contains a subset of the configuration needed to run Kong Gateway for AcmeCorp.

Application team configs

Each of the application team configurations contains routing information only. It uses select_tags to ensure that only entities owned by that team are updated when deck gateway sync is run.

# team-a.yaml
# Contains services + routes
_format_version: '3.0'
_info:
 select_tags:
 - team-a
services:
  - name: users
    url: https://example.com/users
    routes:
      - name: Passthrough
        paths: [/]
# team-b.yaml
# Contains services + routes
_format_version: '3.0'
_info:
 select_tags:
 - team-b
services:
  - name: widgets
    url: https://widgets.example.com/
    routes:
      - name: count
        paths: [/count]
      - name: stats
        paths: [/stats]

Consumer management

The users and systems that consume AcmeCorp’s APIs are independent of any team. To ensure that consumers can call the AcmeCorp APIs, decK is used to create consumers and credentials:

# consumers.yaml
# Managed by a central team
_format_version: '3.0'
_info:
 select_tags:
 - consumers
consumers:
  - username: alice
    keyauth_credentials:
      - key: hello_alice
  - username: bob
    keyauth_credentials:
      - key: hello_bob
  - username: charlie
    keyauth_credentials:
      - key: hello_charlie

Platform security

To ensure that the APIs are only accessed by authorized users, the platform team applies a global key-auth plugin:

_format_version: '3.0'
_info:
 select_tags:
 - security-plugins
plugins:
  - name: key-auth

Rate Limiting

Finally, the platform team wants to add a rate limiting plugin to the users service to protect the underlying database.

They could work with team-a to add the plugin in the team’s configuration file, but the platform team want to be able to change values rapidly based on monitoring data. To enable this, the platform team chooses to layer on the rate limiting configuration independently of team-a’s configuration.

_format_version: '3.0'
_info:
 select_tags:
   - plugins-rate-limit
 default_lookup_tags:
  services:
    - team-a
plugins:
  - name: rate-limiting
    service: users
    config:
      minute: 10

As this configuration uses a different select_tags value, it will not be edited by team-a when they run deck gateway sync. The use of default_lookup_tags allows the platform team to reference the users service even though it has different tags.

Federated management is easy!

The example above shows how multiple application and platform teams can manage their configuration independently. Each application team can focus on routing requests to their service while the platform team handles security and stability concerns.

Thank you for your feedback.
Was this page useful?
情報が多すぎる場合 close cta icon
Kong Konnectを使用すると、より多くの機能とより少ないインフラストラクチャを実現できます。月額1Mリクエストが無料。
無料でお試しください
  • Kong
    APIの世界を動かす

    APIマネジメント、サービスメッシュ、イングレスコントローラーの統合プラットフォームにより、開発者の生産性、セキュリティ、パフォーマンスを大幅に向上します。

    • 製品
      • Kong Konnect
      • Kong Gateway Enterprise
      • Kong Gateway
      • Kong Mesh
      • Kong Ingress Controller
      • Kong Insomnia
      • 製品アップデート
      • 始める
    • ドキュメンテーション
      • Kong Konnectドキュメント
      • Kong Gatewayドキュメント
      • Kong Meshドキュメント
      • Kong Insomniaドキュメント
      • Kong Konnect Plugin Hub
    • オープンソース
      • Kong Gateway
      • Kuma
      • Insomnia
      • Kongコミュニティ
    • 会社概要
      • Kongについて
      • お客様
      • キャリア
      • プレス
      • イベント
      • お問い合わせ
  • 利用規約• プライバシー• 信頼とコンプライアンス
© Kong Inc. 2025