POLICY-542 attempts to remove the usage of hardcoded passwords in configuration files, post installation with encrypted passwords.   

The limitation is that the secret key to decode is hardcoded in the source code, see:  https://gerrit.onap.org/r/#/c/29715/.   Effectively, provided that the key is publicly known in the code (or could be decompiled from binaries), it does not sove the original problem, it just adds a little bit more of a difficulty.

The recommendation to make it much harder to compromise passwords in they file system (that's the threat model that POLICY-542 tries to impose) is to generate an secret key via openssl or other mechanism at installation time, therefore it will be different on a per installation basis.   The key can be stored in a read only file in a policy directory and only owned by the policy user ($POLICY_HOME/etc/ssl).     The utility will encrypt the plaintext passwords during installation, so configuration files will only contain the encrypted passwords Those files should also be ensured are read only and only owned by the policy account at installation time.

This approach is still much stronger but still have limitations, and in general any such approach, where the thread model assumes that the attacker has access to the filesystem is problematic.   The policy software though contain the damage by operating in a regular user non-privileged account (policy) instead of root.    This benefit though is diluted when the software is run in a container.