Setting up and using ACLs

古いプラグインバージョンのドキュメントを閲覧しています。

Note: We have deprecated the usage of whitelist and blacklist in favor of allow and deny. This change may require Admin API requests to be updated.

Prerequisites

Configure your service or route with an authentication plugin so that the plugin can identify the client consumer making the request.
Enable the ACL plugin

Associate consumers with an ACL

With a database

Without a database

After you have added an authentication plugin to a Service or a Route, and you have created your consumers, you can now associate a group to a consumer using the following request:

curl -X POST http://localhost:8001/consumers/{CONSUMER}/acls \
    --data "group=group1" \
    --data "tags[]=tag1" \
    --data "tags[]=tag2"

CONSUMER: The username property of the consumer entity to associate the credentials with.

form parameter	default	description
`group`		The arbitrary group name to associate with the consumer.
`tags`		Optional descriptor tags for the group.

You can create ACL objects via the acls entry in the declarative configuration file:

acls:
- consumer: {CONSUMER}
  group: group1
  tags: { tag1 }

CONSUMER: The id or username property of the Consumer entity to associate the credentials to.
group: The arbitrary group name to associate to the Consumer.
tags: Optional descriptor tags for the group.

You can have more than one group associated to a consumer.

Upstream headers

When a consumer has been validated, the plugin appends a X-Consumer-Groups header to the request before proxying it to the Upstream service, so that you can identify the groups associated with the consumer. The value of the header is a comma-separated list of groups that belong to the consumer, like admin, pro_user.

This header will not be injected in the request to the upstream service if the hide_groups_header config flag is set to true.

More information

前へ Basic config examples for ACL

次へ ACL Changelog