[ 
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]

Reply via email to