Skip to content
|
Kong Gateway
3.6.x
github-edit-pageEdit this page
report-issueReport an issue
You are browsing documentation for an older version. See the latest documentation here.

Consumer Groups

Consumer groups enable the organization and categorization of consumers (users or applications) within an API ecosystem. By grouping consumers together, you eliminate the need to manage them individually, providing a scalable, efficient approach to managing configurations.

With consumer groups, you can scope plugins to specifically defined consumer groups and a new plugin instance will be created for each individual consumer group, making configurations and customizations more flexible and convenient. For all plugins available on the consumer groups scope, see the Plugin Scopes Reference.

Note: Consumer groups plugin scoping is a feature that was added in Kong Gateway version 3.4. Running a mixed-version Kong Gateway cluster (3.4 control plane, and <=3.3 data planes) is not supported when using consumer-group scoped plugins.

Use cases

  • Managing permissions: Consumer groups can be used to define different sets of users with varying levels of permissions. For example, you can create distinct consumer groups for regular users, premium users, and administrators.

  • Managing roles: Within an organization, there may be various departments or teams that interact with APIs differently. By creating consumer groups for these different roles, you can customize the API usage experience. For instance, an organization could have separate consumer groups for the marketing team, development team, and support team.

  • Resource quotas and rate limiting: Consumer groups can be used to enforce resource quotas and rate limiting on different sets of consumers. For instance, you can apply different rate limits to different consumer groups based on their subscription plans.

  • Customizing plugin configurations: With the ability to scope plugins specifically to defined groups, different consumer groups can have distinct plugin configurations based on their requirements. For example, one group may require additional request transformations while another may not need them at all.

More information