search

build-trust / demo-influxdb-telegraf

1 stars 0 forks source link

Improving enrolment and security DX #1

Open glenngillen opened 1 year ago

glenngillen commented 1 year ago

As it stands, here's a summary of how a Telegraf instance connects to InfluxDB via Ockam (skipping the initial Orchestrator setup).

First, an Ockam Admin needs to create an enrolment token for the Influx node:

INFLUXDB_TOKEN=$(ockam project enroll --to /project/$PROJECT_NAME/service/authenticator --attribute component=influxdb)

Then the InfluxDB Admin can use that to create + enroll a node, set a policy to only allow access from a Telegraf node, create a TCP outlet, and finally create a forwarder:

NODE="influxdb"
ockam node create $NODE --project /config/project.json --enrollment-token $OCKAM_TOKEN
ockam policy set --at $NODE --resource tcp-outlet --expression '(= subject.component "telegraf")'
ockam tcp-outlet create --at /node/$NODE --from /service/outlet --to 127.0.0.1:8086
ockam forwarder create $NODE --at /project/$OCKAM_PROJECT_NAME --to /node/$NODE

Once that's running the Ockam Admin can then create an enrolment token for the Telegraf node:

export TELEGRAF_TOKEN=$(ockam project enroll --to /project/$PROJECT_NAME/service/authenticator --attribute component=telegraf)

and the Telegraf Admin can use that to create + enroll a node, set a policy, create an inlet so that Telegraf can connect to the local node and have packets forwarded to InfluxDB:

NODE="telegraf"
ockam node create $NODE --project /config/project.json --enrollment-token $OCKAM_TOKEN
ockam policy set --at $NODE --resource tcp-inlet --expression '(= subject.component "influxdb")'
sleep 30
ockam tcp-inlet create --at /node/$NODE --from 127.0.0.1:8086 --to /project/$OCKAM_PROJECT_NAME/service/forward_to_influxdb/secure/api/service/outlet

This will work and successfully have data transferred via the secure channel, but only because the Telegraf config is hard-coded to use the InfluxDB admin token. Wouldn't it be great if instead of hard-coding the token into the Telegraf config, Telegraf could instead delegate authentication to Ockam as part of the setup of creating the secure channel. Instead of using a broad privilege and perpetual token, a token with a lesser scope and a TTL could be issued. Without the need for code, config, or network topology changes on either the InfluxDB or Telegraf side.

glenngillen commented 1 year ago

I've split out a few different personas here, which is likely inaccurate for a lot of situations. I figure at a very large company though it becomes more likely these are 3 different people and so if we can accomodate that we'll have a good set of primitives to work with.

So my questions are:

@mrinalwadhwa keen to know what you've been thinking.

glenngillen commented 1 year ago

...+ @CAOakleyII given you've already started thinking about the lease interface on the CLI.

mrinalwadhwa commented 1 year ago

Nice, @glenngillen thank for putting this together.

Places Involved

Let's break this down even further. There are six places involved for the three personas (Orchestrator Project Admin, InfluxDB Admin, Telgraf Admin)

  1. Orchestrator Project Admin's Workstation.
    • setup as project enroller with project authority when the project is created.
  2. Orchestrator Project node.
    • setup as project member with project authority when the project is created.
  3. InfluxDB Admin's Workstation.
  4. InfluxDB Node
    • enrolled using enrollment tokens.
  5. Telgraf Admin's Workstation
  6. Telegraf Node(s)
    • enrolled using enrollment tokens.

Ideal Flow

So the ideal flow should look like this:

Hurdle

Glenn's Questions

Who'd set the scope and TTL on a token? Should it be the InfluxDB admin? Is it then somehow attached to the policy that is already being set?

Does the Telegraf node ever need to know about tokens? Or are we going to intercept and override if/where it's required?

adding @polvorin @hairyhum @BeenzSyed

caoakleyii commented 1 year ago

I will add to this discussion that the concept of a Token Lease Manager seems to be some what separate from the entire implementation of InfluxDb + Telegraf.

With that also being said, i'd imagine the lease manager structure could be platform agnostic at a higher level, and allow for specific configurations as the command drills down.

e.g.

# base lease command
# the help here will indicate which lease actions are available. [create, show, list, revoke]
ockam lease

# an example of creating a token within our token lease management system
# for influxdb. 
# I believe there will be some required options across all commands (e.g. project id)
ockam lease create influxdb [addon-specific-options]