[
https://issues.apache.org/jira/browse/HDDS-10604?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
István Fajth updated HDDS-10604:
--------------------------------
Summary: Whitelist based compliance check for crypto related configuration
options (was: Whitelist based compliance check for crypto related
configuration)
> Whitelist based compliance check for crypto related configuration options
> -------------------------------------------------------------------------
>
> Key: HDDS-10604
> URL: https://issues.apache.org/jira/browse/HDDS-10604
> Project: Apache Ozone
> Issue Type: Improvement
> Reporter: István Fajth
> Priority: Major
>
> Our base class of configuration is OzoneConfiguration, which is a direct
> child class of Hadoop's Configuration object.
> This makes it ideal to implement a common way to get a crypto related
> configuration parameter just after it was checked to be present in the
> relevant whitelist. In case the configuration option's value is not present
> in the whitelist an exception should be thrown, that shuts down the component.
> This method should take the config option, and the config option of the
> relevant whitelist, besides the default value so defaults should be provided
> programmatically.
> With that we introduce the possibility to select the proper default value for
> the environment based on either from code, or from additional config files,
> that this routine can help later on. The initial version should only support
> the wildcard as the whitelist, it is still to be investigated what would be
> the best option to provide a generic way to define the relation between one
> config option and the relevant whitelist for this option.
> Note: places where we use a cryptography function for something that is not
> related to authentication, authorization, encryption, decryption, or
> identification, we may skip adding new configuration, but we need to mark
> these places in the code, and we need to document the purpose, so that
> compliance check can decide if it is something that is under the regulation,
> or it is irrelevant. (One example might be allowing and MD5 hash to be used
> for block checksum, where the MD5 usage is for content integrity
> verification, as that is not a security concern at all, with that it is
> highly likely that an exemption can be made for those use cases of any crypto
> function.)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]