Until recently, Grafana Cloud users had to rely on API keys to read and write data to and from the composable observability platform. These API keys had minimal features, which limited administrators’ ability to manage account access on a granular level. 

We’re keenly aware of these shortcomings, and we’ve been working to overhaul and replace these API keys with something more flexible, more reliable, and more secure. That’s why we’re so excited to tell you about the addition of Grafana Cloud Access Policies to Grafana Cloud.

Why move away from API keys?

Our API keys have taken us a long way. They’ve helped thousands of users read and write terabytes of data on Grafana Cloud, but they also have their limitations. The privilege level of these API keys is solely defined by a coarse-grained role (e.g., Viewer, Editor, Admin). These roles have implicit permissions, and they apply to everything within a Grafana Cloud organization. This works well enough at a small scale, but problems arise as you add isolated environments.

To illustrate, let’s consider a Grafana Cloud organization with two stacks:

Copy

Organization: my-org
Stacks: dev-stack, prod-stack
API key:
 - Name: editor-api-key
   Role: Editor

In this scenario, our editor-api-key can read from and write to services (e.g., Grafana Mimir, Grafana Loki, and Grafana Tempo) belonging to both dev-stack and prod-stack.

It’s not possible to create an API key that can, for example, only write metrics to a single Grafana Cloud stack. This means that anyone with an Editor API key can read and write metrics to all stacks in the organization. Generally, this does not follow the principle of least privilege, and in some cases this falls short of security requirements.

Also, it’s difficult to determine, for example, what an Admin role can do that an Editor role cannot. Users need to sift through documentation to determine the role they should use, which is likely to result in them picking the Admin role when, by and large, they really just needed the Editor role. Security at the expense of usability comes at the expense of security.

Introducing Grafana Cloud Access Policies

Cloud Access Policies do not have these shortcomings. Instead of coarse-grained roles, access policies have a set of explicit fine-grained scopes (e.g., metrics:read, logs:write). And instead of being able to access everything in a Grafana Cloud organization, access policies have a realm that determines if the access policy provides access to a Grafana Cloud organization or a Grafana Cloud stack.

To illustrate, let’s reconsider the scenario above, but let’s create Cloud Access Policies instead:

Copy

Organization: my-org
Stacks: dev-stack, prod-stack
Access Policies: 
 - Name: metrics-write-policy
   Scopes: [metrics:write]
   Realms: [dev-stack] 
 - Name: logs-read-policy
   Scopes: [logs:read]
   Realms: [prod-stack] 
 - Name: editor-policy
   Scopes: [metrics:write, logs:read]
   Realms: [dev-stack, prod-stack] 

In this scenario, metrics-write-policy is only capable of writing metrics to Mimir in the dev-stack, logs-read-policy is only capable of reading logs from Loki in the prod-stack, and the editor-policy can write metrics to Mimir and read logs from Loki in both dev-stack and prod-stack.

As we can see, by using access policies instead of API keys, we have more options for defining privileges. This translates to reduced vulnerability if you leak one of your keys. In addition, the scopes and realms create guard rails which help prevent any impacts from developer mistakes. Lastly, the purpose and capability of these access policies are simple and clear thanks to their explicit scopes.

Utilize additional features for greater security

In addition to the benefits we’ve already discussed, Cloud Access Policies have a few other new features you might find helpful.

Filtering by labels (label-based access control). This allows you to refine the privilege of an access policy even further. In addition to realms and scopes, access policies can have Prometheus label selectors that determine which metrics and logs can be queried. 

This is a great way to isolate data to certain teams within a single stack. Rather than creating multiple stacks (as shown above), you could create multiple Grafana data sources that have different filters.

Multiple tokens per access policy. Tokens have a many-to-one relationship with access policies so you can create multiple tokens for an access policy. Tokens can be deleted without removing the related access policy, meaning that access policies don’t need to be recreated when rotating a token.

Custom token expiration. Tokens can optionally be given an expiration date, beyond which the token will stop working. This can help automate controls for short-lived access.

What’s next for Grafana Cloud Access Policies?

Cloud Access Policies are generally available today to all Grafana Cloud users, and we plan to completely replace API keys with access policies at some point in the future. At the time of writing this, access policies have a limited set of scopes, primarily for querying and sending data. Eventually, however, there will be scopes for everything related to Grafana Cloud. This will allow organizations to define more granular privileges for their users, resulting in better security.

To learn more about Cloud Access Policies, check out the docs, which go into greater detail and show how to use the API and plugin. And if you’re not already using Grafana Cloud — the easiest way to get started with observability — sign up now for a free 14-day trial of Grafana Cloud Pro, with unlimited metrics, logs, traces, and users, long-term retention, and access to one Enterprise plugin.