fapifta opened a new pull request, #4921:
URL: https://github.com/apache/ozone/pull/4921

   ## What changes were proposed in this pull request?
   
   ### This is a fairly large refactor mainly due to moving files around in 
different modules/packages.
   - OzoneSecurityException moved from hdds-server-framework to hdds-common and 
from o.a.h.hdds.security to o.a.h.hdds.security.exception package.
   - KeyStoresFactory interface moved from hdds-server-framework to 
hdds-common, but remained in the same package along with its implementation
   - Reloading key and trust manager moved from hdds-server-framework to 
hdds-common, but remained in the same package
   - CAType enum moved from hdds-server-framework to hdds-common but remained 
in the same package
   - CertificateClient and CertificateNotification interfaces moved from 
hdds-server-framework to hdds-common, they have remained in the same package.
   - CertificateCode, CertificateSignRequest, SelfSignedCertificate is moved 
from hdds-server-framework to hdds-common they remained in the same package
   - CertificateException moved from hdds-server-framework to hdds-common but 
remained in the same package
   - SecurityConfig moved from o.a.h.hdds.security.x509 to o.a.h.hdds.security 
package.
   
   ### Besides all these moves the following significant changes were made:
   - PemFileBasedKeyStoresFactory implementation was changed to avoid findbugs 
warning about exposing internal structure.
   - Everything under the packages org.apache.hadoop.hdds.security and any 
derived classes rely only on the SecurityConfig object, and the 
OzoneConfiguration and its descendants are not used there anymore.
   - block token duration related sanity check was bought into the 
SecurityConfig, sanity check had to be disabled because of this change in quite 
a lot of tests. Also this reveals a possible follow up JIRA, as we does not 
seem to have a similar check for container token lifetime.
   - OZONE_S3_AUTHINFO_MAX_LIFETIME_KEY removed from OzoneConfigKeys after 
removing the only usage of it in SecurityConfig along with the associated 
getter that is not used anymore anywhere in the code. It was not added to 
ozone-default.xml either.
   - TokenHelper used by EC reconstruction now uses SecurityConfig in its 
constructor, and its code have been changed to delegate understanding the 
configuration to the SecurityConfig object, and just use the proper getters to 
get values.
   - HddsDatanodeService lost its two static creation method, and now the 
costructors are called directly, as there was no further logic or any other use 
of the static creator methods.
   - CertificateClient construction has changed, it relies on a SecurityConfig 
instance from now on, and also it relies to get the SCMSecurityProtocol client 
from outside. This has an effect on all certificate client instantiation, and 
there was a need to change the order of doing UGI login and initializaton due 
to some assumptions in tests that I did not changed.
   - Moved the utility method that sets up the SCMSecurityProtocol client from 
HddsServerUtil to HASecurityUtils
   - OmCertificateClient now relies on OzoneManagerDetailsProto via its 
constructor, and does not call the static method on OzoneManager class directly 
to figure it out.
   
   ### Why I would like to change all of these?
   This is one of the steps to simplify and reduce external dependencies of the 
CertificateClient and related codebase. The final aim is to get to a stage 
where we can separate the code that is responsible to create the certificate 
sign request for a service and send it to the SCM, the code that is responsible 
to store the certificate and key material of a particular service, the code 
that is responsible to gather the rootCA certificate from SCM, and the code 
that provides means to set up the different type of secure connections.
   Also, by centralizing all the security related configuration and its 
handling, we have a single pane of glass to see what configurations we use, and 
what rules we apply to these configuration values.
   
   ## What is the link to the Apache JIRA
   
   https://issues.apache.org/jira/browse/HDDS-8879
   
   ## How was this patch tested?
   
   Existing JUnit and integration tests.
   


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