mirror of https://github.com/status-im/consul.git
Merge pull request #14589 from hashicorp/docs/search-desc-batch02
docs: Search Metadata Batch 02
This commit is contained in:
Jeff Boruszak
GitHub
commit
21621f314c
|
|
@ -1,12 +1,11 @@
|
|||
---
|
||||
layout: docs
|
||||
page_title: Configuration Entries
|
||||
page_title: How to Use Configuration Entries
|
||||
description: >-
|
||||
Consul allows storing configuration entries centrally to be used as defaults
|
||||
for configuring other aspects of Consul.
|
||||
Configuration entries define the behavior of Consul service mesh components. Learn how to use the `consul config` command to create, manage, and delete configuration entries.
|
||||
---
|
||||
|
||||
# Configuration Entries
|
||||
# How to Use Configuration Entries
|
||||
|
||||
Configuration entries can be created to provide cluster-wide defaults for
|
||||
various aspects of Consul.
|
||||
|
|
|
|||
|
|
@ -1,11 +1,11 @@
|
|||
---
|
||||
layout: docs
|
||||
page_title: Consul Agent CLI Reference
|
||||
page_title: Agents: CLI Reference
|
||||
description: >-
|
||||
This topic describes the supported options for configuring Consul agents on the command line.
|
||||
Add flags to the `consul agent` command to configure agent properties and actions from the CLI. Learn about configurable options and how to format them with examples.
|
||||
---
|
||||
|
||||
# Command-line Options ((#commandline_options))
|
||||
# Agents Command-line Reference ((#commandline_options))
|
||||
|
||||
-> **Note:** Some CLI arguments may be different from HCL keys. See [Configuration Key Reference](/docs/agent/config/config-files#config_key_reference) for equivalent HCL Keys.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,11 +1,11 @@
|
|||
---
|
||||
layout: docs
|
||||
page_title: Consul Agent Configuration Reference
|
||||
page_title: Agents: Configuration File Reference
|
||||
description: >-
|
||||
This topic describes the supported parameters for configuring Consul agents in HCL and JSON configuration files.
|
||||
Use agent configuration files to assign attributes to agents and configure multiple agents at once. Learn about agent configuration file parameters and formatting with this reference page and sample code.
|
||||
---
|
||||
|
||||
# Configuration Files ((#configuration_files))
|
||||
# Agents Configuration File Reference ((#configuration_files))
|
||||
|
||||
You can create one or more files to configure the Consul agent on startup. We recommend
|
||||
grouping similar configurations into separate files, such as ACL parameters, to make it
|
||||
|
|
|
|||
|
|
@ -1,13 +1,11 @@
|
|||
---
|
||||
layout: docs
|
||||
page_title: Configuration
|
||||
page_title: Agents: Configuration Explained
|
||||
description: >-
|
||||
The agent has various configuration options that can be specified via the
|
||||
command-line or via configuration files. All of the configuration options are
|
||||
completely optional. Defaults are specified with their descriptions.
|
||||
Agent configuration is the process of defining server and client agent properties with CLI flags and configuration files. Learn what properties can be configured on reload and how Consul sets precedence for configuration settings.
|
||||
---
|
||||
|
||||
# Configuration
|
||||
# Agent Configuration
|
||||
|
||||
The agent has various configuration options that can be specified via
|
||||
the command-line or via configuration files. All of the configuration
|
||||
|
|
|
|||
|
|
@ -1,13 +1,11 @@
|
|||
---
|
||||
layout: docs
|
||||
page_title: Agent
|
||||
page_title: Agents Overview
|
||||
description: >-
|
||||
The Consul agent is the core process of Consul. The agent maintains membership
|
||||
information, registers services, runs checks, responds to queries, and more.
|
||||
The agent must run on every node that is part of a Consul cluster.
|
||||
Agents maintain register services, respond to queries, maintain datacenter membership information, and make most of Consul’s functions possible. Learn how to start, stop, and configure agents, as well as their requirements and lifecycle.
|
||||
---
|
||||
|
||||
# Consul Agent
|
||||
# Agents Overview
|
||||
|
||||
This topic provides an overview of the Consul agent, which is the core process of Consul.
|
||||
The agent maintains membership information, registers services, runs checks, responds to queries, and more.
|
||||
|
|
|
|||
|
|
@ -1,11 +1,8 @@
|
|||
---
|
||||
layout: docs
|
||||
page_title: RPC
|
||||
page_title: Legacy RPC Protocol
|
||||
description: >-
|
||||
The Consul agent provides a complete RPC mechanism that can be used to control
|
||||
the agent programmatically. This RPC mechanism is the same one used by the CLI
|
||||
but can be used by other applications to easily leverage the power of Consul
|
||||
without directly embedding.
|
||||
Consul agents originally could be controlled through the RPC protocol. This feature was deprecated in version 0.8 in favor of the HTTP API. Learn about agent RPC interactions and how they worked.
|
||||
---
|
||||
|
||||
# RPC Protocol
|
||||
|
|
|
|||
|
|
@ -1,13 +1,11 @@
|
|||
---
|
||||
layout: docs
|
||||
page_title: Sentinel in Consul
|
||||
page_title: Sentinel ACL Policies (Enterprise)
|
||||
description: >-
|
||||
Consul Enterprise uses Sentinel to augment the built-in ACL system to provide
|
||||
advanced policy enforcement. Sentinel policies can currently execute on KV
|
||||
modify and service registration.
|
||||
Sentinel allows you to include conditional logic in access control policies. Learn how Consul can use Sentinel policies to extend the ACL system's capabilities for controlling key-value (KV) write access.
|
||||
---
|
||||
|
||||
# Sentinel Overview
|
||||
# Sentinel for KV ACL Policy Enforcement
|
||||
|
||||
<EnterpriseAlert />
|
||||
|
||||
|
|
|
|||
|
|
@ -1,13 +1,11 @@
|
|||
---
|
||||
layout: docs
|
||||
page_title: Telemetry
|
||||
page_title: Agents: Enable Metrics
|
||||
description: >-
|
||||
The Consul agent collects various runtime metrics about the performance of
|
||||
different libraries and subsystems. These metrics are aggregated on a ten
|
||||
second interval and are retained for one minute.
|
||||
Configure agent telemetry to collect operations metrics you can use to debug and observe Consul behavior and performance. Learn about configuration options, the metrics you can collect, and why they're important.
|
||||
---
|
||||
|
||||
# Telemetry
|
||||
# Agent Telemetry
|
||||
|
||||
The Consul agent collects various runtime metrics about the performance of
|
||||
different libraries and subsystems. These metrics are aggregated on a ten
|
||||
|
|
|
|||
|
|
@ -1,14 +1,11 @@
|
|||
---
|
||||
layout: docs
|
||||
page_title: Monitor Services - Check Definitions
|
||||
page_title: Configure Health Checks
|
||||
description: >-
|
||||
One of the primary roles of the agent is management of system- and
|
||||
application-level health checks. A health check is considered to be
|
||||
application-level if it is associated with a service. A check is defined in a
|
||||
configuration file or added at runtime over the HTTP interface.
|
||||
Agents can be configured to periodically perform custom checks on the health of a service instance or node. Learn about the types of health checks and how to define them in agent and service configuration files.
|
||||
---
|
||||
|
||||
# Checks
|
||||
# Health Checks
|
||||
|
||||
One of the primary roles of the agent is management of system-level and application-level health
|
||||
checks. A health check is considered to be application-level if it is associated with a
|
||||
|
|
|
|||
|
|
@ -1,13 +1,11 @@
|
|||
---
|
||||
layout: docs
|
||||
page_title: Find Services - DNS Interface
|
||||
page_title: Find services with DNS
|
||||
description: >-
|
||||
One of the primary query interfaces for Consul is DNS. The DNS interface
|
||||
allows applications to make use of service discovery without any high-touch
|
||||
integration with Consul.
|
||||
For service discovery use cases, Domain Name Service (DNS) is the main interface to look up, query, and address Consul nodes and services. Learn how a Consul DNS lookup can help you find services by tag, name, namespace, partition, datacenter, or domain.
|
||||
---
|
||||
|
||||
# DNS Interface
|
||||
# Query services with DNS
|
||||
|
||||
One of the primary query interfaces for Consul is DNS.
|
||||
The DNS interface allows applications to make use of service
|
||||
|
|
|
|||
|
|
@ -1,16 +1,11 @@
|
|||
---
|
||||
layout: docs
|
||||
page_title: Register Services - Service Definitions
|
||||
page_title: Register Services with Service Definitions
|
||||
description: >-
|
||||
One of the main goals of service discovery is to provide a catalog of
|
||||
available services. To that end, the agent provides a simple service
|
||||
definition format to declare the availability of a service and to potentially
|
||||
associate it with a health check. A health check is considered to be
|
||||
application level if it is associated with a service. A service is defined in
|
||||
a configuration file or added at runtime over the HTTP interface.
|
||||
Define and register services and their health checks with Consul to make a service available for service discovery or service mesh access. Learn how to format service definitions with this reference page and sample code.
|
||||
---
|
||||
|
||||
# Services
|
||||
# Register Services with Service Definitions
|
||||
|
||||
One of the main goals of service discovery is to provide a catalog of available
|
||||
services. To that end, the agent provides a simple service definition format
|
||||
|
|
|
|||
|
|
@ -1,9 +1,8 @@
|
|||
---
|
||||
layout: docs
|
||||
page_title: Consul Tools
|
||||
description: |-
|
||||
From this page you can download various tools for Consul. These tools are
|
||||
maintained by HashiCorp and the Consul Community.
|
||||
description: >-
|
||||
Consul's capabilities can be extended through integration with other tools. Learn about Consul-related tools created by HashiCorp and by the Consul community.
|
||||
---
|
||||
|
||||
# Download Consul Tools
|
||||
|
|
|
|||
|
|
@ -1,7 +1,8 @@
|
|||
---
|
||||
layout: docs
|
||||
page_title: Network Infrastructure Automation Integration Program
|
||||
description: Guide to partnership integrations for Consul NIA
|
||||
page_title: Network Infrastructure Automation (NIA) Integration Program
|
||||
description: >-
|
||||
The Network Infrastructure Automation (NIA) Integration Program allows partners to develop Terraform modules for Consul-Terraform-Sync (CTS) that HashiCorp reviews to consider publishing as officially verified. Learn about how to participate in the program.
|
||||
---
|
||||
|
||||
# Network Infrastructure Automation Integration Program
|
||||
|
|
|
|||
|
|
@ -1,7 +1,8 @@
|
|||
---
|
||||
layout: docs
|
||||
page_title: Consul Integration Program
|
||||
description: Guide to partnership integrations for Consul.
|
||||
description: >-
|
||||
The Consul Integration Program allows approved partners to develop Consul integrations that HashiCorp reviews to consider publishing as officially verified. Learn about how to participate in the program.
|
||||
---
|
||||
|
||||
# Consul Integration Program
|
||||
|
|
|
|||
|
|
@ -1,8 +1,8 @@
|
|||
---
|
||||
layout: docs
|
||||
page_title: ACL in Federated Datacenters
|
||||
page_title: ACL Setup for WAN Federated Datacenters
|
||||
description: >-
|
||||
This topic describes the specific ACL bootstrapping policies that are necessary when ACLs are enabled for federated, multi-datacenter deployments.
|
||||
Consul's access control list (ACL) system can span multiple datacenters that are WAN federated. Learn how to replicate the ACL system from the primary datacenter to secondary datacenters using a replication token.
|
||||
---
|
||||
|
||||
# ACLs in Federated Datacenters
|
||||
|
|
|
|||
|
|
@ -1,11 +1,8 @@
|
|||
---
|
||||
layout: docs
|
||||
page_title: ACL System (Legacy Mode)
|
||||
page_title: Legacy ACL System
|
||||
description: >-
|
||||
Consul provides an optional Access Control List (ACL) system which can be used
|
||||
to control access to data and APIs. The ACL system is a Capability-based
|
||||
system that relies on tokens which can have fine grained rules applied to
|
||||
them. It is very similar to AWS IAM in many ways.
|
||||
Consul's legacy ACL system was deprecated in version 1.4.0 and removed in version 1.11.0. Learn how Consul's legacy ACL system worked and how it differs from the current ACL system.
|
||||
---
|
||||
|
||||
# ACL System in Legacy Mode
|
||||
|
|
|
|||
|
|
@ -1,13 +1,8 @@
|
|||
---
|
||||
layout: docs
|
||||
page_title: ACL Token Migration
|
||||
page_title: Legacy ACL Token Migration
|
||||
description: >-
|
||||
Consul 1.4.0 introduces a new ACL system with improvements for the security
|
||||
and
|
||||
|
||||
management of ACL tokens and policies. This guide documents how to upgrade
|
||||
|
||||
existing (now called "legacy") tokens after upgrading to 1.4.0.
|
||||
Migrate legacy tokens when updating to Consul 1.4.0+ from earlier versions to use the current ACL system. Learn about the migration process, how to update tokens, and examples for creating policies.
|
||||
---
|
||||
|
||||
# ACL Token Migration
|
||||
|
|
|
|||
|
|
@ -2,10 +2,10 @@
|
|||
layout: docs
|
||||
page_title: ACL Policies
|
||||
description: >-
|
||||
This topic describes policies as used in Consul's access control list (ACL) system. A policy is a group of one or more ACL rules that define which services and agents are authorized to communicate with other resources in the network.
|
||||
ACL policies define access control rules for resources in Consul. When an ACL token is submitted with a request, Consul authorizes access based on the token's associated policies. Learn how to format and combine rules into policies and apply them to tokens.
|
||||
---
|
||||
|
||||
# Policies
|
||||
# ACL Policies
|
||||
|
||||
This topic describes policies, which are components in Consul's access control list (ACL) system. Policies define which services and agents are authorized to interact with resources in the network.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,12 +1,11 @@
|
|||
---
|
||||
layout: docs
|
||||
page_title: Roles
|
||||
page_title: ACL Roles
|
||||
description: >-
|
||||
This topic describes roles within the access control list (ACL) system. A role is a named set of policies and service identities.
|
||||
They enable you to reuse policies by decoupling the policies from the token distributed to team members.
|
||||
Roles are a named collection of ACL policies, service identities, and node identities. Learn how roles allow you to reuse and update access control policies without needing to distribute new tokens to users.
|
||||
---
|
||||
|
||||
# Roles
|
||||
# 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.
|
||||
|
|
|
|||
|
|
@ -1,11 +1,11 @@
|
|||
---
|
||||
layout: docs
|
||||
page_title: ACL Rules Reference
|
||||
page_title: ACL Rules
|
||||
description: >-
|
||||
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.
|
||||
Rules define read, write, and deny access controls for datacenter resources. Learn about these resources and how to assign rules to them, as well as their restrictions and API interactions.
|
||||
---
|
||||
|
||||
# Rules Reference
|
||||
# ACL Rules
|
||||
|
||||
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).
|
||||
|
||||
|
|
|
|||
|
|
@ -1,11 +1,11 @@
|
|||
---
|
||||
layout: docs
|
||||
page_title: Tokens
|
||||
page_title: ACL Tokens
|
||||
description: >-
|
||||
This topic describes access control list (ACL) tokens. Tokens are the core method of authentication in Consul.
|
||||
Tokens are used to authenticate users, services, and agents and authorize their access to resources in Consul. Learn about token attributes, special-purpose and built-in tokens, and how to pass a token’s SecretID in the CLI and API.
|
||||
---
|
||||
|
||||
# Tokens
|
||||
# ACL Tokens
|
||||
|
||||
This topic describes access control list (ACL) tokens, which are the core method of authentication in Consul.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,8 +1,8 @@
|
|||
---
|
||||
layout: docs
|
||||
page_title: Access Control List (ACL) Overview
|
||||
page_title: Access Control List (ACL): Overview
|
||||
description: >-
|
||||
This topic describes provides an overview of the optional access control list (ACL) system shipped with Consul. The ACL system authenticates requests and authorizes access to resources. It is used by the UI, API, and CLI for service-to-service communication and agent-to-agent communication.
|
||||
Consul's ACL system secures communication and controls access to the API, CLI, and UI. Learn about ACL components and how they interact to authenticate requests and authorize access for your network.
|
||||
---
|
||||
|
||||
# Access Control List (ACL) Overview
|
||||
|
|
|
|||
|
|
@ -1,10 +1,8 @@
|
|||
---
|
||||
layout: docs
|
||||
page_title: Encryption
|
||||
page_title: Encryption Systems
|
||||
description: >-
|
||||
The Consul agent supports encrypting all of its network traffic. The exact
|
||||
method of encryption is described on the encryption internals page. There are
|
||||
two separate encryption systems, one for gossip traffic and one for RPC.
|
||||
Consul supports encrypting all of its network traffic. Remote Process Calls (RPCs) between client and server agents can be encrypted with TLS and authenticated with certificates. Gossip communication between all agents can also be encrypted.
|
||||
---
|
||||
|
||||
# Encryption
|
||||
|
|
|
|||
|
|
@ -1,12 +1,8 @@
|
|||
---
|
||||
layout: docs
|
||||
page_title: Security
|
||||
page_title: Security: Overview
|
||||
description: >-
|
||||
Consul relies on both a lightweight gossip mechanism and an RPC system to
|
||||
provide various features. Both of the systems have different security
|
||||
mechanisms that stem from their designs. However, the security mechanisms of
|
||||
Consul have a common goal: to provide confidentiality, integrity, and
|
||||
authentication.
|
||||
Security requirements and recommendations for Consul vary depending on workloads and environments. Learn how ACLs and encryption can protect access to and communication within your datacenter.
|
||||
---
|
||||
|
||||
## Security Models
|
||||
|
|
|
|||
|
|
@ -1,8 +1,8 @@
|
|||
---
|
||||
layout: docs
|
||||
page_title: Consul Core Security Model
|
||||
page_title: Security Models: Consul
|
||||
description: >-
|
||||
Security model including requirements, recommendations, and threats for the core Consul product.
|
||||
The security model for Consul Core details requirements and recommendations for securing your deployment of Consul. Learn about potential threats and how to protect Consul from malicious actors.
|
||||
---
|
||||
|
||||
## Overview
|
||||
|
|
|
|||
|
|
@ -1,8 +1,8 @@
|
|||
---
|
||||
layout: docs
|
||||
page_title: Security Models
|
||||
page_title: Security Models: Overview
|
||||
description: >-
|
||||
Overview and links to various Consul security models.
|
||||
Security models are the set of requirements and recommendations for securely operating a Consul deployment. Learn about security models and how they differ between environments.
|
||||
---
|
||||
|
||||
## Overview
|
||||
|
|
|
|||
|
|
@ -1,8 +1,8 @@
|
|||
---
|
||||
layout: docs
|
||||
page_title: Consul NIA Security Model
|
||||
page_title: Security Models: Network Infrastructure Automation (NIA)
|
||||
description: >-
|
||||
Security model including requirements, recommendations, and threats for Consul Network Infrastructure Automation (NIA).
|
||||
The NIA security model details requirements and recommendations for securing your Consul-Terraform-Sync (CTS) deployment. Learn about potential threats and how to protect CTS from malicious actors.
|
||||
---
|
||||
|
||||
## Overview
|
||||
|
|
|
|||
Loading…
Reference in New Issue