InfluxDB’s Role-Based Access Control (RBAC) isn’t about assigning users to roles, but rather about assigning permissions to tokens, which are then used by users or services.
Let’s see this in action. Imagine you have an InfluxDB instance and you want to allow a specific application to write data to a particular "staging" bucket but do nothing else.
First, you need an organization. Let’s say your organization ID is a1b2c3d4e5f6g7h8.
influx org create --name staging_org --description "Org for staging data"
# Output will include the Org ID, e.g., a1b2c3d4e5f6g7h8
Next, you need a bucket within that organization.
influx bucket create --org a1b2c3d4e5f6g7h8 --name staging_data --retention 1h
# Output will include the Bucket ID, e.g., i9j8k7l6m5n4o3p2
Now, the core of RBAC: creating a token with specific permissions. This token will grant read/write access only to the staging_data bucket within the staging_org.
influx auth create --org a1b2c3d4e5f6g7h8 --bucket-write i9j8k7l6m5n4o3p2 --description "Staging App Write Token"
# Output will include the token, e.g., z9y8x7w6v5u4t3s2r1q0p9o8n7m6l5k4j3i2h1g0
This token, z9y8x7w6v5u4t3s2r1q0p9o8n7m6l5k4j3i2h1g0, can now be used by your staging application to write data. If it tries to read data from another bucket, list organizations, or perform any other action, it will be denied.
The mental model here is that you’re not creating "users" in the traditional sense with usernames and passwords. Instead, you’re creating discrete, permissioned "keys" (tokens) that grant very specific capabilities. These tokens are then handed out to whatever needs to interact with InfluxDB.
The influx auth create command is your primary tool. You can specify permissions granularly: --read-buckets, --write-buckets <bucket-id>, --orgs-read, --dashboards-write, and so on. If you omit a specific permission flag, the token won’t have that capability. For example, if you wanted a token that could only read from the staging bucket, you’d use --bucket-read i9j8k7l6m5n4o3p2 instead of --bucket-write.
A common pattern is to create a single organization per logical domain (e.g., production, staging, monitoring) and then within those organizations, create buckets for different data types or sources. You then issue tokens that are scoped to specific buckets and specific actions within those buckets. This provides a strong security boundary. The influx auth command allows you to list all existing tokens and their associated permissions, which is crucial for auditing.
When you create a token with --all-access, you are effectively creating a super-user token. This token bypasses all RBAC checks and can perform any operation on any resource within the organization it’s associated with. While convenient for initial setup or administrative tasks, it’s generally considered a security anti-pattern to use these broadly.
The true power of this system lies in its ability to create ephemeral, single-purpose credentials. If a staging application is compromised, the attacker only gains the very limited access granted by its token, rather than full access to your InfluxDB instance. This principle of least privilege is fundamental to secure system design.
The next step in mastering InfluxDB access control involves understanding how to manage these tokens throughout their lifecycle, including rotation and revocation.