gianm commented on code in PR #17774:
URL: https://github.com/apache/druid/pull/17774#discussion_r2018971599


##########
processing/src/main/java/org/apache/druid/query/policy/PolicyConfig.java:
##########
@@ -0,0 +1,144 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements.  See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership.  The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License.  You may obtain a copy of the License at
+ *
+ *   http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied.  See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+
+package org.apache.druid.query.policy;
+
+import com.fasterxml.jackson.annotation.JsonCreator;
+import com.fasterxml.jackson.annotation.JsonProperty;
+import com.google.common.collect.ImmutableList;
+
+import javax.annotation.Nonnull;
+import java.util.Objects;
+
+/**
+ * Defines how strict we want to enforce the policy on tables during query 
execution process.
+ */
+public class PolicyConfig
+{
+  @JsonProperty
+  private final TablePolicySecurityLevel tablePolicySecurityLevel;
+
+  @JsonProperty
+  private final ImmutableList<String> allowedPolicies;
+
+  @JsonCreator
+  public PolicyConfig(
+      @JsonProperty("tablePolicySecurityLevel") TablePolicySecurityLevel 
tablePolicySecurityLevel,
+      @JsonProperty("allowedPolicies") ImmutableList<String> allowedPolicies
+  )
+  {
+    this.tablePolicySecurityLevel = tablePolicySecurityLevel;
+    this.allowedPolicies = allowedPolicies;
+  }
+
+  /**
+   * Returns a {@link PolicyConfig} instance that applies restrictions 
whenever seen fit, and allows all policy types.
+   */
+  public static PolicyConfig defaultInstance()
+  {
+    return new PolicyConfig(TablePolicySecurityLevel.APPLY_WHEN_APPLICABLE, 
ImmutableList.of());
+  }
+
+  /**
+   * Returns the table policy security level, higher value means stricter 
policy.
+   *
+   * @see TablePolicySecurityLevel
+   */
+  @JsonProperty
+  public TablePolicySecurityLevel getTablePolicySecurityLevel()
+  {
+    return tablePolicySecurityLevel;
+  }
+
+  /**
+   * Returns a list of allowed policy class.
+   * <p>
+   * An empty list means all policy classes are allowed.
+   */
+  @JsonProperty
+  public ImmutableList<String> getAllowedPolicies()
+  {
+    return allowedPolicies;
+  }
+
+  public boolean allowPolicy(@Nonnull Policy policy)
+  {
+    return allowedPolicies.isEmpty() || 
allowedPolicies.contains(policy.getClass().getSimpleName());
+  }
+
+  /**
+   * Returns true if the security level requires that, every table must have a 
policy during query execution stage,
+   * this means the table must have a non-empty value in the policy map.
+   */
+  public boolean policyMustBeCheckedAndExistOnAllTables()

Review Comment:
   IMO, "enable users [operators, really] to bind a PolicyValidator they want 
to use" is the right way to go. Although I would suggest naming it 
`PolicyEnforcer`. It should be specified the same way most potentially-complex 
choices are specified: using a Jackson-deserializable interface bound with 
`JsonConfigProvider`. That makes it possible to provide custom enforcers in 
site-specific extensions, and those custom enforcers can themselves take 
configuration.
   
   I suggest the `PolicyEnforcer` interface should have two methods:
   
   - `validateQuery(Query)` which runs on both Brokers and data servers before 
a query is issued.
   - `validateProcessableSegment(Segment)` which runs on data servers on the 
mapped segments that result from `createSegmentMapFunction`.
   
   We should provide some basic builtin validator in core, mostly so we can 
write proper tests for the validation feature. IMO it would work to provide two 
builtin enforcers:
   
   - `none` (default enforcer, does nothing)
   - `restrictAllTables` (enforcers that all tables are wrapped in some 
`restricted` datasource)
   
   With the `JsonConfigProvider` approach, these could be specified at runtime 
using something like `druid.auth.policy.enforcer.type = restrictAllTables`.



-- 
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]


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to