I find the client authentication token permission granularity and flexibility to be very limited. I think it boils down to the fact that is not possible to update bucket access to an existing token.
This means that I need to rotate any deployed auth tokens on backends/servers every time I add buckets. In our use case we use separate buckets to separate customer data, so a new customer means a new bucket and a new token.
The only alternative is wildcard tokens for full read and/or write access. This is also a disaster waiting to happen.
If wildcard tokens were combined with organizations it wouldn’t be that much of a problem. In such scenario different environments (dev/test/prod) can use their own organization.
BUT, when using InfluxDB Cloud, there seems to be no way to have multiple organizations (we host our Cloud “instance” in GCP).
Am I missing something or is this the situation I need to design for? Adding many organizations to my Cloud “instance” would certainly make my life easier…
Hi @PHL,
So multitenancy within InfluxDB Cloud is currently in the works. We hope this will be released soon. With regards to updating tokens let me push this feature again back to product and see if there is anything on the roadmap.
Sounds promising, we really need to separate production data in an easy way.
But maybe I’m missing something? Can I just “spin up” new InfluxDB “appliances” in GCP with different organizations and still get the same total cost? Last I checked, it seems like I can only run one InfluxDB Cloud per GCP project.
@PHL you are correct there is only one cloud instance per customer/bill. You can generate further cloud accounts with new emails but these are entirely separate and will be billed accordingly. For now, you are doing the right thing by separating via bucket. I shall keep you in the loop on multiple org releases.
Another thing (maybe reason to start a new thread?), as of now we want to dynamically create buckets for new customers. That requires the using an All Access token. This means that we need to handle a “root” token in our backend. I would prefer to at least limit the access to creating buckets, not deleting them.
