You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@ozone.apache.org by "István Fajth (Jira)" <ji...@apache.org> on 2023/01/17 21:49:00 UTC
[jira] [Updated] (HDDS-7376) Re-organize security bootstrap code
[ https://issues.apache.org/jira/browse/HDDS-7376?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
István Fajth updated HDDS-7376:
-------------------------------
Description:
The current security bootstrap code is kind of here and there in the codebase.
We have some parts of it written as utility methods in different util classes, and some of the logic is implemented as part of the service startup code.
The aim of this improvement, to create a standard logic that describes the generic things that every service has to do in order to setup internal certificates and corresponding keypairs if security is enabled for Ozone, and also to enable the service specific parts to be implemented by the services themselves.
Update:
CertificateClient has these responsibilities:
1. it handles loading other certificates from SCM on request, and caches these certificates locally
2. it handles data signing with the private key material
3. it handles signature validation based on other certificates
4. it stores the SSL identity material of the service
5. it handles the initialization of the certificate and keypair of the component and gathers the signed certificate from SCM
6. it provides CA related information
7. it provides CRL related information
8. it provides factory implementation for keystores and truststores
The central role of security initialization therefore is pushed to the CertificateClient instances, and all components have a very similar initialization call sequence against this class.
Based on this the proposal is to:
- separate a CertificateStore that is responsible for #1 and used by something that implements #4
- separate an RSASigner for #2
- separate an RSASignVerifier for #3
- separate the SSLIdentity representation for #4 that is the in memory representation of the RSA keypair and the certificate and provides accessor and convenience methods to access this data or tp configure external things that use this data (maybe 2 separate interface but one impl?)
- separate the component SSL certificate initialization logic from components and from CertificateClient and standardize the process for #5
- functionalities for #6 should be part of the CertificateStore
- #7 should be removed for now, along with the dependent CRL code, this is related to HDDS-7397
- #8 items should probably have their own separate class, or trust and keystore may be provided by the CertificateStore.
was:
The current security bootstrap code is kind of here and there in the codebase.
We have some parts of it written as utility methods in different util classes, and some of the logic is implemented as part of the service startup code.
The aim of this improvement, to create a standard logic that describes the generic things that every service has to do in order to setup internal certificates and corresponding keypairs if security is enabled for Ozone, and also to enable the service specific parts to be implemented by the services themselves.
> Re-organize security bootstrap code
> -----------------------------------
>
> Key: HDDS-7376
> URL: https://issues.apache.org/jira/browse/HDDS-7376
> Project: Apache Ozone
> Issue Type: Improvement
> Components: Security
> Reporter: István Fajth
> Assignee: István Fajth
> Priority: Major
> Labels: pki
>
> The current security bootstrap code is kind of here and there in the codebase.
> We have some parts of it written as utility methods in different util classes, and some of the logic is implemented as part of the service startup code.
> The aim of this improvement, to create a standard logic that describes the generic things that every service has to do in order to setup internal certificates and corresponding keypairs if security is enabled for Ozone, and also to enable the service specific parts to be implemented by the services themselves.
> Update:
> CertificateClient has these responsibilities:
> 1. it handles loading other certificates from SCM on request, and caches these certificates locally
> 2. it handles data signing with the private key material
> 3. it handles signature validation based on other certificates
> 4. it stores the SSL identity material of the service
> 5. it handles the initialization of the certificate and keypair of the component and gathers the signed certificate from SCM
> 6. it provides CA related information
> 7. it provides CRL related information
> 8. it provides factory implementation for keystores and truststores
> The central role of security initialization therefore is pushed to the CertificateClient instances, and all components have a very similar initialization call sequence against this class.
> Based on this the proposal is to:
> - separate a CertificateStore that is responsible for #1 and used by something that implements #4
> - separate an RSASigner for #2
> - separate an RSASignVerifier for #3
> - separate the SSLIdentity representation for #4 that is the in memory representation of the RSA keypair and the certificate and provides accessor and convenience methods to access this data or tp configure external things that use this data (maybe 2 separate interface but one impl?)
> - separate the component SSL certificate initialization logic from components and from CertificateClient and standardize the process for #5
> - functionalities for #6 should be part of the CertificateStore
> - #7 should be removed for now, along with the dependent CRL code, this is related to HDDS-7397
> - #8 items should probably have their own separate class, or trust and keystore may be provided by the CertificateStore.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@ozone.apache.org
For additional commands, e-mail: issues-help@ozone.apache.org