clarify documentation about encrypt parameter

[lesinigo]

I have observed (with consul-1.0.2 which is current at the time of this writing) that after an agent has completed joining an encrypt-enabled cluster I can remove the encrypt parameter from the agent configuration and it will keep working correctly, even after a restart.

It is my understanding that the encrypt parameter is needed only at join time and after that the agent will persist whatever data it needs in the local keyring - as is also referenced in issue #1299 for an older version. On the other hand, documentation is a little vague about this and seems to imply to always leave the encrypt parameter in the agent configuration and I don't know if there is any other scenario where an agent would need that parameter even after a successful join.

I have not tried keeping an agent disconnected from the cluster for a long time and I had not done any test on consul servers.

After bootstrapping the consul servers should I keep the encrypt parameter on them, or should it be removed?
And what about agents, should I remove the parameter after they have joined the cluster?

A clarification would be appreciated, and IMHO the documentation should be updated to explicitly say:

• to keep the parameter configured (if there is any need for that)
• to remove the parameter if it is not needed
• what is the threat model if a node without the encrypt parameter on it gets compromised (and the attacker gains access to that node local.keyring) ?

[slackpad]

Hi @lesinigo once you've rotated the key it doesn't hurt to leave the parameter there, but I think you are correct that it can be removed once the local keyring file is established.

what is the threat model if a node without the encrypt parameter on it gets compromised (and the attacker gains access to that node local.keyring) ?

If an attacker got a hold of the encryption keys they could join the cluster and send spurious gossip messages (like causing leave and rejoin of servers, etc.). If the key gets compromised you'd need to rotate it out on the rest of the nodes.

We can definitely improve the documentation around this.

[lesinigo]

@slackpad so if I understand it correctly, from a security standpoint having someone reading the encryption config value from the configuration file or reading the local.keyring file is exactly the same, it that correct?

By extension I'd then say that assuming local.keyring is only readable by a consul user and the config file is only readable by the same user, then leaving encryption in there does not worsen the possible attack surface.

(related to this: maybe some documentation about how to rotate the encryption key of a whole cluster could be of help)

[preetapan]

By extension I'd then say that assuming local.keyring is only readable by a consul user and the config file is only readable by the same user, then leaving encryption in there does not worsen the possible attack surface.

Yes - the same user owns both the config file and the data directory where local.keyring is stored, so you are compromised when the consul user is compromised and leaving the encryption key in the config doesn't make it worse.

You can use consul keyring to manage encryption keys. See -
https://www.consul.io/docs/commands/keyring.html#install for more information. You should be able to add scripting around this command to periodically rotate your keys.

Also, we are working on making keyring management fully automated in a future release.

[samsonkolge]

@preetapan Just curious, do we have the keyring management in place yet?

[hanshasselberg]

nothing automated yet. But since the original issues was resolved, I will close this issue now.