Using Secret Stores to Secure Flux Access

Navigate to:

Multi-data source Flux opens up endless variations in time series analysis, but as with all data access, new communications open potential attack vectors for shady actors. To secure your sensitive credentials, use InfluxDB’s integrated secret store and Flux’s new secrets library.

Keep the keys to the kingdom secret

If you follow my multi-data source Flux journey you have seen some exciting possibilities introduced by combining multiple data stores and time series analysis.  However, if you look closely at my SQL Flux scripts, you may notice something unsettling — the Flux to connect external data stores avoids usernames and passwords and is in plaintext.

Simple data access methods when developing are acceptable, but when it comes to sensitive production data stores we all must be vigilant in protecting our information. Flux assists in this protection by integrating with secret stores to help you keep the secrets to your kingdom secret.

InfluxDB Cloud 2's secret store

Our InfluxDB Cloud 2 service is integrated with the industry-leading Vault secret store to provide every customer with a secure secret store. Users can store secrets, list their keys, and delete secrets using our fully documented API. As an example, these curl commands use an organization’s ID and all access token to insert and retrieve secrets:

Putting a secret into your secret store:

>curl --data '{"myuser_password": "my_password_value"}' --request PATCH --url<My_Org_ID>/secrets --header 'Authorization: Token <All_Access_Token>'

Listing out all the secret keys in Organization

>curl --request GET --url<My_Org_ID>/secrets --header 'Authorization: Token <All_Access_Token>'

Using secrets in Flux

My blog used this bit of Flux code to perform SQL insert magic:

// Store result in Postgres
|> "postgres", dataSourceName: "postgresql://localhost?sslmode=disable", table: "adjustment_billing")

Locally, that works, but a production example would use a user/password to write to a remote database with Flux:

// Store result in remote Postgres database
	|> "postgres", dataSourceName: "postgresql://myuser:[email protected]:5432/nisley?sslmode=disable", table: "sensor_billing")

Without secrets, usernames and passwords are hardcoded in plaintext. Fortunately, we can leverage Cloud 2’s Vault to keep sensitive information safe. Here, I revamp the full fish tank vendor billing script to use the secret store for the actual password stored in myuser_password:

import "sql"
import "influxdata/influxdb/secrets"

myuser_secret = secrets.get(key: "myuser_password")

from(bucket: "tank-health")
	|> range(start: -1w)
	|> filter(fn: (r) => r._measurement == "water_sensor" and r.type == "adjustment")
	|> group(columns: ["type", "device_id"], mode:"by")
|> count(column: "change")
|> rename(columns: {change: "adjustment_actions"})
|> keep(columns: ["device_id", "adjustment_actions"])
|> "postgres", dataSourceName: "postgresql://myuser:" + myuser_secret + "@", table: "adjustment_billing")

InfluxDB's common API and OSS

If you are developing on-premise with OSS instead of Cloud 2, don’t fret! One of our core tenets is to develop one common API across all products and services. The API examples above work with any local InfluxDB 2 OSS URLs:

Get secrets from local OSS build:

>curl --request GET --url https://localhost:9999/api/v2/orgs/<My_Org_ID>/secrets --header 'Authorization: Token <All_Access_Token>'

Note that InfluxDB 2 OSS’s underlying key-value store is currently BoltDB. BoltDB is not focused on being a secret key-value store, so be mindful that if folks have access to the machine, values should not be considered secure.

Come explore Flux with us

Join us in exploring the new Secret packages in Flux by signing up for InfluxDB Cloud 2, or use it locally with the latest OSS InfluxDB 2 alpha. As always, if you have questions or feature requests for Flux, head on over to Flux’s community forum and let us know!