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.,
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:
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
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.,
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.
There’s supposed to be a video here, but for some reason there isn’t. Either we entered the id wrong (oops!), or Vimeo is down. If it’s the latter, we’d expect they’ll be back up and running soon. In the meantime, check out our blog!
To illustrate, let’s reconsider the scenario above, but let’s create Cloud Access Policies instead:
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
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
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.