jjj-n commented on issue #12689:
URL: https://github.com/apache/gravitino/issues/12689#issuecomment-5451381531
Hi @paultanay, good catch. You are right: placing `${ENV:...}` directly under
`gravitino.client.oauth2.credential` would not be sufficient. The property
would
still be classified as security-sensitive by its name and removed before the
dynamic catalog configuration reaches the workers.
What I had in mind is a new Gravitino-side mapping mechanism, rather than
relying
only on Trino's existing environment-variable interpolation:
1. The dynamic catalog configuration would carry only non-sensitive metadata,
such as the name of the environment variable containing the OAuth
credential.
The mapping property itself must not match the sensitive-property suffix
filter.
2. The literal credential and the original
`gravitino.client.oauth2.credential` property would never be stored in or
distributed through the dynamic catalog configuration.
3. Each connector instance, including those created on workers, would resolve
the named environment variable locally and restore the credential in
memory
before `GravitinoAuthProvider` creates the OAuth client.
So this would require a small new mapping/resolution path in Gravitino. My
original comment was ambiguous about that distinction.
Before implementing it, I would still like maintainer guidance on whether the
first change should be limited to `gravitino.client.oauth2.credential`, or
whether the mapping should be generic for all security-sensitive
`gravitino.client.*` properties.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
