At the risk of starting a flame war, this is my 2 cents. In the end rundeck will need the actual un-encrypted password to connect to the service. This means rundeck needs to be able to decrypt/decode the configured value. That will mean that rundeck will then need access to whatever password was used to encrypt it and the algorithms used for the transform. The password encrypting password would then need to be stored somewhere and the algorithms used would clearly be visible in the class files, not to mention the source code as rundeck is opensource.
So I feel time is better spent securing the server and the files in question than to hiding the password. If someone has a solution I would love to hear it because I have been wrestling with this issue for years.
p.s. this is the primary reason I use rundeck, so I can allow support people to restart tomcat servers without allowing them to see the sensitive config files.