Heplon

Connector data access

A connector reads only what the table lists, and only what its credential permits. Every connector is read-only: no connector can create, change, or delete anything upstream. The exception are GitLab and Gitea connectors, which can open pull requests.

What each connector may pull

ConnectorCredentialData Heplon may pull
BackstageNoneCatalog components: their metadata, component spec, and relations to other entities
GitLabStatic token or delegated OAuthProjects, repository contents, pipelines, tags
GiteaStatic token or delegated OAuthRepositories, repository contents, tags
Azure DevOpsPersonal access tokenRepositories across every project in the organisation, repository contents, tags, Azure Pipelines build runs, their jobs, and job logs
SlackBot tokenChannel names, and the messages and thread replies in the configured channels
KubernetesService-account bearer tokenAny Kubernetes resource the token can read, namespaced or cluster-scoped
TempoOptional bearer tokenTraces, trace search results, and attribute values
LokiOptional bearer tokenLog lines, label names, and label values
PrometheusOptional bearer tokenMetric samples, series, label names and values, metric metadata, and active alerts

The credential sets the ceiling

The categories above describe the most a connector can pull. What it actually pulls is the intersection of those categories and what the configured credential is allowed to see. Heplon holds no separate access of its own, so it can never reach data the credential cannot reach.

For example, if the service account whose token was used to configure the Kubernetes connector cannot read the contents of Secrets, then Heplon cannot read them either. The same applies elsewhere: a GitLab token that sees three projects gives Heplon those three projects.

Scoping the credential is therefore the way to scope Heplon.