luxolus
/
open-consul
2
0
Fork 0
Code Issues 1 Pull Requests Packages Releases Wiki Activity

Apply suggestions from code review 

Co-authored-by: Chris S. Kim <ckim@hashicorp.com>
This commit is contained in:
trujillo-adam 2022-03-08 14:04:46 -08:00 committed by GitHub
parent 883ea2f0ce
commit ed8aa7d24a
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
5 changed files with 15 additions and 14 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

10
website/content/docs/security/acl/acl-policies.mdx
View File

@ -113,7 +113,7 @@ Use the `policy` keyword and one of the following access levels to set a policy
- `write`: Allows the resource to be read and modified. - `write`: Allows the resource to be read and modified.
- `deny`: Denies read and write access to the resource. - `deny`: Denies read and write access to the resource.
The special `list` access level provices access to all keys with the specified resource label in the Consul KV. The `list` access level can only be used with the `key_prefix` resource. The [`acl.enable_key_list_policy`](/docs/agent/options#acl_enable_key_list_policy) setting must be set to `true`. The special `list` access level provides access to all keys with the specified resource label in the Consul KV. The `list` access level can only be used with the `key_prefix` resource. The [`acl.enable_key_list_policy`](/docs/agent/options#acl_enable_key_list_policy) setting must be set to `true`.
### Matching and Prefix Values ### Matching and Prefix Values
@ -198,7 +198,7 @@ When using prefix-based rules, the most specific prefix match determines the act
- A rule that denies access to a specific resource label - A rule that denies access to a specific resource label
- A prefix-based rule that allows write access to a class of resources - A prefix-based rule that allows write access to a class of resources
- An empty prefix that grants read-only access to all resource within the declared class - An empty prefix that grants read-only access to all resources within the declared class
#### Matching Precedence #### Matching Precedence
@ -286,8 +286,8 @@ operator = "read"
The rules from all policies, including roles and service identities, linked with a token are combined to form that token's effective rule set. The rules from all policies, including roles and service identities, linked with a token are combined to form that token's effective rule set.
Policy rules can be defined in either an `allowlist` or `denylist` mode, depending on the configuration of the [`acl_default_policy`](/docs/agent/options#acl_default_policy). Policy rules can be defined in either an `allowlist` or `denylist` mode, depending on the configuration of the [`acl_default_policy`](/docs/agent/options#acl_default_policy).
If the default policy is configured to deny access to all resources, then policy rules can be set to `allowlist` access to specific resources. If the default policy is configured to deny access to all resources, then you can specify `allowlist` in policy rules to explicitly allow access to resources.
If the default policy is to allow then access to all resources, policy rules can be used to explicitly deny access to resources. Conversely, if the default policy is configured to allow access to all resources, then you can specify `denylist` in policy rules to explicitly deny access to resources.
## Implementing Policies ## Implementing Policies
@ -424,7 +424,7 @@ The `Hash`, `CreateIndex`, and `ModifyIndex` attributes are also printed. These
## Built-in Policies ## Built-in Policies
New installations of Consul ship with the following built-ib policies. New installations of Consul ship with the following built-in policies.
### Global Management ### Global Management

9
website/content/docs/security/acl/acl-roles.mdx
View File

@ -3,7 +3,7 @@ layout: docs
page_title: Roles page_title: Roles
description: >- description: >-
This topic describes roles within the access control list (ACL) system. A role is a named set of policies and service identities. This topic describes roles within the access control list (ACL) system. A role is a named set of policies and service identities.
They are intended to They enable you to reuse policies by decoupling the policies from the token distributed to team members.
--- ---
# Roles # Roles
@ -15,7 +15,7 @@ As a result, roles can provide a more convenient authentication infrastrcture th
## Workflow Overview ## Workflow Overview
Roles are configurations link several policies to a token. The following procedure describes the workflow for implementing roles. 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](/docs/security/acl/acl-policies)) and register them in Consul. 1. Assemble rules into policies (see [Policies](/docs/security/acl/acl-policies)) and register them in Consul.
1. Define a role and include the policy IDs or names. 1. Define a role and include the policy IDs or names.
@ -64,7 +64,8 @@ Roles may contain the following table describe the attributes:
- `Policies`: Specifies a the list of policies that are applicable for the role. The object can reference the policy `ID` or `Name` attribute. - `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](#service-identities) for details. - `ServiceIdentities`: Specifies a list of services that are applicable for the role. See [Service Identities](#service-identities) for details.
- `NodeIdentities`: Specifies a list of nodes that are applicable for the role. See [Node Identities](#node-identities) for details. - `NodeIdentities`: Specifies a list of nodes that are applicable for the role. See [Node Identities](#node-identities) for details.
- `Namespace`: <EnterpriseAlert inline /> The namespace this policy resides within. Roles can only be linked to policies that are defined in the same namespace and admin partition. See [Namespaces](/docs/enterprise/namespaces) and [Admin Partitions](/docs/enterprise/admin-partitions) for additional information. Requires Consul Enterprise 1.7.0+. - `Namespace`: <EnterpriseAlert inline /> The namespace that the policy resides in. Roles can only be linked to policies that are defined in the same namespace. See [Namespaces](/docs/enterprise/namespaces) for additional information. Requires Consul Enterprise 1.7.0+
- `Partition`: <EnterpriseAlert inline/> 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](/docs/enterprise/admin-partitions) for additional information. Requires Consul Enterprise 1.10.0+.
## Service Identities ## Service Identities
@ -361,7 +362,7 @@ node "node-1" {
} }
# Allows the agent to detect and diff services registered to itself. This is used during # Allows the agent to detect and diff services registered to itself. This is used during
# anti-entropy to reconcile difference between the agents knowledge of registered # anti-entropy to reconcile differences between the agent's knowledge of registered
# services and checks in comparison with what is known in the Catalog. # services and checks in comparison with what is known in the Catalog.
service_prefix "" { service_prefix "" {
policy = "read" policy = "read"

2
website/content/docs/security/acl/acl-rules.mdx
View File

@ -7,7 +7,7 @@ description: >-
# Rules Reference # Rules Reference
This topic provides reference information for the types of access control level (ACL) rules you can create and how they affect access to datacenter resources. For details on how to create rules and group them into policies, see [Policies](/docs/security/acl/acl-policies). This topic provides reference information for the types of access control list (ACL) rules you can create and how they affect access to datacenter resources. For details on how to create rules and group them into policies, see [Policies](/docs/security/acl/acl-policies).
## Overview ## Overview

6
website/content/docs/security/acl/acl-tokens.mdx
View File

@ -13,19 +13,19 @@ This topic describes access control list (ACL) tokens, which are the core method
Tokens are artifacts in the ACL system used to authenticate users, services, and Consul agents. When ACLs are enabled, entities requesting access to a resource must include a token that has been linked with a policy, service identity, or node identity that grants permission to the resource. The ACL system checks the token and grants or denies access to resource based on the associated permissions. Tokens are artifacts in the ACL system used to authenticate users, services, and Consul agents. When ACLs are enabled, entities requesting access to a resource must include a token that has been linked with a policy, service identity, or node identity that grants permission to the resource. The ACL system checks the token and grants or denies access to resource based on the associated permissions.
Refer to the [ACL system workflow overview](/docs/security/acl/acl-system#workflow-overview) for an information about tokens' role in the ACL system. Refer to the [ACL system workflow overview](/docs/security/acl/acl-system#workflow-overview) for information about tokens' role in the ACL system.
## Creating Tokens ## Creating Tokens
The person responsible for administrating ACLs can use the API or CLI to create and link tokens to entities that enable permissions to resources. The person responsible for administrating ACLs can use the API or CLI to create and link tokens to entities that enable permissions to resources.
Refer to the [ACL API ](/api-docs/acl) and [ACL CLI](/commands/acl) documentation for instructions on how to create and link tokens. Tokens can also be created dynamically from trusted external system using an Refer to the [ACL API](/api-docs/acl) and [ACL CLI](/commands/acl) documentation for instructions on how to create and link tokens. Tokens can also be created dynamically from trusted external system using an
[auth method](/docs/security/acl/auth-methods). [auth method](/docs/security/acl/auth-methods).
## Passing Tokens ## Passing Tokens
Users deploying their services into the network or performing some operations in the Consul command line or GUI will need to include the value of the token's `SecretID` attribute. The `SecretID` is often referred to as the ACL token. It is an opaque string that identifies the requester so that the ACL system can determine if access to the requested resource should be granted or denied. Users deploying their services into the network or performing some operations in the Consul command line or GUI will need to include the value of the token's `SecretID` attribute. The `SecretID` is often referred to as the ACL token. It is an opaque string that identifies the requester so that the ACL system can determine if access to the requested resource should be granted or denied.
Tokens have several additional attributes. Refer to the (see [Token Attributes](#token-attributes)). Tokens have several additional attributes. Refer to [Token Attributes](#token-attributes) for details.
### Service Requests ### Service Requests

2
website/content/docs/security/acl/index.mdx
View File

@ -47,7 +47,7 @@ Refer to the following topics for details about tokens:
## Policies ## Policies
An ACL policy is a set of rules grant or deny access to resources in the network. An ACL policy is a set of rules that grant or deny access to resources in the network.
The person responsible for administrating ACLs in your organization will assemble and create policies and link them to tokens. The person responsible for administrating ACLs in your organization will assemble and create policies and link them to tokens.
Tokens are the artifacts distributed to users so that they can be implemented. Tokens are the artifacts distributed to users so that they can be implemented.
In addition to the rules that authenticate access to services, several attributes may be assigned policies that determine their scope. In addition to the rules that authenticate access to services, several attributes may be assigned policies that determine their scope.