fapifta commented on code in PR #5009:
URL: https://github.com/apache/ozone/pull/5009#discussion_r1256619931


##########
hadoop-ozone/ozone-manager/src/main/java/org/apache/hadoop/ozone/om/ServiceInfoProvider.java:
##########
@@ -0,0 +1,102 @@
+/*
+ * 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.hadoop.ozone.om;
+
+import org.apache.hadoop.hdds.conf.ConfigurationSource;
+import org.apache.hadoop.hdds.conf.OzoneConfiguration;
+import org.apache.hadoop.hdds.security.SecurityConfig;
+import 
org.apache.hadoop.hdds.security.x509.certificate.client.CertificateClient;
+import org.apache.hadoop.hdds.security.x509.certificate.utils.CertificateCodec;
+import org.apache.hadoop.ozone.om.helpers.ServiceInfoEx;
+import org.apache.hadoop.ozone.om.protocol.OzoneManagerProtocol;
+import org.slf4j.Logger;
+
+import java.io.IOException;
+import java.security.cert.X509Certificate;
+import java.util.Collections;
+import java.util.LinkedList;
+import java.util.List;
+import java.util.concurrent.CompletableFuture;
+import java.util.function.BiFunction;
+import java.util.function.Function;
+
+import static org.slf4j.LoggerFactory.getLogger;
+
+/**
+ * A helper class to handle the construction of
+ * {@link org.apache.hadoop.ozone.om.helpers.ServiceInfoEx} objects,
+ * and refresh of the things that are necessary for constructing it.
+ */
+public final class ServiceInfoProvider {
+
+  private static final Logger LOG = getLogger(ServiceInfoProvider.class);
+
+  private final OzoneManagerProtocol om;
+  private final CertificateClient certificateClient;
+
+  private String caCertPem;
+  private List<String> caCertPemList;
+
+  public ServiceInfoProvider(
+      OzoneConfiguration config,
+      OzoneManagerProtocol om,
+      CertificateClient certificateClient,
+      BiFunction<CertificateClient, ConfigurationSource, List<String>> caList
+  ) throws IOException {
+    this.om = om;
+    if (new SecurityConfig(config).isSecurityEnabled()) {
+      this.certificateClient = certificateClient;
+      caCertPem = certificateClient.getSingleCACertificatePEM();
+      caCertPemList =
+          caList == null ? null : caList.apply(certificateClient, config);
+      certificateClient.registerRootCARotationListener(onRootCAChange());
+    } else {
+      this.certificateClient = null;
+      caCertPem = null;
+      caCertPemList = null;
+    }
+  }
+
+  private Function<List<X509Certificate>, CompletableFuture<Void>>
+      onRootCAChange() {
+    return certs -> {
+      try {
+        caCertPem = certificateClient.getSingleCACertificatePEM();

Review Comment:
   The thing is that, it is a race condition, but the problem is not the race...
   
   The problem is more of a question instead, around what we want to do with 
1.1 or older clients, as all 1.2 or newer client versions work based off of the 
caCertPemList instead of the caCertPem value.
   So newer clients rightfully get the list of the old and the new rootCA 
certificate, and will work with the cluster fine during the rotation, whichever 
root of trust the certificates of cluster services have old or new.
   
   But with older clients we have a similar tradeoff as we had once we have 
introduce SCM HA. With SCM HA old clients got the sub-CA certificate that OM 
has read from its filesystem as the signer of its certificate, and if the post 
1.2 DN that the pre 1.2 DN trying to connect to has its certificate signed by 
the same cert, then the client was able to read from the DN. Now in our case, 
we again need a decision, either we give back the old root CA certificate, 
which is returned by the certClient at this point, or we return the new 
certificate.
   
   Based on your question I am happy that I thought this through more, and I 
think we should return the new rootCA certificate here. With that, we will have 
a glitch in old clients, as we don't know how many DNs have already renewed 
their certificates with the new rootCA and its subCAs, but for sure the number 
will be all DNs eventually, while less and less DNs will use their old 
certificates. So I need to change this code accordingly. Thank you for pointing 
this out!



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