Looker package v1.0.0

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). The credential pair is used only to obtain a token: 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, according to the reviewed authentication documentation) for a short-lived OAuth 2.0 access token, and stores under this reference the complete Authorization header value the reviewed 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.

Token lifetime: the reviewed 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 the api-auth page states NO numeric token lifetime, while the retrieved login reference documents an expires_in seconds-to-expiry field in the token response — the external renewal process must therefore renew proactively using expires_in (or 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, according to the reviewed 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.

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 has since been retrieved live at cloud.google.com/looker/docs/reference/looker-api/latest/methods/ (method pages for Query/run_inline_query, Folder/create_folder, Dashboard/all_dashboards, Dashboard/delete_dashboard, Look/all_looks, Look/delete_look, ApiAuth/login and ApiAuth/logout), and every operation path in this pack is verified against it; the instance's own API Explorer (which every Looker instance serves) remains a useful deployment check.

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 designated actions requiring human approval and a delivered copy cannot be recalled after delivery), 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.

Approval classification: 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.