This post is for platform engineers, SREs, and IT security teams evaluating Confluence apps that handle observability data from Grafana Cloud.
When a Confluence app renders your Grafana dashboards, alert states, and panel snapshots, it is handling operational data that describes the health and architecture of your production systems. Where that data is processed and stored is not a nice-to-have question. It is a security question.
GrafanaSight for Confluence is a Forge-native app that brings Grafana Cloud visibility into Confluence pages. This post explains what Forge-native means, why it matters for apps that handle monitoring data, and what specific security properties GrafanaSight provides.
GrafanaSight is a Flowdence product and is not affiliated with, endorsed by, or sponsored by Grafana Labs.
Two App Architectures: Connect vs Forge
Atlassian offers two architectures for Confluence Cloud apps: Connect and Forge. The difference is fundamental — it determines where your data lives.
Connect apps run on the vendor’s own infrastructure. When a Connect app fetches data from Grafana Cloud, that data passes through the vendor’s servers, is processed on the vendor’s compute, and is stored in the vendor’s database. You are trusting both Atlassian and the app vendor with your data.
Forge apps run on Atlassian’s serverless infrastructure. The app’s code executes inside Atlassian’s cloud. Data is stored in Atlassian-managed encrypted Forge storage. Network egress is declared in the app’s Forge manifest and enforced at the platform level. The vendor ships code; Atlassian runs it.
For utility apps — formatting tools, emoji pickers, page templates — this distinction may not matter much. For apps that handle observability data, it matters a great deal.
Why Observability Data Deserves Forge
Grafana dashboards are not decoration. They encode operational knowledge: which services are monitored, what thresholds trigger alerts, how infrastructure is organized, and what the team considers important enough to watch.
An app that renders Grafana content in Confluence handles several categories of sensitive data:
- Dashboard metadata — panel titles, query structures, data source names, organizational hierarchy
- Alert states and rules — what is being monitored, current firing/pending/normal states, evaluation thresholds
- Annotation data — deployment markers, incident timelines, team-authored context on production events
- Panel snapshot images — rendered graphs that reveal traffic patterns, error rates, capacity utilization, and infrastructure topology
This is operational intelligence. If it passes through a vendor’s external server, that vendor has visibility into your monitoring posture. If it is stored in a vendor’s database, it is subject to the vendor’s data retention, encryption, and access control policies — not yours, and not Atlassian’s.
Forge eliminates this exposure. The data stays within Atlassian’s trust boundary from the moment it is fetched to the moment it is rendered.
GrafanaSight’s Security Model
GrafanaSight is built on Forge with a minimal, auditable security surface. Here is the specific model:
| Property | Detail |
|---|---|
| Runtime | Atlassian Forge — serverless, hosted by Atlassian |
| Forge permissions | Minimal least-privilege scopes; no write scopes to Confluence content |
| External fetch | Declared backend egress to https://*.grafana.net only |
| API method | All Grafana API calls are GET-only (read-only) |
| Credential storage | Atlassian-managed encrypted secret storage — never in macro config |
| Data storage | Atlassian-managed Forge storage — all cache within Atlassian infrastructure |
| Space isolation | Credentials and cache scoped per Confluence space |
| Licensing | Atlassian Marketplace license-gated features |
| Self-hosted Grafana | Not supported — Forge egress is restricted to Grafana Cloud |
No external servers. No vendor database. No infrastructure for your security team to audit beyond what Atlassian already manages.
Declared Egress: No Surprises
Every Forge app must declare its external network access in its Forge manifest. The Forge platform enforces this at runtime — the app physically cannot make requests to undeclared endpoints.
GrafanaSight declares backend egress to one destination: https://*.grafana.net.
This means the app can reach Grafana Cloud APIs and nothing else. It cannot phone home to a vendor analytics service. It cannot exfiltrate data to an external store. It cannot communicate with any endpoint outside the declared scope. The platform enforces this — it is not a policy the vendor opts into; it is a constraint the vendor cannot bypass.
Every API call GrafanaSight makes to Grafana Cloud is a GET request. The app reads dashboard metadata, alert states, annotation data, and renders panel snapshots. It never writes, updates, or deletes anything in your Grafana instance.
Readers view panels, alerts, and health signals in documentation.
Product logic runs on Atlassian-managed infrastructure.
Snapshots and metadata stay inside Atlassian-managed storage.
Service Account tokens are stored as encrypted secrets.
The visual above shows the complete data flow. Everything inside the Atlassian Cloud boundary runs on Atlassian infrastructure. The only external communication is GET requests to Grafana Cloud over declared egress.
Encrypted Credential Storage
GrafanaSight requires a Grafana Cloud service account token to authenticate API requests. This token is stored using Atlassian-managed encrypted secret storage, which provides encryption at rest within Atlassian’s infrastructure.
The token is never stored in macro configuration. Macro config is visible to page editors and is included in page export data — it is not a safe location for secrets. GrafanaSight’s macro configuration contains only non-sensitive values: dashboard selectors, display preferences, and Grafana instance URLs.
Client-facing configuration views never expose token secret keys. A space admin can update or rotate the token, but the stored value is never rendered back to any UI.
Space Isolation
GrafanaSight scopes credentials and cached data per Confluence space. Each space maintains its own Grafana Cloud connection with its own service account token. There is no global credential that spans spaces.
This means:
- A team’s Grafana token in Space A cannot be used to fetch data rendered in Space B.
- Cached dashboard metadata in one space is not accessible from another space.
- Revoking a token in one space does not affect other spaces.
- Different spaces can connect to different Grafana Cloud organizations entirely.
For enterprises with multiple teams sharing a single Confluence instance, space isolation ensures that Grafana access boundaries in Confluence mirror the access boundaries you have already defined in Grafana Cloud.
Forge-Native Trust Signals
For an observability app, Forge-native means the app is built on Atlassian’s Forge platform: Atlassian-hosted compute, Atlassian-managed credential storage, declared external endpoints, and no vendor servers in the path. Every Flowdence product is Forge-native.
That architecture gives InfoSec teams practical trust signals during review:
- No vendor compute or storage to audit. The app’s code runs on Atlassian Forge; Flowdence does not operate any servers, databases, or storage that handle your Confluence or Grafana data.
- Atlassian’s compliance certifications cover the runtime. SOC 2, ISO 27001, and the other certifications that apply to Atlassian Cloud also apply to the Forge execution environment your installation runs inside.
- External connections are declared and auditable. GrafanaSight connects only to Grafana Cloud endpoints required to render the authorized data you choose to show in Confluence.
- Credentials stay in Atlassian-managed encrypted storage. Your Grafana service account token never leaves the Atlassian platform.
This is why we build every Flowdence product — GrafanaSight, ApprovalFlow, and MuleSight — on Forge. The security model is not a feature we add after the fact. It is the foundation the product is built on.
What This Means for Your Security Review
If your InfoSec team is evaluating GrafanaSight, here is what the Forge-native architecture gives you:
Shorter vendor security questionnaires. Most questions about data storage, encryption at rest, server hardening, backup policies, and access control are answered by “runs on Atlassian Forge.” The vendor (Flowdence) ships code. Atlassian runs it. Your existing Atlassian Cloud security assessment covers the runtime.
No new attack surface. A Connect app adds the vendor’s infrastructure to your attack surface. A Forge app does not. GrafanaSight introduces no servers, databases, or storage endpoints outside Atlassian’s boundary.
Auditable egress. The Forge manifest is the single source of truth for what external endpoints the app can reach. *.grafana.net, GET-only. That is the complete external surface, visible in the Marketplace listing before installation.
Credential lifecycle stays in Atlassian. Grafana service account tokens are stored in Atlassian-managed encrypted secret storage, rotated through Confluence space settings, and never leave Atlassian’s infrastructure. Your token management process does not need to account for a third-party credential store.
Compliance-friendly documentation. For teams that need to document their Confluence app landscape for SOC 2, ISO 27001, or internal security reviews, GrafanaSight’s Forge-native architecture produces a clean, auditable story. We maintain a trust page with the security details your compliance team needs.
For full product documentation, see the GrafanaSight docs.
FAQ
What does Forge-native mean for a Confluence app?
Forge-native means the app runs entirely on Atlassian’s serverless infrastructure. There are no external servers to manage, audit, or trust. The app’s code executes inside Atlassian’s cloud, data is stored in Atlassian-managed encrypted storage, and network egress is declared and enforced at the platform level.
This is distinct from Connect apps, which run on the vendor’s own servers and require you to trust both Atlassian and the vendor’s infrastructure with your data.
Why is Forge better than Connect for observability apps?
Connect apps run on the vendor’s own servers, meaning observability data — dashboard metadata, alert states, panel images — passes through and is stored on third-party infrastructure. Forge apps process and store data entirely within Atlassian’s cloud.
For apps handling sensitive monitoring data, this eliminates an entire class of data residency, security, and vendor trust concerns. Your observability data never leaves Atlassian’s trust boundary.
What egress restrictions does GrafanaSight have?
GrafanaSight declares backend egress only to https://*.grafana.net. This is enforced by the Forge platform — the app physically cannot reach any other external endpoint. All API calls are GET-only (read-only).
Grafana service account tokens are stored in Atlassian-managed encrypted secret storage, not in macro configuration or app storage. This means credentials are encrypted at rest and never exposed in page exports or macro config views.
Does GrafanaSight store monitoring data on external servers?
No. All cached dashboard metadata, alert summaries, annotation data, and panel snapshot images are stored in Atlassian-managed Forge storage within Atlassian’s infrastructure.
GrafanaSight has no external servers, databases, or storage. Flowdence ships code to the Forge platform; Atlassian runs it and stores the data.
Can GrafanaSight connect to self-hosted Grafana instances?
No. Forge’s egress enforcement restricts all external requests to declared domains. GrafanaSight declares *.grafana.net only, which covers Grafana Cloud. Self-hosted Grafana instances running on custom domains cannot be reached from within the Forge runtime. This is a deliberate security constraint, not a missing feature.
Related Posts
- Stop Screenshotting Grafana Dashboards
- From Dashboard to Documentation: GrafanaSight for Platform Teams