[
https://issues.apache.org/jira/browse/HDDS-10604?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
István Fajth updated HDDS-10604:
--------------------------------
Description:
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.)
was:
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.
> Whitelist based compliance check for crypto related configuration
> -----------------------------------------------------------------
>
> 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]
