Improving enrolment and security DX

[glenngillen]

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]

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:

• 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?

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

[glenngillen]

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

[mrinalwadhwa]

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:

• Orchestrator Project Admin creates the project.
• Orchestrator Project Admin enables InfluxDB add-on.
• Orchestrator Project Admin invites the InfluxDB Admin to the project and gives them ability to configure InfluxDB add-on and enroll members that have the attribute component=influxdb
• Orchestrator Project Admin invites the Telgraf Admin to the project and gives them ability enroll members that have the attribute component=telegraf

Hurdle

• We currently don't have a good UX for inviting InfluxDB Admin and Telgraf Admin.
• We left this out of the releases in September and November.
• The ideal UX is they get an email with a one-time use enrollment token and instructions to authenticate with it to get a credential.
  • This is an enrollement protocol. Enrollment protocols end in a issued credential. Some other examples https://miro.com/app/board/uXjVOtcT-9Y=/
• Until the ideal UX is ready, to tell the story, we could possibly use the current enrollment token workflow.
• In a large enough org, where Okta (or some other OAuth Identity Provider) add-on is already enabled. Email invitations may not be required and enrollment can happen based on attribute defined in Okta https://docs.ockam.io/use-cases/use-employee-attributes-from-okta-to-build-trust-with-cryptographically-verifiable-credentials

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?

• It should be the influxdb admin.
• The TTL should be set as a configuration property of the influxdb add-on on the ockam project.

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

• I think the ideal UX is they don't need to know about it at all.
• Until we have the ideal UX, it may okay to show the token can regenerated by issuing some command to the telegraf adjacent ockam node.

adding @polvorin @hairyhum @BeenzSyed

[caoakleyii]

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]