Setting up GCP

There is no key to paste

Telaron stores no credential of yours, and there is no field anywhere to paste one into. If you are looking for where the service-account key goes, that is why you cannot find it.

Instead, Telaron holds an identity of its own and mints a short-lived token scoped to your tenant. You configure your project to trust that token, and to let it act as a service account you choose. Access is something you grant and can withdraw, in your own project, with your own audit trail — rather than a secret you hand over and hope is looked after.

Configure the trust

1. 01

   Create a workload identity pool provider that trusts Telaron

   In your project, add a workload identity pool with an OIDC provider pointing at Telaron’s issuer. The provider’s full resource name is the audience Telaron must present, and you will give it to Telaron in the next section. Ask us for the issuer URL and the claim to match on — those are ours to give you rather than yours to guess.

2. 02

   Choose the service account Telaron will act as

   Create one, or nominate an existing one. This is the identity that does the work in your project, so what it can do is exactly what Telaron can do. A dedicated account is easier to reason about and easier to revoke than reusing one that already has other jobs.

3. 03

   Let the pool identity impersonate that account

   Grant the pool principal the ability to obtain tokens for the service account. Without this the exchange still succeeds and lands on a pool identity that can do nothing — which is the most common way a setup looks configured and is not.

4. 04

   Grant the service account what it needs

   Scope it to what you want Telaron to manage. Creating gateway instances, attaching spokes by network peering, programming routes and provisioning a load balancer each need their own permissions, so the grant follows from which of those you want rather than from a single fixed role. Grant the subset you are using and add to it later.

Register the account

Tell Telaron which project this is and where to go in it. A cloud account carries the provider, a name of your choosing, the project id, and two trust references: the audience your provider expects, and the service account to act as. The trust references point at things in your project. They are not secrets.

curl -X POST https://api.dev.telaron.io/api/v1/cloud-accounts/ \
  -H "Authorization: Bearer $TELARON_API_KEY" \
  -H "X-Tenant-ID: $TELARON_TENANT_ID" \
  -H "Content-Type: application/json" \
  -d '{
        "cloud": "gcp",
        "name": "production",
        "account_id": "my-gcp-project-id",
        "federation_audience": "//iam.googleapis.com/projects/123456789012/locations/global/workloadIdentityPools/telaron/providers/telaron",
        "federation_principal": "telaron-fabric@my-gcp-project-id.iam.gserviceaccount.com"
      }'

Command Center does the same thing with a form. Each rule below is a refusal you would otherwise meet cold:

• Both or neither. The audience and the principal are set together; sending one without the other is refused.
• GCP only, for now. An AWS or Azure account refuses the trust references rather than storing something no adapter can use yet.
• The shape is checked. The audience must be a workload identity pool provider path, and the principal must end .iam.gserviceaccount.com.
• To change them, send both. To clear them, send both as empty strings — a change carrying only one is refused.
• Changing them resets the account to pending validation, because the new trust is unproven. Run validation again afterwards.

Validate, and read the answer carefully

Validation is not a formality. Telaron exchanges its own token for the pool identity, impersonates the service account you nominated, and reads the project back. A pass means the whole path works. A failure means that identity genuinely cannot see that project, or that the trust references do not match what you configured.

The message says the identity cannot read the project, and deliberately does not distinguish a project that does not exist from one it is not allowed to see. Google answers those differently and it is not Telaron’s place to tell you which of someone else’s projects exist.

What Telaron does once the account validates

Today, two things: it validates the credentials as described above, and it checks a region against what your project can use.

Separately, enrolment, policy compilation and distribution, and identity resolution work as described elsewhere in this documentation — those are the same on any cloud, because they run between the control plane and your gateways rather than against a provider API.

What stays yours

• The project, its billing, and its organisation policies.
• The service account and everything it may do — withdraw the impersonation grant and Telaron’s access ends immediately, with no key to rotate or revoke anywhere else.
• The workload networks themselves. Telaron peers a network you name; it never creates one.