-
Notifications
You must be signed in to change notification settings - Fork 618
HDDS-7831. Use symmetric secret key to sign and verify token #4417
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from 1 commit
77bd133
a5a2007
9660682
f279269
4444f02
d5f5038
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -38,6 +38,7 @@ | |
| import org.apache.hadoop.hdds.protocol.proto.StorageContainerDatanodeProtocolProtos.ContainerReportsProto; | ||
| import org.apache.hadoop.hdds.protocol.proto.StorageContainerDatanodeProtocolProtos.NodeReportProto; | ||
| import org.apache.hadoop.hdds.protocol.proto.StorageContainerDatanodeProtocolProtos.PipelineReportsProto; | ||
| import org.apache.hadoop.hdds.security.symmetric.SecretKeyClient; | ||
| import org.apache.hadoop.hdds.security.x509.certificate.client.CertificateClient; | ||
| import org.apache.hadoop.hdds.upgrade.HDDSLayoutVersionManager; | ||
| import org.apache.hadoop.hdds.utils.IOUtils; | ||
|
|
@@ -139,6 +140,7 @@ public class DatanodeStateMachine implements Closeable { | |
| public DatanodeStateMachine(DatanodeDetails datanodeDetails, | ||
| ConfigurationSource conf, | ||
| CertificateClient certClient, | ||
| SecretKeyClient secretKeyClient, | ||
| HddsDatanodeStopService hddsDatanodeStopService, | ||
| DatanodeCRLStore crlStore) throws IOException { | ||
| DatanodeConfiguration dnConf = | ||
|
|
@@ -171,7 +173,7 @@ public DatanodeStateMachine(DatanodeDetails datanodeDetails, | |
| constructionLock.writeLock().lock(); | ||
| try { | ||
| container = new OzoneContainer(this.datanodeDetails, | ||
| conf, context, certClient); | ||
| conf, context, certClient, secretKeyClient); | ||
| } finally { | ||
| constructionLock.writeLock().unlock(); | ||
| } | ||
|
|
@@ -204,7 +206,7 @@ public DatanodeStateMachine(DatanodeDetails datanodeDetails, | |
| ecReconstructionMetrics = ECReconstructionMetrics.create(); | ||
|
|
||
| ecReconstructionCoordinator = new ECReconstructionCoordinator( | ||
| conf, certClient, context, ecReconstructionMetrics); | ||
| conf, certClient, secretKeyClient, context, ecReconstructionMetrics); | ||
|
|
||
| // This is created as an instance variable as Mockito needs to access it in | ||
| // a test. The test mocks it in a running mini-cluster. | ||
|
|
@@ -245,6 +247,12 @@ public DatanodeStateMachine(DatanodeDetails datanodeDetails, | |
| queueMetrics = DatanodeQueueMetrics.create(this); | ||
| } | ||
|
|
||
| @VisibleForTesting | ||
| public DatanodeStateMachine(DatanodeDetails datanodeDetails, | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I am not really a fan of adding a constructor just for testing...
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I'm not a fan of it either but feel guilty repeating |
||
| ConfigurationSource conf) throws IOException { | ||
| this(datanodeDetails, conf, null, null, null, null); | ||
| } | ||
|
|
||
| private int getEndPointTaskThreadPoolSize() { | ||
| // TODO(runzhiwang): current only support one recon, if support multiple | ||
| // recon in future reconServerCount should be the real number of recon | ||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was wondering if we really need both of these constructor... I understand that we have two from the older version as well, but the only difference is how we get the blockId parameter, as a BlockID or as a String.
The String representation is used in the protocol, I believe we should not use it elsewhere, but apparently we are doing it right now. I think this we might address along with the series of changes that we are doing to go from asymmetric to symmetric keys. What do you think?
I don't want to address this right now, but should we go ahead and have a task for this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Got the concern. I think the internal logic of OzoneBlockTokenId always favor a string presentation. The BlockId if passed is converted to a "service id".
and this "service id" is used to verify the token .