Organizations that serve multiple parties from a centralized physical GCP infrastructure face a design puzzle - how to structure the cloud environment to accommodate the needs of a multi-tenant system. You may find yourself in this space if you are a SaaS provider, independent software vendor (ISV) or enterprise IT department responsible for providing services to multiple internal groups. While designing a complete multi-tenant cloud system that encompasses storage, compute, networking, etc. is beyond the scope of this article, one frequently encountered focus area is API consumption.
Let's lay out a few common API consumption use cases.
- as a SaaS provider or ISV, your customers consume Google Maps Platform APIs by way of your application
- as a SaaS provider or ISV, your customers consume your own APIs hosted in GCP and registered with Cloud Endpoints
- as an IT department, your customers consume Google Cloud APIs directly
The common element in all these use cases is request authentication with Google API keys. Maps Platform requires API keys and your custom-built APIs can choose to use API keys as can the public Google Cloud APIs. Keep in mind that API keys are not appropriate for all authentication scenarios. For example, authenticating end users is better accomplished with other methods.
Why fine-grained API key access management?
Some of the reasons for building a sound architecture to manage multiple tenants at a fine-grained level include:
- tracking spend by customer, internal department or team for invoicing purposes
- securing access by customer domain or IP
Design patterns for multi-tenant API consumption
There are a few patterns in the wild that multi-tenant software providers have established, each with advantages and disadvantages. Each pattern has deployment-related subtleties which can only be addressed with knowledge of your specific system.
Pattern Decision Matrix
|API key||GCP Project||Channels (Labels)||Customer-managed|
|allocate spend by customer||no*||yes||yes||yes|
|provider management overhead||high||high||high||low|
|responsible party: project, keys, channels and security||provider||provider||provider||customer|
|responsible party: cost management||provider||provider||provider||customer|
|volume pricing benefits**||discounts||discounts||discounts||possible|
*possible when combined with channels
**available through Maps Partner relationship
API key per customer
Software provider creates a single GCP project and API key for each customer. This is often the first solution that comes to mind. There are challenges with this approach. First and foremost, none of the available billing data, including Cloud Console billing reports and Big Query billing data export, contains API key information so spend allocation by customer becomes difficult if not impossible. Do note, there is a way to overcome this blocker with a hybrid solution - combining this pattern with channels (below). Further, all API key management falls on the provider, including creating and destroying keys and API key security. The advantage is the provider can take advantage of discounted tier pricing with Woolpert as your Maps partner as the project is linked to the partner billing account. However, cost management becomes the provider's problem and protecting against cost overruns becomes paramount.
Project per customer
Software provider creates a GCP project for each customer and an API key inside each project. Provider retains ownership and management responsibilities of the project and API keys. The Cloud Console billing reports, BigQuery billing export data and our invoice will break down spend by project. Provider invoices customers accordingly. The challenge here is in managing these projects as customer come and go (which can be done programmatically), and running up against GCP project quota limits. Also, API key security is left up to the software vendor. As in the first pattern, the provider can take advantage of discounted tier pricing with Woolpert as your Maps partner. Here too, protecting against cost overruns is critical.
Channel (Label) per customer
Only available with Maps Platform and Google Cloud APIs. Not available for your custom APIs in Cloud Endpoints.
Software provider creates a single project and API key. This single key is used across all customers. Provider decorates requests with channels to track customers. These channels are available in the all billing report data sources to separate spend by customer. There is a cap of 1000 unique channels per API key after which additional API keys can be created. The drawback with this approach is two-fold: channel management is on the provider and API key security becomes a giant whitelist containing all customer domains and API keys are shared across customer sites. Discounted tier pricing is also available here but with that comes the responsibility to protect against cost overruns.
Customer-managed API key
Customer creates own GCP project and API key and provides it to the software provider during onboarding. In this scenario, the customer is responsible for managing the API key, including security. Any spend is billed to the customer's billing account and therefore cannot take advantage of discounted tier pricing at the provider level. The advantage is the provider is relieved of the burden of managing API keys and projects and the customer is directly responsible for all spend, including any cost overruns.
There's no single solution to this puzzle that will meet every organization's needs and desires. But practically speaking, if you as the service provider want to minimize overhead and are comfortable with laying more responsibility on your customers, we recommend Customer-managed API keys. On the other hand, if you want to take on this overhead as a service you provide to your customers, consider a hybrid solution of API key per customer combined with channels.
Hybrid API key per customer with channels
Please sign in to leave a comment.