Appearance
Google Drive
Liddr indexes Google Drive documents and mirrors each file's Drive permissions onto its knowledge-graph entry, so retrieval hides what Drive hides. The Scope setting selects shared drives only (the default) or shared drives plus every user's personal My Drive. Requires a Google Workspace or Cloud Identity domain: domain-wide delegation does not exist for consumer Google accounts, and shared drives are a Workspace feature. Access is strictly read-only.
What Liddr accesses
| Direction | Access |
|---|---|
| Ingest (read into your knowledge graph) | Read-only |
| Reverse sync | None — Liddr never writes to this source |
Setup
- Create a Google Cloud service account for Liddr and generate a JSON key. It needs no project IAM roles — access comes from domain-wide delegation.
- Copy the service account's numeric Client ID from its Details page.
- In the Google Admin console: Security → Access and data control → API controls → Domain-wide delegation → Add new. Paste the Client ID and authorize the scopes below.
- Assign the Drive admin privilege to the account Liddr will impersonate, via super admin or a custom admin role. Without it the connector falls back to the drives that account belongs to.
- In Liddr: Settings → Connections → Google Drive. Paste the JSON key and set the admin email to impersonate.
- Run Test to list visible shared drives, then set the shared-drive allowlist under Advanced.
- Run liddr gdrive acl-preview to confirm captured permissions resolve to real Liddr accounts, create any accounts that are missing, then run an Ingest.
- To index personal drives as well, authorize the directory user scope and set Scope to all. Only files a user owns are indexed, so a document shared with ten people is stored once, taken from its owner, with its full grant list intact.
Required scopes
Domain-wide delegation scopes
Ingest — minimum
- https://www.googleapis.com/auth/drive.readonly — always required; reads files and their permissions
- https://www.googleapis.com/auth/admin.directory.group.readonly — optional; reads the groups Drive grants access to
- https://www.googleapis.com/auth/admin.directory.group.member.readonly — optional; reads who belongs to those groups
- https://www.googleapis.com/auth/admin.directory.user.readonly — required for Scope = all; lists whose personal drives to index
TIP
Minimum equals maximum — there is no reverse sync to Drive, so never authorize a write scope. A scope that is not authorized fails as unauthorized_client at the token exchange, before any Drive call, so the fix is always in the Admin console rather than in Liddr. The two group scopes buy automatic access provisioning: Drive states that a group may read a file but never who is in that group, so without them a group permission only matches users who sign in through SSO carrying that group in their claims.
Privileges the impersonated account needs
Ingest — minimum
- Drive admin privilege (super admin, or a custom admin role) — lists every shared drive in the domain
- User read privilege — required for Scope = all, to enumerate whose personal drives to crawl
- Without the Drive privilege the connector degrades to the shared drives that account is a member of
TIP
Google reports the missing Drive privilege two different ways: a 403 when listing drives, and a 404 "File not found" when reading a drive's permissions. Liddr treats both as the same signal and retries in member scope, so a least-privilege setup keeps working on a narrower set of drives. A custom admin role is preferable to granting super admin just for this.
What gets indexed
Ingest — minimum
- Shared drives on the allowlist — there is no sync-everything default
- With Scope = all, additionally every user's personal My Drive, limited to files that user OWNS
- Trashed files, folders and shortcuts are skipped
TIP
Taking personal files from their owner rather than from everyone who can see them is what keeps one document one entity: a file shared with ten people sits in ten My Drives. It also avoids pulling in files owned outside your domain that someone shared in. Shared-drive files inherit the drive's permission list, because Google does not return per-file permissions for them; personal files carry their own.
Before you turn on enforcement
Ingest — minimum
- Every Drive file Liddr writes is access-controlled: with enforcement on it is visible only to the people its permissions name
- A file whose permissions could not be read is hidden from everyone, never shown to everyone
- Drive permissions are matched to Liddr accounts by email address
TIP
Run liddr gdrive acl-preview first. If it reports orphan principals or reaches 0 users, turning on Enforce ACLs will hide that content from the whole org — that is the fail-closed design working, not a fault. Create Liddr accounts at the addresses Drive names, or map Google group names with acl_group_alias_map, until the preview comes back clean. Permissions are re-read on each ingest, so a share revoked in Drive takes effect at the next run rather than immediately.