hadoop-hdfs-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Anu Engineer (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (HDDS-580) Bootstrap OM/SCM with private/public key pair
Date Sat, 27 Oct 2018 02:34:00 GMT

    [ https://issues.apache.org/jira/browse/HDDS-580?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16665840#comment-16665840
] 

Anu Engineer edited comment on HDDS-580 at 10/27/18 2:33 AM:
-------------------------------------------------------------

[~ajayydv] Thanks for the updating the patch. A couple of comments on the v9 patch.
 # I feel that the changes in the Security config are not needed.
Let us keep a Key Store Path – and secure it only to "hdfs" user.
Then we can support a well-known path under it(which is what the current patch seems to do)
So if you want to read the public and private keys for SCM.
We can get to ../keystore/scm/keys. The scm/keys is a storage location we know from the convention.
The user needs to only specify where the key material is stored.
I think if we do that, we can avoid passing component to the security config, we can handle
all of this logic in SecurityUtils.
In other words, I think this logic is better suited for SecurityUtils.java.
 # StorageContainerManager.java: Line 498:
"SCM cannot be started in secure mode", this message will be misleading once we have HDDS-4
branch merged.
 # StorageContainerManager.java: Line 514:
if (SecurityUtils.isOzoneSecurityEnabled(conf)) \{ // Bootstrap security components as well.
bootstrapSecurity(conf); }
We initialize the Storage Directories for the SCM after we
create an store public and private keys. (scmInit)

 ## Should we do key generation after the basic storage is initialized.
 ## Does it make sense to map the default SCM keys to be mapped to this directory path?
 ## Eventually, we will need to generate the Certificate, and that needs the Cluster ID and
SCM ID. So it might make sense to make this call after the SCM identity is generated.
 # Why do we have a command line called INIT_SECURITY since it will check if the secure config
is setup? if we always need config then INIT should be enough? I am not sure I understand
why we need two different ways to do this.
 # We might not be able to do this in this patch, but we should file a JIRA to track this.
We should write an Audit Entry to who created the Private Keys, Who created the certificates
etc. that is a security audit log of everything we did in SCM init.
 # We don't authenticate the user who is running the scm --init. Should we read the Keytab
file and find out if the user is an admin group user?
 # We can lose the component from the Self-signedCertificate.java too. If we isolate SecurityConfig.java
from having this change, it will work consistently. We might have to pass paths to SecurityConfig.java
to get various objects, but it is better than having to pass a string everywhere we use that.
 # Rotating keys and certificates need more work. Should we separate that to a different JIRA
and not be part of this one?
 # We seem to have removed some Kerberos related keys in this patch, was that intentional?
 # nit: unused keypair variable in OzoneManager.java
 # I am not sure I understand the pattern of having init and init_security. Am I missing something
here?
 # Should this function "isOzoneSecurityEnabled" be in SecurityConfig.java?
 # SecurityUtils.java#bootstrapKeyPair - This function we fail if the keyPair already exists.
I am fine with the failure, but we should define what we need to do fix this.
 ## Do you want the user to delete these key files?
 ## if the key files already exist, should we not be able to use them instead of failing?
that way user can provide a key if he/she so desires. Not something we need to support now,
just a thought.
 # nit: There are a couple of unused functions in SecurityUtils.java.


was (Author: anu):
[~ajayydv] Thanks for the updating the patch. A couple of comments on the v9 patch.
 # I feel that the changes in the Security config are not needed.
Let us keep a Key Store Path – and secure it only to "hdfs" user.
Then we can support a well-known path under it(which is what the current patch seems to do)
So if you want to read the public and private keys for SCM.
We can get to ../keystore/scm/keys. The scm/keys is a storage location we know from the convention.
The user needs to only specify where the key material is stored.
I think if we do that, we can avoid passing component to the security config, we can handle
all of this logic in SecurityUtils.
In other words, I think this logic is better suited for SecurityUtils.java.
 # StorageContainerManager.java: Line 498:
"SCM cannot be started in secure mode", this message will be misleading once we have HDDS-4
branch merged.
 # StorageContainerManager.java: Line 514:
if (SecurityUtils.isOzoneSecurityEnabled(conf)) {
// Bootstrap security components as well.
bootstrapSecurity(conf);
}
We initialize the Storage Directories for the SCM after we
create an store public and private keys. (scmInit)
 ## Should we do key generation after the basic storage is initialized.
 ## Does it make sense to map the default SCM keys to be mapped to this directory path?
##. Eventually, we will need to generate the Certificate, and that needs the Cluster ID and
SCM ID. So it might make sense to make this call after the SCM identity is generated.
 # Why do we have a command line called INIT_SECURITY since it will check if the secure config
is setup? if we always need config then INIT should be enough? I am not sure I understand
why we need two different ways to do this.
 # We might not be able to do this in this patch, but we should file a JIRA to track this.
We should write an Audit Entry to who created the Private Keys, Who created the certificates
etc. that is a security audit log of everything we did in SCM init.
 # We don't authenticate the user who is running the scm --init. Should we read the Keytab
file and find out if the user is an admin group user?
 # We can lose the component from the Self-signedCertificate.java too. If we isolate SecurityConfig.java
from having this change, it will work consistently. We might have to pass paths to SecurityConfig.java
to get various objects, but it is better than having to pass a string everywhere we use that.
 # Rotating keys and certificates need more work. Should we separate that to a different JIRA
and not be part of this one?
 # We seem to have removed some Kerberos related keys in this patch, was that intentional?
 # nit: unused keypair variable in OzoneManager.java
 # I am not sure I understand the pattern of having init and init_security. Am I missing something
here?
 # Should this function "isOzoneSecurityEnabled" be in SecurityConfig.java?
 # SecurityUtils.java#bootstrapKeyPair - This function we fail if the keyPair already exists.
I am fine with the failure, but we should define what we need to do fix this.
 ## Do you want the user to delete these key files?
 ## if the key files already exist, should we not be able to use them instead of failing?
that way user can provide a key if he/she so desires. Not something we need to support now,
just a thought.
 # nit: There are a couple of unused functions in SecurityUtils.java.

> Bootstrap OM/SCM with private/public key pair
> ---------------------------------------------
>
>                 Key: HDDS-580
>                 URL: https://issues.apache.org/jira/browse/HDDS-580
>             Project: Hadoop Distributed Data Store
>          Issue Type: Sub-task
>            Reporter: Xiaoyu Yao
>            Assignee: Ajay Kumar
>            Priority: Major
>         Attachments: HDDS-4-HDDS-580.00.patch, HDDS-580-HDDS-4.00.patch, HDDS-580-HDDS-4.01.patch,
HDDS-580-HDDS-4.02.patch, HDDS-580-HDDS-4.03.patch, HDDS-580-HDDS-4.04.patch, HDDS-580-HDDS-4.05.patch,
HDDS-580-HDDS-4.06.patch, HDDS-580-HDDS-4.07.patch, HDDS-580-HDDS-4.08.patch, HDDS-580-HDDS-4.09.patch
>
>
> We will need to add API that leverage the key generator from HDDS-100 to generate public/private
key pair for OM/SCM, this will be called by the scm/om admin cli with "-init" cmd.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

---------------------------------------------------------------------
To unsubscribe, e-mail: hdfs-issues-unsubscribe@hadoop.apache.org
For additional commands, e-mail: hdfs-issues-help@hadoop.apache.org


Mime
View raw message