[jira] [Updated] (HDDS-8960) Hold the rootCA's private key only in memory for the time of initialization/rotation, then forget it

["ASF GitHub Bot (Jira)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/HDDS-8960?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

ASF GitHub Bot updated HDDS-8960:
---------------------------------
    Labels: pull-request-available  (was: )

> Hold the rootCA's private key only in memory for the time of initialization/rotation, then forget it
> ----------------------------------------------------------------------------------------------------
>
>                 Key: HDDS-8960
>                 URL: https://issues.apache.org/jira/browse/HDDS-8960
>             Project: Apache Ozone
>          Issue Type: Sub-task
>            Reporter: István Fajth
>            Assignee: Szabolcs Gál
>            Priority: Blocker
>              Labels: pull-request-available
>
> The rationale behind this task is the fact that the rootCA certificate is only used to sign the sub-CA certificates assigned to the SCMs, and the rotation/initialization can only succeed if all SCMs have the sub-CA certificate and the materials needed for them.
> Later on the rootCA certificate is not used to sign anything else, and we just need it as the trust anchor, the keypair we can simply forget, as the private key is not needed anymore, while the public key is part of the certificate.
> During the rotation of CA certificates, we are creating a new DefaultCAServer instance, which internally creates and saves the new rootCA certificate and keys.
> Additionally SCM holds a reference to the DefaultCAServer instance with the rootCA certificate, and during initialization it always creates it.
> The DefaultCAServer class is also used with sub-CA certificates as the general CA server within SCM, and contains logic to check on disk data content to be sure we are able to sing certificates properly.
> The proposal here is to somehow separate the two, as we need this full functionality for the CA server with the sub-CA certificate, but for the rootCA certificate, we need the keys only in memory and only until we sign the first 3 (HA case), or the one (non-HA case) sub-CA certificate that will sign certificates for the rest of the services.
> In the original bootstrap we also do not need the rootCA certificate's private key after we signed the first set of sub-CA certificates.
> With this change, we should implement the separation of these two approaches, and we should clean up any unused rootCA related key material from the metadata directories.
> As the rootCA certificate is replicated via raft, and is present in the SCM's rocksDB, we might also remove the on disk representation but that might be useful to have it cached in a file so that we do not need to query the rocksDB for it, this is to decide during implementation.
> Additional complexity is upgrades, as the new code can not immediatelly remove the rootCA material, as the old code still would rely on it, so this needs integration with the upgrade framework as well.



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