consulconsul-templategossip

Concept of remote controling several consul stacks securely


Introduction

I am running multiple, i call them consul-stacks. They do always look like: - 1 consul server - 9 consul nodes

Each node offers some services - just a classic web-stack and more (not interesting for this question). Gossip is used to protect the server getting queried by arbitrary nodes and reveal data. Several consul-template / tiller "watchers" are waiting to dynamically configure the nodes/services on KV changes

Goal

Lets say i have 10 of those stacks ( number is dynamic ) and i want to build a web-app controlling the consul-KV of each stack using a specific logic

What i have right now

I have created a thor+diplomat tool to wrap the logic i need to create specific KV entries. I implemented it while running it on the "controller" container in the stack, talking to localhost:8500 - which then authenticates with gossip and writes to the server.

Question

What concept would i now use to move this tool a remote ( not part of the consul-stack ) server, while being able to write into each consul-stacks KV.

Sure, i can use diplomat to connect to stack1.tld:8500 - but this would mean i open the HTTP port and need to secure it somehow ( not protected by gossip? somehow, only RPC? ) and also protect the /ui.

In general, without using TLS ( which needs to much work for the clients to setup ), what concepts would fit this need communicating to the stack-server to write into its KV, securely.

If i missed something, happy to add anything you ask for


Solution

  • The answer on this is

    1. Enable ACLs on the consul-server

    { "acl_datacenter": "stable", "acl_default_policy": "deny", "acl_down_policy": "deny" }

    1. Create a general acl token with write/write/write

    consul-cli acl create --management=false --name="general_node" --rule "key::write" --rule "event::write" --rule "service::write" --token=<master-token> Ensure to use your master-token here, created during the server start

    1. Optionally also configure gossip to let your clients communicate encrypted ( otherwise ACLs kind of not make sense )

    2. Add the general token to the consul-client you use remotely to be able to talk to the remote consul - since this consul will no longer be publicly doing anything ( without token )