Redact sensitive information in catalog queries #24563
Conversation
The SPI will be used by the engine to redact security-sensitive information in statements that manage catalogs. It has been added at the connector factory level, rather than the connector level, to allow more flexibility in retrieving properties. In some cases, we want to perform redacting before a connector is initiated. For example, when we create a new catalog by issuing the CREATE CATALOG statement.
Exposed properties fall into one of the following categories: they are either explicitly marked as security-sensitive or are unknown. The connector assumes that unknown properties might be misspelled security-sensitive properties. The purpose of the included test is to identify security-sensitive properties that may be used by the connector. It uses the output generated by the maven-dependency-plugin, configured in the connector's pom.xml file. This output contains the connector's runtime classpath, which is then scanned to identify all property names annotated with @config. Scanning the classpath ensures that all configuration classes are included, even those used conditionally.
This commit introduces redacting of security-sensitive information in statements containing connector properties, specifically: * CREATE CATALOG * EXPLAIN CREATE CATALOG * EXPLAIN ANALYZE CREATE CATALOG The current approach is as follows: * For syntactically valid statements, only properties containing sensitive information are masked. * If a valid query references a nonexistent connector, all properties are masked. * If a query fails before or during parsing, the entire query is masked The redacted form is created in DispatchManager and is propagated to all places that create QueryInfo and BasicQueryInfo. Before this change, QueryInfo/BasicQueryInfo stored the raw query text received from the end user. From now on, the text will be altered for the cases listed above.
@JsonConstructor for TrimmedBasicQueryInfo was introduced to facilitate the deserialization of server responses in tests.
piotrrzysko
force-pushed
the
redact-sensitive-queries
branch
from
98470bb to
ed595a1
Compare
| return statementRedactingEnabled; | ||
| } | ||
|
|
||
| @Config("statement-redacting-enabled") |
There was a problem hiding this comment.
@mosabua for suggestions about config naming. 😄
There was a problem hiding this comment.
I'm not sure we want an option to disable this. Maybe as a temporary kill switch, but we should remove this as soon as we are happy with this feature
There was a problem hiding this comment.
Agreed, we can prefix with experimental. in that case like we have done in past to clarify this. Or maybe deprecated. from the beginning.
| { | ||
| ConnectorFactory connectorFactory = connectorFactories.get(connectorName); | ||
| if (connectorFactory == null) { | ||
| // If someone tries to use a non-existent connector, we assume they |
There was a problem hiding this comment.
great catch, I didn't think of this case.
| } | ||
|
|
||
| @Override | ||
| protected Node visitCreateCatalog(CreateCatalog createCatalog, Void context) |
There was a problem hiding this comment.
Is there some way to notice when we need to add new node visitors here?
Should this be a "wrapper" like the various Forwarding*** classes and a test to assert that full set of methods is overridden? That way once new methods get added we'll explicitly need to either override to do no-op or to redact?
WDYT? Might be overkill for now so need to change anything - just to have a discussion.
| @@ -240,7 +248,7 @@ private <C> void createQueryInternal(QueryId queryId, Span querySpan, Slug slug, | |||
| DispatchQuery dispatchQuery = dispatchQueryFactory.createDispatchQuery( | |||
There was a problem hiding this comment.
this automatically also handles things like event listener and QueryResource right?
Might be worth to explicitly call it out in the commit message (although you do imply that by mentioning anything using QueryInfo/BasicQueryInfo).
| return statementRedactingEnabled; | ||
| } | ||
|
|
||
| @Config("statement-redacting-enabled") |
There was a problem hiding this comment.
I'm not sure we want an option to disable this. Maybe as a temporary kill switch, but we should remove this as soon as we are happy with this feature
|
|
||
| public class SensitiveStatementRedactor | ||
| { | ||
| public static final String REDACTED_VALUE = "***"; |
There was a problem hiding this comment.
We should consider a better value here than just ***. We could also consider using a special function like $redacted$(), which just throws exceptions if you try to actuall call that function.
There was a problem hiding this comment.
*** seems to be almost what everyone uses for redaction.
Can you expand on the function idea? Is that to make it so that the output of SHOW CREATE CATALOG (as an example) is valid but still fails when you try to run it.
Description
This a follow-up to #24562 that introduces redacting of security-sensitive information in statements containing connector properties, specifically:
CREATE CATALOGEXPLAIN CREATE CATALOGEXPLAIN ANALYZE CREATE CATALOGThe current approach is as follows:
Redacted queries are returned through the REST API, the
system.runtime.queriestable, and query events (QueryCreatedEventandQueryCompletedEvent).Notice that currently this PR includes two commits from #24562.
Additional context and related issues
Release notes
( ) This is not user-visible or is docs only, and no release notes are required.
( ) Release notes are required. Please propose a release note for me.
(x) Release notes are required, with the following suggested text: