Cluster-based access controls

Approach

The company had a working hypothesis that enterprise customers would be able to leverage CockroachDB's differentiators most effectively. Barring financial considerations, we had expected more migration evaluations, signaled by more users being granted access to a customer's CockroachDB account.

Yet, deal analysis showed that expansion revenue was falling behind projections. User analytics indicated most customers' new user count nosedived to 0 after the 3 month mark.

his pattern provided my team and I a starting point: excluding financial considerations, what had to be true for enterprise customers to be comfortable adding more users i.e. onboarding more teams who in turn would begin migration evaluations?

Insights

To answer this question, my team and I scheduled interviews with more than 30 customers in the enterprise segment about what would give them the confidence to onboard their next team to CockroachDB. Amongst what we learned, 3 learnings stood out:

Teams had to manage their own clusters

In our interviews, customers mentioned that if they had multiple teams using CockroachDB, at minimum it'd be necessary for those teams to manage access to their own clusters. Jack from team A shouldn't be able to misconfigure clusters managed by Tony's team B and vice versa.

At the time, anyone with access to a customer's account had access to every cluster within that account. Meeting this requirement required us to devise access controls that allowed limiting or "scoping" access to every cluster.

Programmatic management of clusters

During our interviews, more than 3/4 of our enterprise customers mentioned they used an infrastructure-as-code tool like Terraform and Pulumi to coordinate 3rd-party cloud infrastructure services within the customer's ecosystem. Typically these tools leveraged services accounts to interact with services like CockroachDB through public APIs.

Knowing this usage pattern signaled that programmatic access via public APIs would be critical to enterprise customers. As CockroachDB service accounts used a different permission model than human accounts, we realized that consistency mattered. We had to find some way for human and service accounts to utilize the same permission model.

Momentum mattered

Enterprise customers also shared that momentum was key for migration evaluations. If a team was told they could begin experimenting with CockroachDB, it had to be possible to provision access quickly to the team conducting the evaluation.

While access to services like CockroachDB was usually managed through a central identity management tool, in the case of evaluations most enterprises were willing to side step the normal access policies. Customers shared that even when tools were approved for use, ongoing evaluations typically meant access was shared from within the service's provided access management UIs.

Thus, while programmatic access via service accounts was key for getting a team running with CockroachDB in production, we had to ensure that our UI was also usable and durable for the long term.