Announcing: Time-Based, Revocable, Leased – Dynamic Access Credentials for InfluxDB

By Community / Product
Apr 11, 2023

This article, written by Glenn Gillen, was originally published on the Ockam blog and is reposted here with permission.

Automated token management for InfluxDB Cloud

Today we’re excited to announce the InfluxDB add-on for Ockam Orchestrator. Through the use of the add-on, customers that are using InfluxDB Cloud can use Ockam to improve their security posture by automatically granting uniquely identifiable, least privilege, time-limited credentials for any client that needs to connect to InfluxDB Cloud.

The problem with managing access at scale

Managing client access credentials for thousands of discrete clients can be a challenge for customers at scale. Issuing unique credentials to each client can be such an operational burden that we’ve seen some companies opt to have a single credential that is shared across all their client services and devices. This trade-off though comes with an increase in risk: any one of those thousands of clients could potentially expose the same secrets used by the whole fleet. It also increases the operational burden of remediation when one of those credentials is exposed: you’re now scrambling to work out how to revoke and deploy new credentials to your entire fleet all at once. Instead industry best-practice would recommend regularly auditing and rotating those credentials to reduce the risk to the business. That regular revocation and rotation results in an on-going operational complexity that only continues to increase as the number of clients grows.

The InfluxDB add-on for Ockam Orchestrator is a drop-in solution that works with any InfluxDB client. It allows an organization to define a standardized policy that defines uniquely identifiable, least privilege, time-limited credentials appropriate for their use case. Each client can then request its own credential which, if granted, can then be used wherever existing InfluxDB credentials are used. The time-limited nature means that when the lease period expires the credential is automatically revoked, and the client can request a new one to continue communicating.

Let’s take a look at just a couple of examples of what’s now possible, and how to achieve it.

Initial setup of Ockam

If you’ve previously setup Ockam you can skip this section and move straight to the two examples below.

brew install build-trust/ockam/ockam

(if you’re not using brew for package management we have installation instructions for other systems in our documentation)

Once installed you need to enroll your local identity with Ockam Orchestrator, run the command below and follow the instructions provided:

ockam enroll

Enroll clients at scale

Log in to your InfluxDB Cloud Dashboard and get the Cluster URL (Host Name) and Organization ID from your Organization settings page, then generate a new All Access API token (Load Data > API Tokens > Generate API Token > All Access API Token). Take those three values and insert them into the appropriate environment variables below so we can use them later:

export INFLUXDB_ADMIN_TOKEN="infludb-cloud-token-here"
export INFLUXDB_ORG_ID="influxdb-org-id-here"
export INFLUXDB_ENDPOINT_URL="https://your-cluser-url-here"
export INFLUXDB_BUCKET="bucket-name-here"

Next we’ll save project information to a JSON file so that we can use it later when registering our client nodes:

ockam project information --output json default > project.json

Now it’s time to integrate Ockam and InfluxDB Cloud! We’ll do that by configuring the add-on to use the configuration settings we exported early, in addition to defining a default set of permissions each future lease request should be granted.

read -r -d '' INFLUXDB_LEASE_PERMISSIONS <<- EOF
[{"action": "write", 
  "resource": {
    "type": "buckets", 
    "name": "$INFLUXDB_BUCKET",
    "orgID": "$INFLUXDB_ORG_ID"
}}]
EOF

To save you having to unpack all of that: it’s an InfluxDB permission definition (in JSON format) that only grants the ability to write to a specific bucket on a specific Org. Clients with this permission will be unable to read any data, modify permissions, etc.

ockam project addon configure influx-db \
  --endpoint-url $INFLUXDB_ENDPOINT_URL \
  --token $INFLUXDB_ADMIN_TOKEN \
  --org-id $INFLUXDB_ORG_ID \
  --permissions "$INFLUXDB_LEASE_PERMISSIONS" \
  --max-ttl 900

Before a client can connect to a project, an enrollment token must be generated for it by an authorized entity:

export VEHICLE_TOKEN=$( \
  ockam project enroll \
  --attribute service=connected-vehicle )

Next we need to create a new identity for our client, as it’s to this identity that the leased InfluxDB token will be issued. In a production environment you would run these next 3 steps on your intended your intended client, in our case the connected vehicle, but for demo purposes we’ll run them all from the same machine:

ockam identity create connected-vehicle

Identity created, we can authenticate to our project (using the JSON configuration file we created earlier) and the enrolment token SENSOR_TOKEN we saved at the start of this section:

ockam project authenticate \
  --identity connected-vehicle \
  --project-path project.json \
  --token $VEHCILE_TOKEN

We’ve arrived at the big moment, time to request a new lease:

ockam lease create \
  --identity connected-vehiclez \
  --project-path project.json

In the output you’ll see not just the token you created but when it expires, which should be 15 minutes from the time it was created (we set the max TTL to 900 seconds in the original ockam addon configure command).

Grant temporary read access

What if we wanted to grant someone from our data science or operations teams access to read the data? We could take the same approach as in the previous example, but simply change the permissions and the lease timeout:

read -r -d '' INFLUXDB_LEASE_PERMISSIONS <<- EOF
[{"action": "read", 
  "resource": {
    "type": "buckets", 
    "name": "$INFLUXDB_BUCKET",
    "orgID": "$INFLUXDB_ORG_ID"
}}]
EOF

This is the same permission definition we used earlier except the write access has been replaced with read.

Next we’ll configure the add-on, but this time we’ll set the time-to-live (TTL) on the issued credentials to be 7 days instead of 15 minutes:

ockam project addon configure influx-db \
  --endpoint-url $INFLUXDB_ENDPOINT_URL \
  --token $INFLUXDB_ADMIN_TOKEN \
  --org-id $INFLUXDB_ORG_ID \
  --permissions "$INFLUXDB_LEASE_PERMISSIONS" \
  --max-ttl 604800

As before we will generate a token to allow this person to enroll, and then create and enroll them:

export USER_TOKEN=$( \
  ockam project enroll \
  --attribute service=data-user)

ockam identity create alice

ockam project authenticate \
  --identity alice \
  --project-path project.json \
  --token $USER_TOKEN

Now any time this person needs to request access to query InfluxDB Cloud they can request a new set of credentials by running:

ockam lease create \
  --identity alice \
  --project-path project.json

Unique, time-limited, and least privilege access

You’ve hopefully seen from these examples that in just a few minutes you can go through the complete Ockam setup process and implement an improved credential management policy for your InfluxDB Cloud clients. One that reduces your risk by issuing unique per-client credentials. Credentials that are limited in both scope and duration to whatever is most appropriate for the needs of your clients. And credentials that work as a seamless alternative for all of your existing InfluxDB client use cases.

Get started

If you’ve not already followed the example in this guide, you can get started using Ockam for free by following the instructions in our documentation. If you’d like to talk specifically about this or other potential use cases for Ockam, the team would be more than happy to chat with you. Alternatively you can join us, and an ever growing community of developers who want to build trust by making applications that are secure-by-design, in the Build Trust Discord server.