CE-654 - TLS Encryption docs + CE-713 - Gossip Encryption key rotation

[danielehc]

Jira tickets reference

• CE-654 TLS Encryption docs
• CE-654 Gossip Encryption rotation docs

Description

• Porting of Secure Consul agent communication with TLS encryption and Rotate gossip encryption keys in Consul into documentation.
• Refactoring of the encryption section.

🎪 Preview

⚠️ When reviewing, please also review https://github.com/hashicorp/tutorials/pull/2259

[boruszak]

Looking great so far. The only page I still need to review is the encryption/mtls page.

[boruszak]

Suggested change

	The Consul agent supports encryption for all of its network traffic. There are two separate encryption systems, one for gossip
	traffic and one for HTTP + RPC. The [Encryption](/consul/docs/security/encryption) section describes the logic behind these two different encryption systems and provides configuration guidance for them.
	The Consul agent supports encryption for all of its network traffic. There are two separate encryption systems:
	- A gossip encryption system
	- An mTLS encryption system for HTTP and RPC
	For more information about these two different encryption systems, as well as configuration guidance, refer to [Consul encryption](/consul/docs/security/encryption).

I think the unordered list is appropriate here to help emphasize the two encryption systems.

[boruszak]

Match page title after responding to suggestion.

[boruszak]

Suggested change

	This topic describes the two different encryption systems available in Consul to secure network traffic, Gossip encryption and mTLS.
	[Consul security model](/consul/docs/security/security-models/core) defines the guidelines for operating a secure Consul deployment. Its recommendations are applicable only if all parts of the system are running with a secure configuration.
	[Gossip Encryption](/consul/docs/security/encryption#gossip-encryption) and [Mutual TLS Encryption](/consul/docs/security/encryption#mutual-tls-mtls-encryption) are the foundations for a secure Consul datacenter.
	This topic provides an overview of the two distinct encryption systems available in Consul. [Gossip encryption](/consul/docs/security/encryption#gossip-encryption) and [Mutual TLS encryption](/consul/docs/security/encryption#mutual-tls-mtls-encryption) are the foundations of a secure Consul datacenter.
	The guidelines in the [Consul security model](/consul/docs/security/security-models/core) for operating a secure Consul deployment recommends using both encryption systems.

Re-orders sentences to avoid the jump back and forth between the security model and the encryption systems

[boruszak]

Suggested change

	Consul uses a [gossip protocol](https://en.wikipedia.org/wiki/Gossip_protocol) to manage membership and broadcast messages to the cluster.
	Consul uses a [gossip protocol](/consul/docs/architecture/gossip) to perform the following cluster operations:

[boruszak]

Suggested change

	Once all agents have received the key and are able to use it as the primary encryption key, it is possible to promote the new key to primary.
	After all agents recognize the key, it is possible to promote it to be the new primary encryption key.

[boruszak]

Suggested change

	To avoid unused keys remaining in the keyring, we recommended you remove the old primary from the keyring once a new key is installed.
	Unused keys in the keyring are a potential security risk to your Consul cluster. We recommended that you remove the former primary key from the keyring after a new key is installed.

[boruszak]

Suggested change

Documentation for the commands used in this topic is available at [Consul agent configuration - Encryption Parameters](/consul/docs/agent/config/config-files#encryption-parameters). You can find more information over the gossip protocol used by Consul at [Gossip Protocol](/consul/docs/architecture/gossip).

Not really "next steps" - I suggest removing this sentence.

[danielehc]

I see your point but I think is always useful to have a place where some links to the documentation/reference for the commands shown is located.

[boruszak]

Suggested change

	After enabling gossip encryption, to continue securing your Consul datacenter, enable mutual TLS encryption. Read more on [Mutual TLS (mTLS) Encryption](/consul/docs/security/encryption/mtls).
	After you enable gossip encryption, you can continue to process to secure your Consul datacenter by enabling mutual TLS encryption. For more information, refer to [Mutual TLS (mTLS) Encryption](/consul/docs/security/encryption/mtls).

[boruszak]

Suggested change

	To learn how to automate gossip key rotation using HashiCorp Vault and consul-template, refer to the [Automatically Rotate Gossip Encryption Keys Secured in Vault](/consul/tutorials/operate-consul/vault-kv-consul-secure-gossip) tutorial.
	To learn how to automate gossip key rotation using HashiCorp Vault and consul-template, refer to the [Automatically Rotate Gossip Encryption Keys Secured in Vault tutorial](/consul/tutorials/operate-consul/vault-kv-consul-secure-gossip).

[boruszak]

Suggestions for the mTLS page to complete my review.

[boruszak]

Suggested change

	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.
	Consul supports encrypting all of its network traffic. Learn how to encrypt and authenticate Remote Process Calls (RPCs) between client and server agents with TLS certificates.

[boruszak]

Suggested change

	This topics describes how to enable Mutual TLS (mTLS) encryption on a Consul datacenter.
	The content in this page is not referred to Consul service mesh mTLS encryption. For documentation about Consul service mesh Certification authority refer to [Service Mesh Certificate Authority](/consul/docs/connect/ca) documentation.
	This topic describes mutual TLS (mTLS) encryption between agents in a Consul datacenter.
	This mTLS encryption is distinct from Consul service mesh mTLS encryption. To learn about encrypted mTLS communication between services, refer to [service mesh certificate authority](/consul/docs/connect/ca).

[boruszak]

Suggested change

	Consul supports the use of TLS certificates to secure the traffic related to the `RCP`, `gRPC`, and `HTTP` communications and to verify the authenticity of servers and clients.
	Consul supports TLS certificates that verify the authenticity of servers and clients to secure `RCP`, `gRPC`, and `HTTP` traffic.

Simplifying sentence

[boruszak]

Suggested change

	If you want to avoid the need to present a valid client certificate every time you need to interact with Consul API, CLI, or UI, it is possible to configure Consul to trust all incoming HTTPs connections. Setting `tls.https.verify_incoming` to `false` removes the need to present a client certificate. RCP communications are still mTLS encrypted.
	If you want to avoid the need to present a valid client certificate every time you interact with Consul using the HTTP API, CLI, or UI, configure Consul to trust all incoming HTTPS connections by seting `tls.https.verify_incoming` to `false`. RPC communications are still mTLS encrypted.

[boruszak]

Suggested change

If you want to avoid the need to present a valid client certificate or to use the CA certificate every time you need to interact with your local Consul agent, it is possible to configure Consul to keep the HTTP listener only active on the `localhost` interface. External requests to the API or the UI will still be TLS protected but setting `tls.https.verify_incoming` to `false` removes the need to present a client certificate. RCP communications are still mTLS encrypted.

If you want to avoid the need to present a valid client certificate or to use the CA certificate every time you interact with the local Consul agent, configure Consul to keep the HTTP listener active on the `localhost` interface only and set `tls.https.verify_incoming` to `false`. External requests to the API or UI are still protected by TLS encryption, requests that originate locally do not need to present a client certificate. RPC communications are still mTLS encrypted.

[boruszak]

Suggested change

	After completing the steps in this topic, your agents will be configured with TLS for encrypted communication. With the auto encryption method, your
	client certificates are managed by the server. With the operator method, you distributed all the certificates, but have a more flexible configuration.
	Your agents are now configured with mTLS for encrypted communication. With the auto encryption method, your
	client certificates are managed by the server. With the operator method, you distributed all the certificates manually, but have a more flexible configuration.

[boruszak]

Suggested change

	Documentation for the commands used in this topic is available at [Consul agent configuration - TLS configuration reference](/consul/docs/agent/config/config-files#tls-configuration-reference) documentation and at the [`consul tls` CLI command reference](/consul/commands/tls).
	Documentation for the commands used in this topic is available at [Consul agent configuration - TLS configuration reference](/consul/docs/agent/config/config-files#tls-configuration-reference) and the [`consul tls` CLI command reference](/consul/commands/tls).

[boruszak]

Suggested change

	The other prerequisites for a secure Consul deployment are [gossip encryption](/consul/docs/security/encryption/gossip) and [Access Control Lists (ACLs)](/consul/docs/security/acl) with default deny policy.
	To continue securing your Consul deployment, add [gossip encryption](/consul/docs/security/encryption/gossip) and enable [Access Control Lists (ACLs)](/consul/docs/security/acl) with the default deny policy.

[boruszak]

Absolutely fabulous work.