ACL Roles

A role is a collection of policies that your ACL administrator can link to a token. They enable you to reuse policies by decoupling the policies from the token distributed to team members. Instead, the token is linked to the role, which is able to hold several policies that can be updated asynchronously without distributing new tokens to users. As a result, roles can provide a more convenient authentication infrastructure than creating unique policies and tokens for each requester.

Workflow Overview

Roles are configurations linking several policies to a token. The following procedure describes the workflow for implementing roles.

  1. Assemble rules into policies (see Policies) and register them in Consul.
  2. Define a role and include the policy IDs or names.
  3. Register the role in Consul and link it to a token.
  4. Distribute the tokens to users for implementation.

Creating Roles

Creating roles is commonly the responsibility of the Consul ACLs administrator. Roles have several attributes, including service identities and node identities. Refer to the following documentation for details:

Use the Consul command line or API endpoint to create roles.

Command Line

Issue the consul acl role create command to create roles. In the following example, a role named crawler is created that contains a policy named crawler-kv and a policy named crawler-key.

  1. $ consul acl role create -name "crawler" -description "web crawler role" -policy-name "crawler-kv" -policy-name "crawler-key"

Refer to the command line documentation for details.

API

Make a PUT call to the acl/role endpoint and specify the role configuration in the payload to create roles. You can save the role definition in a JSON file or use escaped JSON in the call. In the following example call, the payload is defined externally.

  1. $ curl --request PUT --data @payload.json http://127.0.0.1:8500/v1/acl/role

Refer to the API documentation for details.

Role Attributes

Roles may contain the following attributes:

  • ID: The ID is an auto-generated public identifier. You can specify the role ID when linking it to tokens.
  • Name: A unique meaningful name for the role. You can specify the role Name when linking it to tokens.
  • Description: (Optional) A human-readable description of the role.
  • Policies: Specifies a the list of policies that are applicable for the role. The object can reference the policy ID or Name attribute.
  • ServiceIdentities: Specifies a list of services that are applicable for the role. See Service Identities for details.
  • NodeIdentities: Specifies a list of nodes that are applicable for the role. See Node Identities for details.
  • Namespace: EnterpriseRoles - 图1Enterprise The namespace that the policy resides in. Roles can only be linked to policies that are defined in the same namespace. See Namespaces for additional information. Requires Consul Enterprise 1.7.0+
  • Partition: EnterpriseRoles - 图2Enterprise The admin partition that the policy resides in. Roles can only be linked to policies that are defined in the same admin partition. See Admin Partitions for additional information. Requires Consul Enterprise 1.10.0+.

Service Identities

You can specify a service identity when configuring roles or linking tokens to policies. Service identities enable you to quickly construct policies for services, rather than creating identical polices for each service.

Service identities are used during the authorization process to automatically generate a policy for the service(s) specified. The policy will be linked to the role or token so that the service(s) can be discovered and discover other healthy service instances in a service mesh. Refer to the service mesh topic for additional information about Consul service mesh.

Service Identity Specification

Use the following syntax to define a service identity:

  1. {
  2.   "ServiceIdentities": [
  3.     {
  4.       "ServiceName": "<service name>",
  5.       "Datacenters": ["<datacenter name>"]
  6.     }
  7.   ]
  8. }

Refer to the the API documentation for roles for additional information and examples.

Scope for Namespace and Admin Partition - In Consul Enterprise, service identities inherit the namespace or admin partition scope of the corresponding ACL token or role.

The following policy is generated for each service when a service identity is declared:

  1. # Allow the service and its sidecar proxy to register into the catalog.
  2. service "<service name>" {
  3.     policy = "write"
  4. }
  5. service "<service name>-sidecar-proxy" {
  6.     policy = "write"
  7. }
  9. # Allow for any potential upstreams to be resolved.
  10. service_prefix "" {
  11.     policy = "read"
  12. }
  13. node_prefix "" {
  14.     policy = "read"
  15. }

Refer to the rules reference for information about the rules in the policy.

Example

The following role configuration contains service identities for the web and db services. Note that the db service is also scoped to the dc1 datacenter so that the policy will only be applied to instances of db in dc1.

Roles - 图3

example-role.json

  1. {
  2.   "Name": "example-role",
  3.   "Description": "Showcases all input parameters",
  4.   "Policies": [
  5.     {
  6.       "ID": "783beef3-783f-f41f-7422-7087dc272765"
  7.     },
  8.     {
  9.       "Name": "node-read"
  10.     }
  11.   ],
  12.   "ServiceIdentities": [
  13.     {
  14.       "ServiceName": "web"
  15.     },
  16.     {
  17.       "ServiceName": "db",
  18.       "Datacenters": ["dc1"]
  19.     }
  20.   ],
  21.   "NodeIdentities": [
  22.     {
  23.       "NodeName": "node-1",
  24.       "Datacenter": "dc2"
  25.     }
  26.   ]
  27. }

During the authorization process, the following policies for the web and db services will be generated and linked to the token:

Roles - 图4

web-policy.hcl

  1. # Allow the service and its sidecar proxy to register into the catalog.
  2. service "web" {
  3.     policy = "write"
  4. }
  5. service "web-sidecar-proxy" {
  6.     policy = "write"
  7. }
  9. # Allow for any potential upstreams to be resolved.
  10. service_prefix "" {
  11.     policy = "read"
  12. }
  13. node_prefix "" {
  14.     policy = "read"
  15. }

Per the ServiceIdentities.Datacenters configuration, the db policy is scoped to resources in the dc1 datacenter.

Roles - 图5

db-policy.hcl

  1. # Allow the service and its sidecar proxy to register into the catalog.
  2. service "db" {
  3.     policy = "write"
  4. }
  5. service "db-sidecar-proxy" {
  6.     policy = "write"
  7. }
  9. # Allow for any potential upstreams to be resolved.
  10. service_prefix "" {
  11.     policy = "read"
  12. }
  13. node_prefix "" {
  14.     policy = "read"
  15. }

Node Identities

You can specify a node identity when configuring roles or linking tokens to policies. Node commonly refers to a Consul agent, but a node can also be a physical server, cloud instance, virtual machine, or container.

Node identities enable you to quickly construct policies for nodes, rather than manually creating identical polices for each node. They are used during the authorization process to automatically generate a policy for the node(s) specified. You can specify the token linked to the policy in the acl_tokens_agent field when configuring the agent.

Node Identity Specification

Use the following syntax to define a node identity:

  1. {
  2.   "NodeIdentities": [
  3.     {
  4.       "NodeName": "<node name>",
  5.       "Datacenter": "<datacenter name>"
  6.     }
  7.   ]
  8. }

Refer to the the API documentation for roles for additional information and examples.

Consul Enterprise Namespacing - Node Identities can only be applied to tokens and roles in the default namespace. The generated policy rules allow for service:read permissions on all services in all namespaces.

The following policy is generated for each node when a node identity is declared:

  1. # Allow the agent to register its own node in the Catalog and update its network coordinates
  2. node "<node name>" {
  3.   policy = "write"
  4. }
  6. # Allows the agent to detect and diff services registered to itself. This is used during
  7. # anti-entropy to reconcile difference between the agents knowledge of registered
  8. # services and checks in comparison with what is known in the Catalog.
  9. service_prefix "" {
  10.   policy = "read"
  11. }

Refer to the rules reference for information about the rules in the policy.

Example

The following role configuration contains a node identity for node-1. Note that the node identity is also scoped to the dc2 datacenter. As a result, the policy will only be applied to nodes named node-1 in dc2.

Roles - 图6

example-role.json

  1. {
  2.   "Name": "example-role",
  3.   "Description": "Showcases all input parameters",
  4.   "Policies": [
  5.     {
  6.       "ID": "783beef3-783f-f41f-7422-7087dc272765"
  7.     },
  8.     {
  9.       "Name": "node-read"
  10.     }
  11.   ],
  12.   "NodeIdentities": [
  13.     {
  14.       "NodeName": "node-1",
  15.       "Datacenter": "dc2"
  16.     }
  17.   ]
  18. }

During the authorization process, the following policy will be generated and linked to the token:

Roles - 图7

node-1-policy.hcl

  1. # Allow the agent to register its own node in the Catalog and update its network coordinates
  2. node "node-1" {
  3.   policy = "write"
  4. }
  6. # Allows the agent to detect and diff services registered to itself. This is used during
  7. # anti-entropy to reconcile differences between the agent's knowledge of registered
  8. # services and checks in comparison with what is known in the Catalog.
  9. service_prefix "" {
  10.   policy = "read"
  11. }