Apache Polaris Credential Vending Audit Trails

Temporary credentials are not a security story by themselves. The audit trail decides whether anyone can trust them later.

Credential vending needs evidence, not just expiry

Credential vending sounds clean. A catalog gives a query engine short-lived storage access so the engine can read or write table data without holding long-term cloud keys. That is the right direction. It still leaves a hard question for platform security teams.

Who asked for the credential, which table or warehouse did it cover, which storage path did it unlock, which policy allowed it, when did it expire, and which query or job used it? If those answers are not captured together, short-lived access becomes short-lived memory.

Polaris puts the catalog in the access path

The Apache Polaris documentation describes credential vending as a process where Polaris vends temporary storage credentials to a query engine during execution. The Iceberg REST Catalog specification also treats credential vending as part of catalog operations.

That catalog position matters. A catalog can see the principal, catalog object, table identifier, storage configuration, and operation request. ODI turns that position into an audit boundary. The access grant is not just a token. It is a reviewable decision.

Make every vendable credential reviewable

• Record the requesting principal, client, catalog, namespace, table, and operation.
• Attach policy version, allowed scope, credential lifetime, and storage location.
• Correlate the credential event with query logs, lineage events, and incident records.
• Flag broad, repeated, or unusual vending patterns for owner review.
• Test revocation and expiry behavior during normal platform drills.

This belongs next to Apache Polaris and open catalogs, catalog-neutral governance controls, and policy portability tests. Credential vending is where open catalog design meets real access control.

What breaks first

• Credentials expire correctly, but the audit log cannot explain why they were granted.
• The catalog records table access while storage logs record bucket access, with no common identifier.
• Incident response can see a query but cannot connect it to the vended credential.
• Cross-catalog or external-catalog access hides the original authority boundary.

Questions to ask before production rollout

• Can the audit trail join credential vending, query execution, lineage, and policy evaluation?
• Which credentials can cross warehouse, namespace, table, or external catalog boundaries?
• What is the maximum credential lifetime for each workload class?
• Can a reviewer replay who had storage access at a specific time?

Sources to start with

These primary sources anchor the technical claims in this guide.

• Apache Polaris documentation
• Apache Polaris configuration reference
• Apache Iceberg REST Catalog specification

A vended credential without evidence is still a mystery key.