Securing Catalog and Engines

Securing the Catalog and Query Engines

Lakehouse Access Control's rules trusted whatever user name the client sent. Trino 403,499 authenticates with passwords, LDAP, OAuth 2.0, Kerberos, JWT or client certificates, and accepts credentials only over HTTPS. Besides this file, a password-authenticator.properties names the file authenticator and a file of bcrypt hashes (htpasswd -B):

security/trino/config.properties: HTTPS and password authentication for Trino

coordinator=true
node-scheduler.include-coordinator=true
discovery.uri=http://localhost:8080
http-server.https.enabled=true
http-server.https.port=8443
http-server.https.keystore.path=/etc/trino/tls/trino.pem
http-server.authentication.type=PASSWORD
internal-communication.shared-secret=${ENV:TRINO_SHARED_SECRET}

security/trino_tls_up.sh restarts l1-trino with these files and the 8.13.5 rules, and security/auth.sh tries four clients. HTTPS without a password got HTTP 401; plain HTTP with only an X-Trino-User header got "Error 403 Forbidden: Authentication over HTTP is not enabled"; a wrong password got "Access Denied: Invalid credentials"; and analyst with the right password got the masked "g***@example.com". The masks now bind a proven identity.

Catalogs need the same care: the Iceberg 129 REST specification uses OAuth 2.0 bearer tokens, and Polaris and Lakekeeper authorize per table and vend short-lived, prefix-scoped storage credentials (Lakehouse Access Control). This chapter's REST fixture has no authentication and belongs on a private network only.

MENU