AWS Glue can borrow Iceberg credentials from a remote catalog—but authorization now has two control planes
Source-vended credentials remove the need for a broad AWS role over remote storage. They also make operators reason about revocation, query-time refresh and layered grants across two systems.
AWS Glue Data Catalog now supports source-vended credentials for Apache Iceberg REST catalog federation. Instead of requiring an AWS IAM role with direct access to the remote catalog’s S3 data, Glue can accept temporary credentials issued by that catalog and scoped to the table’s storage prefix. Athena, Redshift, EMR and Glue can then read the federated tables, while Lake Formation continues to enforce its own controls. AWS launch · AWS documentation
The important change is who hands out storage access
AWS now documents two delegation modes. In the default registered-role mode, Lake Formation assumes an IAM role that must be able to read the table data. In source-vended mode, the remote catalog returns temporary S3 credentials through its Iceberg REST loadTable response; the AWS role no longer needs direct access to that data. AWS positions this mode for storage owned by the remote catalog service, or when an operator does not want AWS roles reading it directly. AWS documentation
That narrows one credential boundary, but it does not collapse authorization into one policy engine. The remote catalog’s coarse table grant still applies, and Lake Formation can add row-, column-, cell- and tag-based restrictions. A query succeeds only through the combined path. AWS launch · AWS documentation
Revocation and long-running queries deserve explicit tests
AWS says revoking access in the external catalog causes AWS-engine queries to fail the next time the engine loads the table, without an AWS-side policy change. The remote catalog chooses credential lifetime, while Glue refreshes credentials during long-running queries. Those details create two operational questions: when does an engine reload table state, and what happens to work already running when a grant changes? The documentation defines the mechanism, but teams should test their own query and revocation timing rather than assume an immediate kill switch. AWS documentation
A practical rollout should therefore verify four things: a remote grant alone is insufficient when Lake Formation denies access; an AWS grant cannot bypass a remote revocation; long-running queries survive ordinary credential refresh; and audit records can connect the remote grant to the AWS principal and engine request. Also test large tables: AWS documents a 5 MB metadata limit per REST API call for federated Iceberg catalogs. AWS documentation
The feature is available in commercial AWS Regions where Glue and Lake Formation are supported, through the Lake Formation console, CLI and SDKs. The safer architecture is not “credentials disappear”; it is that storage credentials become shorter-lived and more narrowly issued while authorization remains deliberately layered. AWS launch
sources
comments · 0