looker v1.0.0

The pack names a reference, never a secret. Installing a pack registers capabilities and makes them governable; registration is not connectivity. The credential is created at the provider and held in the client's own secret manager under the reference the pack names, and deployment testing is still required to show the credential path works and cannot be bypassed.

Reference

secret-ref-looker-access-token

Custody

customer_vault

Injection

header (Authorization)

Looker issues API credentials per Looker user as TWO values — a client ID and a client secret — created by an admin on the Users page in the Admin section (Looker original) or by the user on their Account page once API management is enabled (Looker Google Cloud core). This pack states that two-credential model honestly: neither the client ID nor the client secret is what the executor injects. An external deployment process holds the pair in the client's own secret manager under a separate reference, exchanges them at the instance's login endpoint (POST /api/4.0/login, per the retrieved authentication documentation) for a short-lived OAuth 2.0 access token, and stores under THIS reference the complete Authorization header value the retrieved documentation shows: the scheme 'token', one separating space, then the access token — 'token <access_token>'. The external process renews the stored value before expiry; the injector injects the stored value verbatim and performs no login itself. Lifetime honesty: the retrieved documentation names the login and logout (DELETE /api/4.0/logout) endpoints and states an access token can be used on multiple API requests until it expires or is invalidated by calling logout, but it states NO numeric token lifetime and no expires_in response field in the retrieved content — the external renewal process must therefore renew proactively on a deployment-chosen interval and treat a 401 as fail-closed: re-login, never retry with the dead value. The retrieved documentation also does not state that deleting or rotating the underlying client credentials invalidates already-issued access tokens — so the deployment must treat issued tokens as live until expiry or explicit logout (disabling issuance is not revocation), while an expired or logged-out value fails closed. Deleting the bound Looker user account invalidates that user's API credentials. Least privilege, per the retrieved guidance: never use credentials bound to a Looker admin account in production — create a minimal-privilege service account, grant only the permissions these capabilities need, and bind the credentials to it; API calls execute with exactly that user's permissions. Executor hygiene: the value must live only in executor memory for the lifetime of a call, must never be written to logs, traces or diagnostics, and must not appear in crash dumps; a deployment that cannot meet that bar must not enable the pack.

• looker-instance (api, pii): https://looker-instance.invalid/api/4.0

The endpoint host 'looker-instance.invalid' is a reserved non-production placeholder (an RFC 2606 reserved TLD): substitute the customer's Looker instance host before enabling, in every endpoint, in the resource locator and in every egress allowlist entry. The allowlist matches exactly, so endpoints and allowlist must be substituted together, and substitution is a required deployment step. LOOK_ID, DASHBOARD_ID and RESULT_FORMAT in the endpoint paths are placeholders the deployment binds before enabling. The retrieved authentication documentation confirms the API path prefix with the example GET /api/4.0/user on the instance host. The Looker 4.0 endpoint-by-endpoint reference could not be retrieved this session — developers.looker.com was unreachable and the cloud.google.com API-reference paths returned 404 — so every operation path here beyond /api/4.0/user follows the documented /api/4.0 prefix and Looker's published REST conventions but must be re-verified against the instance's own API Explorer (which every Looker instance serves) before enabling; that unverified-path state is why this pack is a draft, not a library entry. Documented exclusions: this pack does not register user administration (creating or deleting users, or creating or deleting their API credentials), sudo or user impersonation (login_as_user), scheduled-plan creation and one-shot delivery (sending dashboards or Looks to email, Slack, S3 or SFTP — send is one of the IRREVERSIBLE ACTIONS and a delivered copy cannot be un-sent), LookML project git operations and deploys, database connection management, content access-grant APIs, and the OAuth CORS authentication mode for frontend clients — each a deliberate exclusion requiring its own review, not an approximated capability. Tiering rationale: query execution is registered read at the read floor because its governed effect is read-only over business data — it modifies none of the content or configuration this pack manages — while provider-side side effects (query history, server-side caches, and any derived-table activity a query triggers in the database) are real but outside what this registration claims to enumerate; and a query can return any data the credential's user can see — the deployment must raise the data class (and policy the tier) wherever the exposed models carry regulated data, since an unrestricted query body selects arbitrary models and explores and the registration does not restrict it.

Draft review record dated 2026-09-21 · Reviewer: aaes-eng (an opaque id that resolves internally to the responsible reviewer)

• https://cloud.google.com/looker/docs/api-auth (retrieved 2026-09-21)
• https://cloud.google.com/looker/docs/api-overview (retrieved 2026-09-21)

A pack review is not a vendor or examiner attestation. A retrieval date says when a source page was read; it does not by itself establish what the page said then. No pack is vendor-endorsed, and none has been connectivity-tested against a live vendor tenant.