[
https://issues.apache.org/jira/browse/HDDS-17722?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Siyao Meng updated HDDS-17722:
------------------------------
Description:
Follow-up to HDDS-17721.
HDDS-17235 limits the inter-SCM gRPC server to SCM (CA) certificates. Recon
used that server to download the SCM DB, so HDDS-17721 moves the download to
SCM's {{/dbCheckpoint}} over HTTP(S) with SPNEGO. As a result, whether the
transfer is encrypted follows {{ozone.http.policy}} instead of
{{hdds.grpc.tls.enabled}}.
A proper fix would keep Recon on gRPC with mTLS. SCM's CA already verifies the
requester's role through Kerberos when it issues a certificate
({{SCMSecurityProtocolServer#checkRequesterIsService}}), but it does not record
the role in the certificate, and the subject and extensions come from the CSR.
If the CA wrote a role marker that only it controls into Recon certificates
(for example a custom extension or extended key usage that is never copied from
a CSR), the inter-SCM gRPC server could accept CA certificates plus leaf
certificates marked as Recon, while still rejecting Datanode and OM
certificates.
To design:
* The marker, and making sure the CA never takes it from a CSR.
* Existing Recon certificates have no marker until they renew (one year by
default), for example by having Recon request a new certificate.
* Mixed versions: an old SCM CA with a new Recon, and the other way around.
* Whether to move the SCM DB download back to gRPC afterwards.
Issuing Recon a CA certificate instead is not an option: a CA certificate can
sign certificates that the whole cluster trusts.
was:Follow-up to HDDS-17721.
> Mark Recon certificates so the inter-SCM gRPC server can authenticate Recon
> ---------------------------------------------------------------------------
>
> Key: HDDS-17722
> URL: https://issues.apache.org/jira/browse/HDDS-17722
> Project: Apache Ozone
> Issue Type: Improvement
> Components: Ozone Recon, SCM, Security
> Reporter: Siyao Meng
> Priority: Major
>
> Follow-up to HDDS-17721.
> HDDS-17235 limits the inter-SCM gRPC server to SCM (CA) certificates. Recon
> used that server to download the SCM DB, so HDDS-17721 moves the download to
> SCM's {{/dbCheckpoint}} over HTTP(S) with SPNEGO. As a result, whether the
> transfer is encrypted follows {{ozone.http.policy}} instead of
> {{hdds.grpc.tls.enabled}}.
> A proper fix would keep Recon on gRPC with mTLS. SCM's CA already verifies
> the requester's role through Kerberos when it issues a certificate
> ({{SCMSecurityProtocolServer#checkRequesterIsService}}), but it does not
> record the role in the certificate, and the subject and extensions come from
> the CSR. If the CA wrote a role marker that only it controls into Recon
> certificates (for example a custom extension or extended key usage that is
> never copied from a CSR), the inter-SCM gRPC server could accept CA
> certificates plus leaf certificates marked as Recon, while still rejecting
> Datanode and OM certificates.
> To design:
> * The marker, and making sure the CA never takes it from a CSR.
> * Existing Recon certificates have no marker until they renew (one year by
> default), for example by having Recon request a new certificate.
> * Mixed versions: an old SCM CA with a new Recon, and the other way around.
> * Whether to move the SCM DB download back to gRPC afterwards.
> Issuing Recon a CA certificate instead is not an option: a CA certificate can
> sign certificates that the whole cluster trusts.
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
