[
https://issues.apache.org/jira/browse/HDDS-8132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17699645#comment-17699645
]
Sammi Chen edited comment on HDDS-8132 at 3/15/23 1:39 AM:
-----------------------------------------------------------
[~Myskov], thanks for identify the issue and raising this topic. I have gone
through the document, and have several comments.
# Save the secret in plain text should definitely be avoid. I previously
considered using OM's private key to encrypt the s3 credential, save the
encrypted one in RocksDB, and later use OM's public key to decrypt. One
drawback of this solution is OM key get rotated regullary(current around 1y).
Once the key rotated, all encrypted s3 credentials require re-encryption using
the new key. Using HashiCorp Vault, we can delegate this effort to Vault. With
HDDS-7815 done, it's feasible to support a Vault storage now.
# For "Endpoint for keys generation", have you compared exposing the endpoint
on OM Web vs in through S3G？ These new REST APIs are different than S3 APIs. So
if we expose them through OM Web, then we don't need to introduce the new set
of configurations for s3 security server, also there is one less hop in network.
# We also have thought about the s3 credential lifetime management, can refer
to HDDS-7887. Will 24h lifetime too short for a s3 credential? For every time
s3 credentials are updated, the application which are use this credentials
should reconfigure the AWS secret. For some application which run more than 1d,
it would be a problem.
was (Author: sammi):
[~Myskov], thanks for identify the issue and raising this topic. I have gone
through the document, and have several comments.
# Save the secret in plain text should definitely be avoid. I previously
considered using OM's private key to encrypt the s3 credential, save the
encrypted one in RocksDB, and later use OM's public key to decrypt. One
drawback of this solution is OM key get rotated regullary(current around 1y).
Once the key rotated, all encrypted s3 credentials require re-encryption using
the new key. Using HashiCorp Vault, we can delegate this effort to Vault. With
HDDS-7815 done, it's feasible to support a Vault storage now.
# For "Endpoint for keys generation", have you compared exposing the endpoint
on OM Web vs in through S3G. These new REST APIs are different than S3 APIs. So
if we expose them through OM Web, then we don't need to introduce the new set
of configurations for s3 security server, also there is one less hop in
network.
# We also have thought about the s3 credential lifetime management, can refer
to HDDS-7887. Will 24h lifetime too short for a s3 credential? For every time
s3 credentials are updated, the application which are use this credentials
should reconfigure the AWS secret. For some application which run more than 1d,
it would be a problem.
> Secure S3 keys management
> -------------------------
>
> Key: HDDS-8132
> URL: https://issues.apache.org/jira/browse/HDDS-8132
> Project: Apache Ozone
> Issue Type: Improvement
> Reporter: Maksim Myskov
> Assignee: Maksim Myskov
> Priority: Major
> Labels: pull-request-available
> Attachments: Secure S3 keys management.pdf
>
>
> While attempting to get Ozone to production, we found several security flaws
> regarding S3 auth.
> Some of them we have already done (HDDS-7191, HDDS-7815), some of them are in
> progress (HDDS-8050,HDDS-7814), and some are to be implemented.
> This Jira has several purposes:
> # To be an umbrella Jira for work regarding improving S3 security
> # To share our vision regarding S3 security
> I attached a design document that describes all the security flaws we have
> found. Eliminating them will drastically increase Ozone S3 security.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
