Hello Looker Dev Team & Community,
With the Looker 26.8 release coming up next month (May 2026), we are trying to figure out how to migrate our automated onboarding scripts before standard user credential management is deprecated for admins.
Our Current Workflow: We run a self-service provisioning portal (via a headless Cloud Run job) to streamline developer and analyst onboarding. Our backend uses a Looker Admin Service Account to:
-
Call
create_user_credentials_api3on behalf of a standard user. -
Capture the
client_idandclient_secretat the moment of creation. -
Automatically generate a
looker.inifile for their MCP server contexts and/or other config files. -
Deliver it securely via a TTL-enforced, SSO-gated Google Cloud Storage file.
-
Automatically handles and enforces credential rotation.
The 26.8 Impasse: The 26.8 release notes state admins will no longer be able to access or manage API credentials for standard users. If our backend admin account can no longer create or revoke keys for these users, our automated pipeline completely breaks.
Our Questions:
-
The Automation Catch-22: If standard users must now generate their own keys, how can an external, trusted automated system facilitate this on their behalf? Is there any supported delegated authorization flow (e.g., impersonation via a trusted service account) that allows a central internal portal to trigger the creation of a
looker.iniconfiguration without forcing the human user to manually click through the Looker Web UI? -
“Grepping” Existing Credentials: If programmatic creation by a trusted service is no longer possible, will there be any secure way for an admin service account to read/retrieve a user’s existing full credentials to build these
looker.inifiles? Specifically, will endpoints likeall_users_credentials_api3scontinue to return metadata/IDs for standard users post-26.8? And if so, is there any new secure retrieval mechanism planned for trusted integrations to retrieve the associatedclient_secret? (Note: We are aware that historically, theclient_secretcannot be retrieved post-creation. We are asking if a new mechanism is planned to support these automated workflows). -
Automated Cleanup/Revocation: How are we supposed to enforce automated credential rotation/deletion for standard users if admins lose access to
delete_user_credentials_api3? -
UI-Only Limitation & Workarounds: If programmatic creation/retrieval is completely blocked, does this mean self-service credential management and config generation for standard users is now strictly limited to manual clicks within the Looker Web UI? Are there any recommended architectural patterns for maintaining an automated, API-driven config-generation system for standard, UI-accessing users post-26.8?
Any guidance on how to avoid forcing our users back to manual UI clicking would be greatly appreciated, especially with the May release right around the corner.
Thank you!